Recently, while chasing a malware, I wanted to review the local security log of a third party server to which I didn't have direct access. The administrator was willing to provide "a limited export" for my offline analysis.

Newer Windows versions nicely enough provide more than one option to accomplish this.

1. You can use the graphical event viewer GUI, and "Save-as", to export the file in EVTX, XML, TXT or CSV Format.

2. You can use wevtutil.exe at the command line to accomplish pretty much the same, but in a scriptable fashion. Wevtutil.exe  can export the entire log. It also supports an XPath filter that allows to query and export only certain log lines and attributes. Unfortunately, the syntax of these filters

wevtutil qe Security /q:"*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4624)]]"

is a mess, and not easy to stomach for someone more used to the pristine beauty of egrep and regexp's :).

3. A third option is to make use of Powershell and the "get-winevent" or "get-eventlog" cmdlet

get-eventlog -logname security -newest 10000 | Export-clixml seclog.xml

is a pretty quick way to get the latest 10'000 records out of the security log. This is the option I chose, because I (somewhat naively) figured that this would be the fastest way to get a quick look. Not surprisingly, the export-xml command left me with an XML file, which is again not easy to stomach for someone more used to the pristine beauty of egrep and syslog :). But Powershell isn't bad, either. On the analysis workstation, you can stuff the entire log into a variable, thusly:

PS C:\TEMP> $seclog = Import-Clixml seclog.xml

and then use the power of Powershell to get a rapid tally:

PS C:\TEMP> $seclog | group eventid -noelement | sort count

Count Name
----- ----
    1 4662
    1 5058
    1 5061
    1 4904
    2 4648
    2 5140
    5 4611
    6 6144
    6 4735
   12 4985
   17 4634
   19 4672
   20 4674
   20 4624
  128 4663
  175 4673

KB947226 helps to translate the EventIDs into readable information. Once we know which events are of interest, we can then extract them:

PS C:\TEMP> $seclog | ? { $_.eventid -match '5140' } | fl *

[...]
Message : A network share object was accessed.

          Subject:
              Security ID:        S-1-5-21-394181-2045529214-8259512215-1280
              Account Name:       TRA29C
              Account Domain:     AMER
              Logon ID:           0x311a28b

          Network Information:
              Object Type:        File
              Source Address:     10.11.192.16
              Source Port:        6539

          Share Information:
              Share Name:        \\*\C$
              Share Path:        \??\C:\
[...]

All the Powershell formatting and querying and pattern match functions can now be used to cut and dice the information to find the haystalk in the cow pie.

If you have any clever Powershell Jiu-Jitsu up your sleeve to deal with unwieldy event logs, please let us know, or share in the comments below.

[Guest Diary: Dylan Johnson BSc.CISSP] [There's value in them there logs!]

Today we bring you a guest diary from Dylan Johnson where he shows us a really cool way to aggregate logs into one place, search, trend, analyze in realtime and graph.

Events in Logs tell a story and are invaluable as a data source. Logs can be used as a source to create complex instrumentation, aid with root cause analysis, and provide real time analysis, during a security incident for example and a plethora of other uses such as trend analysis and forecasting. One of the problems with logs is their non standard use of timestamps, so if you want to correlate across logs you need some pretty tasty regular expression skills. It would be great if your search terms dealt with a single time stamp format and could also query the intrinsic values in all of these logs, across multiple machines, in real-time and with trending information + time series data. Sounds like a big ask for free? Read on!

This diary slot is not large enough to go into any great detail, however I wanted to share a event management framework that concerns itself with shipping, normalisation, filtering, output, time series data and trending of data in log files, from here on referred to as events.

Below is the architecture:

Lets look at the architecture above as there a fair amount of independent moving parts.

Logstash is a stupendous Java application created by Jordan Sissel (see www.logstash.net) which takes data from multiple sources such as file, syslog, message queues, pipes etc and gives you the power to splice and dice, top and tail and mangle this data or event stream via filters (more on these later) and importantly gives each event a standard time stamp. Once you have filtered or normalised your data Logstash gives you plenty of output options for this data such as Elasticsearch, email, graphite and Nagios. So in a nutshell Logstash takes your event streams, does stuff to them and outputs them somewhere useful. This architecture utilises the Elasticsearch output filter (www.elasticsearch.org) an extremely fast, scalable database with Lucene (http://lucene.apache.org/core/) built in for good measure. You can query Elasticsearch via simple REST based calls. As you can see we use Kibana (www.kibana.org) as the query interface and its great as you will see later. There is also Graylog (www.graylog2.org) and one thing to note about Graylog is that is has alerting a feature currently missing in kibana.

Statsd is an aggregation service that listens for events from the Logstash Statsd (https://github.com/etsy/statsd/) output plug-in, counts the events up over time and emits them to graphite (http://graphite.wikidot.com/), a real time scalable time series data application.

One last tool to mention is GROK. GROK is utilised in Logstash filtering, its goal is to bring more semantics to regular expressions allowing expression of ideas rather than complex syntax. (http://code.google.com/p/semicomplete/wiki/GrokConcepts) There is a great tool to help with creating your GROK filters here (http://grokdebug.herokuapp.com/)

Here is a simple Logstash.conf file that reads in an Apache log from a file, parses all of the fields from each event in the log and outputs to Elasticsearch and Graphite. You can find more information on Logstash.net and there is a big community offering support on IRC Freenode.net #logstash

input {

file {

type => "Apache"

path => ["/var/log/httpd/access_log"]

}}

filter {

grok {

type => "Apache"

patterns_dir => "/data/syslog_inbound/grok_pat"

pattern => "%{COMBINEDAPACHELOG}"

}}

output {

elasticsearch {

bind_host => "0.0.0.0"

}

statsd {

increment => "Apache.Verbs.%{verb}"

}}

As you can see the pattern %COMBINEDAPACHELOG is doing some pretty powerful stuff. Its breaking the log up into its constituent parts. This is really useful if you want to get trending metrics from Elasticsearch. For example, tell me what hosts are trending up and down for GETS or 404's etc.

To end on here are a few screen shots showing what you get from all of this effort.

Trending

Output to Graphite via Statsd

Base Line Stats

We have only just scratched the surface here! The framework detailed has limitless potential to solve many complex security event management problems. I hope this has given you an idea of what can be achieved with a bit of research and hard work.

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

Java just can't catch a break!  A number of our readers have pointed out that Security Explorations claims they have 2 new Java zero days (no verification from Oracle on this yet).

This of course has fueled the fire of "it's time to just say no and uninstall Java" in many quarters.  And for general purpose internet browsing, maybe you can.  If you do need Java, and if you do, changing the security settings to "ask every time" is a good way to go.  Of course, if you run a business app that needs Java, you need to make it transparent to your user community somehow - this can be particular problem if your app needs a specific (aka old / vulnerable) Java version - we've talked about this in a few different stories over the last few months.

But this got me to thinking, as security folks, what tools or processes do we use daily that need Java?

My list is pretty short:
Burp Suite for Web Assessments - www.portswigger.net
ZAP - Zed Attack Proxy, also for Web Assessments - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Nessus, for straight up vulnerability assessments and security scans (Java is only needed for PDF exports in Nessus I think) - http://www.tenable.com

Network appliance administration is often Java based as well - for instance, the GUI for Cisco ASA firewalls and many wirelss controllers requires Java to run.

What's in your "I only need Java for this or that infosec tool" list?  Please, let us know through our comment form.
 

===============
Rob VandenBrink
Metafore

I was recently in a client engagement where we had to rebuild / redeploy some ESXi 4.x servers as ESXi 5.1.  This was a simple task, and quickly done (thanks VMware!), but before we were finished I realized that we had missed a critical part - the remote managent port on the servers.  These were iLO ports in this case, as the servers are HP's, but they could just as easily have been DRAC / iDRAC (Dell), IMM or AMM (IBM) or BMC (Cisco, anything with a Tyan motherboard or lots of other vendors).  These "remote management ports are in fact all embedded systems - Linux servers on a card, booting from flash and usually running a web application.  This means that once you update them (via a flash process) they are "frozen in time" as far as Linux versions and patches go. In this case, these iLO cards hadn't been touched in 3 years.

So from a security point of view, all the OS version upgrades and security patches from the last 3 years had NOT been applied to these embedded systems.  What can you do with access to these remote managment cards?  Well, anything from take over the console keyboard and screen, mount a CD or DVD over the netowrk, to powering the server off or reconfigure or delete RAID arrays.  The goal of these cards is to enable you to do almost anything you can do from the console, but from a remote location.  Couple this with difficulty in patching them (or just forgetting to patch them), and youv'e got a serious exposure. 

How can you mitigate a situation like this?  The obvious answer is to patch as updates come out.  For many server vendors however, this means booting the server from a CD or DVD.  This is often a tough sell to management, as it's not only an outage for a production server, but if the firmware update fails or causes some new problem, that could cause another (unplanned) outage later, or in the best case a planned outage to back out the update.  Plus you need to convince them every time the topic comes up that you need remote management at all, which eventually starts to sound like too much work.  But *not* updating critical server components is a ticking time-bomb.  

And all this assumes that your server vendor actually fixes known security issues in their  OS or management interfaces. Since these interfaces are normally web-based, not only does this mean OS patches, but it's VERY common to see XSS, CSRF, authentication bypass and even command injection vulnerabilities built-in to the web interface - so you get your web vulnerabilities for free before you even deploy your own web application!  And server vendors aren't always keen to hear about or fix security issues in these interfaces - from their point of view they might be asked to fix an interface issue in a product they stopped selling years ago, so to the sales folks it might seem like lost money to fix these things.

What many folks do is put the remote management cards in their dedicated management VLAN, which has ACLs and other protections on it.  This certainly isolates these cards from attackers and targetted malware, but if that VLAN is ever breached, these cards become the low-hanging fruit for the attack, which can then be used as a pivot to attack more hardened interfaces such as the Hypervisor admin consoles or SAN management interfaces that are also commonly in these Management VLANS.  I'd suggest both patching your server hardware and segmenting these interface cards off, possibly on a dedicated VLAN just for them.

What other devices in your datacenter should be considered embedded systems, with the same risks? 

• The obvious ones in my mind are KVM (Keyboard / Video / Mouse) switches, which now often have IP interfaces for access, and in some cases operate over IP with dongles attached to the servers - in this case both the KVM unit and the individual dongles are all embedded systems. 
• On the network side - routers, switches and fiber channel switches all have these same risks.  These devices and risks are generally more well-understood though, and in most security conscious environments are patched annually or (hopefully) more frequently.  But in security assessments, it's not uncommon at all for me to find a core routing switch that the entire organization depends on running 10 year old code (just to pick an example from last month).
• Many of the more advanced SCSI RAID, SCSI HBAs or Fiber Channel HBAs (Host Bus Adapters) are now web-enabled, with their own IP addresses and management interfaces (no risk there!).  Folks tend to see these web interfaces as great features, and not make that next cognitive leap to see how they can easily be turned into silent killers.

Oh, one more thing - please change the passwords on all of these!  All the patching in the world won't help you if you're attacker can google for the administrative credentials.  I can't tell you how many SANs, Bladecenters or FC Switches I've seen with the default administrative credentials still in play.  If your admin password is still "password", it's time to change it!

The list of embedded devices in your datacenter goes on - door locks, lights and HVAC controls of course, but I'm sure there are other embedded systems that could be turned to evil in our server racks.  Take a walk down the cold aisle (or better yet, down the hot aisle) in your server room and take a look - please, post anything interesting that you might find in our comment form!
 

===============
Rob VandenBrink
Metafore

Thanks to Gebhard for pointing out the article by Heise about a new spider focusing on finding web application vulnerabilities [1]. "Punkspider" runs essentially a vulnerabiliy scan on random web sites. The results are then searchable. I am not sure about the quality about the results (it doesn't find anything for isc.sans.edu ... ) but you may want to check your own site. There is also a simple, non documented at this point, json API:

http://punkspider.hyperiongray.com/service/search/domain/

Which accepts the following GET parameters:

searchkey: url|title
searchvalue: the url or title you would like to search for
pages: 0
pagesize: how many results (10 by default)
pagenumber: which page (1 by default)

For example:

http://punkspider.hyperiongray.com/service/search/domain/?searchkey=url&searchvalue=isc.sans.edu&pages=0&pagesize=10&pagenumber=1

The Heise article below has more details. Evidentially it is possible to block the spider via robots.txt but I haven't seen the user agent documented. (need to check my logs). Of course, you could block it in robots.txt, or return overly large, or wrong results based on the user agent. Maybe some fake vulnerabilities to see who is exploiting them later.

[1] http://www.h-online.com/security/news/item/Vulnerabilities-served-up-1810524.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Just got another interesting phishing e-mail. This time around it is security company Trustwave that is being phished. I am not a customer, so I am not sure how well these e-mails reflect the real thing, but they confused me for a while. The give away that this is a fake is the from e-mail address as well as the link leading to a different site then advertised.

Click on the image for a full size example.

[Update:] An analysis of this phish by Trustwave's own Spiderlabs can be found here: http://blog.spiderlabs.com/2013/02/more-on-the-trustkeeper-phish.html 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Usually, we find that e-mail used to trick users to malicious or spam sites is either not customized at all, or manually tailored for a particular recipient. A couple years ago at our RSA panel with Alan Paller and Ed Skoudis, I eluded to "mass customized" malware. Malware that automatically harvests social networking accounts or other open source information to find out how to best target you. For example, the malware may see that you "Like" Star Trek on Facebook and then will send you a link to a new movie trailer.

For a while now, I am seeing simple e-mails that appear to be doing something like that. The emails follow the same pattern. The "Real Name" displayed is the name of a person I know. The from e-mail address however has no relation to the person, and is usually some kind of free email 'yahoo'/'gmail' style address. The body of the e-mail itself is just a one liner with a link.

I did suspect Facebook as the source of the information. For most of the "senders" I had gotten these e-mails from in the past, there are other ways then Facebook that link me to them. But wasn't sure about it until now, when I received the e-mail below.

"Orlando Fermi" is the name for the Facebook page of my cat. I don't think there is anything else that links me to this particular name. The URL no longer works (for me at least... getting a 404 right now). But I would suggest you don't try it out.

In the past these e-mail led to various exploit kits, and on occassion spam. But it may also happen that an exploit kit will redirect you to spam if it doesn't have the right exploit for you. My cat's Facebook profile is public (sort of on purpose) and well, Mr. Fermi is a pretty mean cat so I wouldn't click on any link he sends me anyway which is one reason I didn't fall for this one. 

And BTW: If you do happen to visit RSA: Ed, Alan and myself will have this years panel on Wednesday 9:20am in room 134. Lots of interesting stuff this year about targeted attacks, DDoS attacks and things like mobile malware stealing two factor auth tokens. (as usual, check the program guide for changes in room/time).

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Last weekend I attended a presentation by Liam Randall (@hectaman) on the Bro networking language.  It helped break though many of the assumptions I had about it and encouraged me to take a second look at using it the lab.  His talk is available on you-tube and slides are available here: http://www.appliednsm.com/shmoocon-2013-bro-slides-and-video/

"I have snort, why do I need another IDS?"

That pretty much summed up my thoughts about BRO.  Liam described most people's NSM stack as: tcpdump for capture, wireshark for analysis, argus for flow data, snort for alert data, and python to script interactions.  When he siad that BRO could replace each of these tools I was a mix of incredulous and intrigued. The key point that helped me understand was the explanation that Bro is a domain-specific language for networking applications and that Bro-IDS (http://bro-ids.org/) is an application written with Bro.

So, what else does it do?

Basically Bro generates Events from traffic, and these Events drive Actions or generate Structure Output.  If you've ever had a need to script something quickly to process the output of tcpdump, you'll see the appeal of Bro that dumps traffic out in an orderly fashion that's very UNIX command-line friendly.

Using something like Liam's fire-scripts (https://github.com/LiamRandall/bro-scripts/tree/master/fire-scripts) you can explore how protocols are being implemented on your network.  While wireshark does an outstanding job of coloring protocols and identifying flows, Bro scripts do a better job of identifying the order of events and counts of events in a session (helpful for looking bots that are pretending to be Internet Explorer or SSL/TLS shenanigans.)

Bro can be scripted to extract every executable that flies by on the wire. While this can be done with a few key-clicks in wireshark or batched by using tcpflow, Bro allows you to make it part of the analysis process which you can then kick off other static analysis or additional alerts.

How do I get started?

The shortest path to playing with Bro is via Security-Onion: http://code.google.com/p/security-onion/  It's an .iso that you can either boot-up with or build a VM from.

What are you using Bro for?

While Googling around to verify the links for this entry, I see a lot of interesting SSL/TLS projects and APT1-related modules and scripts.  For those of you who are using Bro in your processes, leave a comment below.

I'm certain that something like this has happened to you.  You're at work/home/shopping and a friend/coworker/family-member asks/phones/sends-a-telegram to you basically stating: "My computer is acting strangely, do you think I have a virus?"

I had this happen this week so I asked: "describe strange."

So they listed off some symptoms:

• slow to boot
• takes a while for the computer to catch up to what you're typing
• can't get rid of this silly toolbar
• password to (some service) is no longer working

"Stop right there.  I know what the problem is, you've got (fill-in-the-blank-banking/keylogging trojan,) so you need to rebuild you system."

"Now's not a good time to do that.  Is there anything else you can do?"

"Yes, but I don't recommend it."

What You Should Do

The correct response when suspecting a compromise like this on a non-enterprise device is to simply buy a new hardrive and an external enclosure for you old drive.  Then install fresh, and migrate what you need from the old drive.  It's time-consuming and a hassle (because people invariably install a bunch of things on their systems and forget passwords and license keys, etc.)  But it's the only way to be sure, and it's non-enterprise equivalent to nuking-from-orbit.

What I Did

Becuase I'm sensitive to the realities of life and the solution above does not fit all cases.  I started off with a quick assessment of the device.  Using Autoruns (http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx) the slow boot problem was pretty obvious-- there were at least 3 different anti-virus programs running on the system and competing for resources.

Since we agreed that we weren't going to seek prosecution on this incident, "just clean it up and get it working again," I just dove into ripping out all of free/demo AV programs, and some of the other bloatware introduced by the manufacturer.

That fixed the performance issues on the next reboot.  But how do we keep the machine safe?  We picked one AV solution.  I'm a fan of defense-in-depth, but multiple AV programs is no defense-in-depth, it's width... or something... anyway it's not good.  I also recommend an up-to-date browser and if you use Firefox I really, really recommend NoScript(http://noscript.net/), and healthy dose of paranoia when it comes to clicking on things.

Was the System Compromised or Just Over-protected?

So I'm still left wondering if the system had an undetected infection, so I dropped a Redline collection agent (http://www.mandiant.com/resources/download/redline/) on the box  to pull a comprehensive memory analysis.  Before I run the capture, I open the browser and go to my bank's website and I put in bad username/password pair, and then run the capture. 

Golly that takes a while to run (about 2 hours on a 4Gb system, creating 6.5Gb of data.)

After plodding through with Redline and Volatility I haven't uncovered anything yet... yet.

Going over some data earlier today, I noted that a few days ago, we had a notable spike of port scans from Iran in our DShield database. Iran is "spiking" at times, in part because we figure only a relative number of actors are scanning from Iran. So lets see what was going on. First, a plot of the activity from Iran for February:

Click on the image for the full size. This data is fairly "rough" as it is just counting number of dropped packets. This could be one host sending the same packet over and over to the same target. (ok... about 2-3 Million times on the peak days)

Lets look at the ports affected next. Below you will see the data for February 16th:

+------+--------+
| port | count  |
+------+--------+
|   21 | 466735 | 
|   53 | 465751 | 
|   23 | 458511 | 
|   22 | 457712 | 
|   80 | 455077 | 
|  179 | 453416 | 
| 3389 |   5750 | 
|  445 |   4926 | 
| 4614 |   4721 | 
| 5900 |    356 | 

This is getting a bit more interesting. the top 6 ports have almost the same number of "hits", and they are well known server ports. 179 (BGP) is in particular interesting as it is not scanned a lot and more of an "infrastructure" port. But one could expect routers to respond on 23, 22 and 80 as well. 21 and 53? Not exactly router ports.

One host that sticks out for port 179 scans that day (port 179 is easier to investigatate as there are less scans for this port then the others), is 213.217.37.102 .

Scans originating from this particular host confirm the original picture:

+------------+---------+---------+
| targetport | reports | targets |
+------------+---------+---------+
|         21 |  386903 |     368 | 
|         22 |  379809 |     363 | 
|         23 |  380493 |     365 | 
|         53 |  387051 |     365 | 
|         80 |  374014 |     360 | 
|        179 |  378105 |     366 | 
+------------+---------+---------+

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

NOTE: The site is STILL compromissed right now. DO NOT VISIT.

This is more of an "awareness" item to show to coworkers and relatives that you can't be careful enough. "bible . org" is a site that offers as the name implies access to the bible and related commentary as well as translations. Sadly, earlier this week the site go appearantly compromissed. The owner was notified, but didn't have the means or skills to clean the site so far. 

Like in so many cases, the exploit inserts javascript at the very top of the page. Likely this may have happened via a compromised configuration file. But right now, we don't know. The malicious content is only shown to some browsers based on the user agent string. So a plain wget or curl won't get you the malware. You need to specify the user agent string (for wget, setup a .wgetrc file to do this automatically, or use the -U switch).

The exploit inserts an iframe with changing URL following the pattern http://[random string].ddns.name/b6noxa1/counter.php?fid=2 (the domains I saw have been reported to changeip.com ). 

The wepawet analysis [1] shows that at least one Adobe PDF vulnerability is being exploited, luckily an older one (CVE-2010-0188), but there is an additional PDF that webawet didn't analyse. It can be tricky to retrieve all components of these exploit kits from a non-vulnerable or simulated browser.

[1] http://wepawet.iseclab.org/view.php?hash=ae81a29e04bd93994c1f92411e58975a&t=1361545134&type=js

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Users of tumblr, and likely the other sites mentioned in the subject line, received an e-mail informing them of a breach of a company called "Zendesk". Like myself, you may not have heard of Zendesk before, but they appearantly process customer support e-mail for these sites, including like in the Tumblr case, e-mail to aliases like lawenforcement@ and legal@. According to Zendesk, the attacker retrieved email addresses and subject lines, not e-mail bodies. According to the Zendesk home page, there are many other namebrand companies that are using Zendesk, but the breach notification mentions only the three I listed in the subject.

Lessons learned:

• yet another "internet chokepoint" nobody thought about. A company like Zendesk, dealing with customer support for several large internet properties is a great point to monitor and collect intelligence as well as spreading malware. None of this has happened here.
• Limit confidential information in customer support e-mails. NEVER mention a password. But other information should be limited to what is necessary to describe the problem. Of course, this may have to include sensitive data (account numbers, software versions and configurations.

<Opinion>

With all the "Bad stuff" happending, we dodged some bad bullets this week. The NBC compromisse only led users to a rather old exploit. This Zendesk exploit didn't get very far (no e-mail bodies). The Bit9 exploit, even though it lasted for 6 months or so, was only used against 3 targets. Facebook/Apple developer compromisse didn't lead to backdoored code (we hope).

I think in particular the use of a "lame" exploit in the NBC case kind of points to another problem: It was probably pretty easy to deface the site. 

</Opinion>

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

VMware has released the following new and updated security advisories:

New:

VMSA-2013-0003 http://www.vmware.com/security/advisories/VMSA-2013-0003.html

Updated:

VMSA-2012-0018 http://www.vmware.com/security/advisories/VMSA-2012-0018.html

VMSA-2013-0001 http://www.vmware.com/security/advisories/VMSA-2013-0001.html

Chris Mohan --- Internet Storm Center Handler on Duty

If you've been keeping up with the world of information security this week, you are probably a bit overwhelmed.

Lots of important patches were released in the recent days, as we outlined in the Update Palooza diary, including Java and Adobe Reader and Acrobat updates. We saw instances of SSHD servers compromised and are still unsure of the attack vector. High-profile sites, such as NBC and EDUCAUSE were breached. There has been lots of talk of targeted attacks, especially after the release of Mandiant's APT report and  its subsequent misuse. And this is just a set of items reported here at ISC.

What, if anything, should we be doing now that we weren't doing a week ago? One possible advice is to stay vigilant: be careful what attachments you open and which links you click on. Unfortunately, that is not very practical advice, though one that is hard to resist offering. Perhaps more practical advice is to remind you to pay attention to logs and IDS alerts, spitting incidents and responding to them in a prioritized manner. Also, please take a careful look at the vulnerability posture of systems in your organization. Examine the patches that were recently released. If you've been waiting to push out those updates, especially if they patch client-side applications, now is a good time to focus on that task.

It's a dangerous web out there. But you already knew that, didn't you?

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.

There are a lot of discussions at the moment about a SSHD rootkit hitting mainly RPM based Linux distributions.
Thanks to our reader unSpawn, we received a bunch of samples of the rootkit. The rootkit is actually a trojanized library that links with SSHD and does *a lot* of nasty things to the system.

At this point in time we still do not know what the initial attack vector is – it is unknown how the attackers get root access on the compromised servers that is needed to change the legitimate libkeyutils library with a trojanized one. We are, of course, keeping an eye on the development and will post a new diary or update this one if we receive more information about the attack vectors.

The trojanized library is very, very nasty. Upon execution it performs a number of actions, as described below.

The code first deobfuscates the text strings needed for it to work. The original text is only XORed so this is very easy to retrieve and the deobfuscated strings have already been posted on a lot of sites.

Once that has been done, the library sets up everything needed for it to work. It resolves symbols for the following functions which are used later: PEM_write_RSAPrivateKey, PEM_write_DSAPrivateKey, MD5_Init, MD5_Update, and MD5_Final. As you can already see, it is definitely messing up with the authentication mechanism.

Besides resolving the symbols, the library also hooks the following functions: pam_authenticate, pam_start and crypt as well as audit_log_user_message and audit_log_acct_message. By hooking these functions, the rootkit can modify the flow of the SSHD – as you can see, this is a user-mode rootkit, as it does not affect the kernel.

The main activity of the rootkit consists in collection of credentials of authenticated users. Notice that the rootkit can steal username and password pairs as well as RSA and DSA private keys, so no matter which authentication mechanism you use, if the target host is infected it will successfully steal your information. The hooking of audit_log* functions was done to allow the attacker to stay as low profile as possible – if the attacker uses the hardcoded backdoor password to issue any commands to the rootkit, no logs will be created.

The current version of the rootkit supports three commands: Xver, Xcat and Xbnd. The first command just prints the rootkit’s version; the Xcat commands print the collected information back in the session for the attacker while the Xbnd command allows the attacker to setup a listener.

Besides this, the rootkit can automatically send collected credentials to the attacker. In order to do this the rootkit has a DGA (Domain Generation Algorithm) implemented that will create random looking domain names in the .biz, .info and .net domains (in that order). It will then send a DNS packet containing collected credentials to the target IP address, if it was able to resolve it (meaning the attacker has registered that day’s domain). If no domains have been resolved, the DNS packet is sent to the hard-coded IP address, which in all samples we received was 78.47.139.110.

The rootkit itself looks very similar to the Ebury trojan which was detected back in 2011. In fact, I’m pretty sure that a lot of the code has been directly copied, however, the Ebury trojan patched the whole SSHD and required the attacker to change it.

This was easier to detect and prone to being overwritten with patching. The libkeyutils library, which comes as part of the keyutils-libs package is not changed that often so the chance of it being overwritten automatically is much lower.

If you run a RPM based system you can check the integrity of the file with the rpm command:

# rpm -Vv keyutils-libs-1.2-1.el5
........    /lib/libkeyutils-1.2.so
S.5.....    /lib/libkeyutils.so.1
........    /usr/share/doc/keyutils-libs-1.2
........  d /usr/share/doc/keyutils-libs-1.2/LICENCE.LGPL

This will check a lot of things, the most important being the MD5 checksum so if you see the output as one above you have a trojanized library. Proper output should have all (and only) dots. Keep in mind that the RPM’s verification, of course, depends on the integrity of its database and the kernel itself.

We will keep an eye on the development and will update the diary accordingly – if you have samples or more information, especially on what the initial attack vector is please let us know.

I’d like to thanks again to unSpawn for supporting the SANS ISC.


--
Bojan (@bojanz)
INFIGO IS

On the heels of Mandiant's report APT1: Exposing One of China's Cyber Espionage Units, attackers are circulating malicious versions of the PDF document. It's a clever social engineering scheme that can be used for the types of attacks that Mandiant's report described.

Symantec discovered "targeted attacks is using the report as bait in an attempt to infect those who might be interested in reading it. " The fake report was distributed as an email attachment named Mandiant.pdf according to Symantec and targeted the CVE-2013-0641 vulnerability in Adobe Reader and Acrobat.

Brandon Dixon came across another malicious PDF file that seemed to follow a similar meme and was named "Mandiant_APT2_Report.pdf". According to Brandon, the malicious PDF file was distributed in a password-protected PDF file. The file infected the system with malware and displayed to the victim the original Mandiant APT1 report.

These incidents illustrate how quickly and cleverly the attackers can devise social engineering schemes to target victims in specific organizations, sectors or professions. The audience of Mandiant's original report is likely of interest to the types of attackers that the report profiled.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.

We became aware that the NBC[.]com website is redirecting to malicious websites that contains exploitkit.

At this point it seems like most of the pages contains an iframe that is redirecting to the first stage of the RedKit exploit kit.

Some twitter users are already poiting out some of these bad pages.

Some of bad iframes public known are:

hxxp://www.jaylenosgarage[.]com/trucks/PHP/google.php

hxxp://toplineops[.]com/mtnk.html

hxxp://jaylenosgarage[.]com

The Redkit exploit kit will deploy the banking trojan Citadel.

We will update this diary when more info become available.

---------------------------

Pedro Bueno (pbueno /%%/ isc. sans. org)

Twitter: http://twitter.com/besecure

If you are easily confused like me, you may appreciate this quick summary as to the different updates released the last couple of days:

Oracle Java:

• Java 7 Update 15
• Java 6 Update  41

Mozilla

Firefox 19

Apple

(in addition to Apple's Java update to the versions shown above)

iTunes 11.0.2.25

Adobe

• Flash Player Windows 7 and earlier 11.6.602.168 (Windows 8 and OS X is still use 167)
• Acrobat/Reader 11.0.02 (went live on Adobe's FTP server Wed. 20th morning)

Probably the most dangerous thing you can do when applying patches is to rush. You may not only end up with a broken system, but worse, the patch may not be applied correctly. Take the time to test that you are all up to date. Encourage your coworkers and relatives to visit browsercheck.qualys.com to test if all plugins are installed correctly.

(we may update this diary for a day or two)

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

UPDATE

More updates arrived:

• Thunderbird 17.03 arrived yesterday. It fixes 8 security vulnerabilities.
• Apple released yesterday iOS 6.1.2, which can be downloaded fast as it is small (12.8 MB). So far, this update seems to be only related with a bug on echange calendars that increases network utilization causing battery drain. Better to have last version installed as apple does not always list in a detailed way all the fixes contained in an operating system update.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

7 days ago finished the eight version of the SANS SCADA Summit at Orlando. Conferences were really great and it was a great opportunity to see that I am not the only CISO that is having trouble developing and implementing an information security program to the ICS world of the company. The most important conclusions obtained back there are:

• Operators and professionals from the industrial world does only care about the process: they want it efficient, reliable, available all the time and simple. When we, the security people, try to implement some control measures to avoid risks from being materialized, we need to preservate all those attributes to the process. Let's keep in mind that if we cannot improve the ICS process with our controls, the business won't let us do anything and they prefer to suffer the risk materializing than let us try to avoid them.
• Compliance is a consequence of implementing a good security program. Choose a good framework to implement and begin working. Examples of such frameworks are:
  • NERC CIP
  • ISA (Industrial Automation and Control Systems Security) 99 IEC 62443
  • 20 Critical security controls
  • NIST GUIDE to SCADA and Control Security
  • CFATS (Chemical Facility anti terrorism standards)
• As you definitely need to avoid increasing the complexity on the SCADA System operation, you cannot allow irregular acess to your operators to resources outside the Industrial Control System (ICS) network. That means not allowing to read e-mail and not accessing the Internet from the same computer where a Human to Machine Interface (HMI) is installed. They can always use other computers that have access to the IT world.
• As I stated, the ICS guys only cares about their process and tent to disregard anything that might cause problems or make them feel they are doing their work in a slow way. Therefore, a strong awareness campain is needed pointing to strong motivations like cyberterrorism and materialized risks to the SCADA and ICS systems.
• Firewalls are good but not enough to protect risks from SCADA and ICS systems. You need to add other controls like SCADA application whitelisting, Host Intrusion Prevention Systems, Network Intrusion Prevention Systems and patch management.
• Patch unpatched vulnerabilities of your SCADA and ICS systems. If fore some reason the product cannot be patched, take any other approach to lower the risk to the minimum possible value.
• Include the ICS environment to your information security risk matrix. You need to start including it inside your controls. Otherwise, information security risks will become unmanageable to your SCADA/ICS.

SCADA/ICS systems manages critical infrastructure and could be a target addressed by any irregular and ilegal group. For all us who work to companies where SCADA/ICS systems are vital to business, it will become the most important information asset to protect, as it could be used to destroy all the assets used to ensure company's future money.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org 

Apple has also provided an update for JAVA http://www.apple.com/support/downloads/ Update 13 addresses a number of security issues and should be applied to Apple systems sooner rather than later.  Details on what the java update fixes can be found here http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html

Not sure whether this addresses the issue that has been reported in relation to the breach of apple, which according to the articles I've seen have been atributed to a java issue.

Mark H

Educause, the keeper of the .edu TLD, is reporting that a server used to hold user profiles was breached and data was exfiltrated. For the most part, this will not affect our readers, unless you are in charge of a .edu domain, and do have an account with EDUCAUSE as a result. You should have received an e-mail from EDUCAUSE asking you to reset your password. Evidently EDUCAUSE uses informz.net to send these notices and we had readers suggesting that they are phishing emails. Regardless: Don't click on the link in the e-mail. Go to the EDUCAUSE site and change your password if you think you may be affected.

http://www.educause.edu/sb

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(I originally wrote "update 14", but turns out this is update 15)

Oracle released update 15 for Java 7 and update 41 for Java 6 today. I haven't seen any specific security content yet, but Oracle states that "The highest CVSS Base Score of vulnerabilities affecting Oracle Java SE is 10.0" , which is the maximum possible score and indicates remote compromisse.

Apple users: If you think you are safe, check today's news about how Apple itself got compromissed via a Java vulnerability (maybe this is why Apple was so quick in disabling the Java plugin via X-Protect).

http://www.oracle.com/technetwork/topics/security/javacpufeb2013update-1905892.html

once you are done patching (if you still have Java installed), head to browsercheck.qualys.com to make sure all the other plugins are up to date)

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

The label of "state sponsored attacks" or "advanced persistent treat" has been used and abused frequently in the last few years. Hardly ever have we seen any "hard evidence" of how these attacks happen, and who is behind it. The report by Mandiant that made the news this week is probably the best public summary of these attacks listing conclusive evidence linking the attacks to the chinese government.

Attributing cyber attacks is always very difficult. IP addresses don't really mean much as attackers frequently use chains of compromissed machines to attack the ultimate target. The Mandiant report uses additional evidence and does a very good and thorough job in tracing the attacks.

But what does it mean to you?

First of all: Read the report (the original, not the press releases and commentaries): http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf . Direct management to the video that Mandiant made.

The report also includes lots of IP addresses and other indicators that you can use to check your own networks for similar compromisses.

The attacks follow a very tried and true pattern:

• send an e-mail to the victim.
• the victim will click on a link or an attachment
• an exploit will be used to compromisse the users system
• additional software will then be used to establish a foothold and exfiltrate data

What can you do about this? 

At each step, try to see how you could possibly intercept the attack. For example conduct your own phishing exercises. With permission, register a hotmail/gmail/yahoo mail account using an executive's e-mail address. Sent an email to all employees using this from address and see how many people click. Direct them to a nice but educational page telling them how they may have been "hacked" this way, and what to look for.

This way, you gain a bit of awareness, but you also gain hard numbers on how many people in your organization would have clicked on the link. This is critical to demonstrate the size of the issue to manage to obtain resources to defend agains tthis threat. 

Next, to prevent the infection of the system. Patching still helps. Not all attackers use 0-day attacks. But more importantly, reduce the attack surface by removing unneeded software (Java, Flash, Office...) . Office may be a hard one to remove, but limit it to the pieces of the package that are actually needed. It will save you on licensing fees too.

Consider whitelisting. While not perfect, if done right, it is a lot better then anti virus.

And finally in this very brief list: Don't forget some kind of exfiltration or data leakage protection. Look for anomalies more then for signatures. The better you know what is normal on your network, the better are your chances to detect "bad stuff".

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Last week Adobe's PSIRT Team published an advisory on vulnerabilities affecting Adobe Reader and Acrobat. Yesterday they published an update that they plan to release a patch to resolve CVE-2013-0640 and CVE-2013-0641 this week.

[1] https://isc.sans.edu/diary/More+adobe+reader+and+acrobat+%28PDF%29+trouble/15151
[2] http://www.adobe.com/support/security/advisories/apsa13-02.html
[3] http://blogs.adobe.com/psirt/2013/02/schedule-update-to-security-advisory-for-adobe-reader-and-acrobat-apsa13-02.html

(fixed typo in response to carpenter jokes below ;-) )

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

If you are using HP ArcSight Connector Appliance (v6.3 and earlier) and Logger (v5.2 and earlier), some potential security vulnerabilities have been identified which could be remotely exploited to allow information disclosure, command injection and cross-site scripting (XSS).

HP recommend to contact support to request the current updates for ArcSight Connector Appliance (v6.4) and ArcSight Logger (v5.3) to resolve these issues. Additional information available here.

[1] http://h20565.www2.http.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?docId=emr_na-c03606700-1&ac.admitted=1361054958795.876444892.492883150

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

RedHat released a vulnerability today impacting PTRACE_SETREGS.  The release simply states: "A race conditon in ptrace can lead to kernel stack corruption and arbitrary kernel-mode code execution. A local unprivileged user could use this flaw to elavate his privileges."  It is being tracked as CVE-2013-0871.  A PoC was also posted at http://seclists.org/oss-sec/2013/q1/326.  According to the advisory, it impacts all Fedora versions.

One of our readers has come across traffic leaving the network with a destination of CN and a destination port of tcp 8520.  

If you are seeing the same I'd like to know, even better if you have a capture of the traffic including the payload that would be great. 

Cheers

Mark H 

Recently I’ve been working on several incidents that included attackers getting shell access to the compromised host and somehow elevating their privileges to root. Of course, once they have access to the box, one of the first things they want to do is to be able to establish that same level of access again.

While there are many, many ways for an attacker to plant a backdoor that will allow him access to the server later, the easiest way is, of course, to create a new, privileged account that the attacker can use to access the server.
Now, when analyzing what happened during the attack we figured that this was exactly what the attacker did, however there were no logs on the system and subsequently the central logging system and SIEM implemented by the victim were of no use.

As this was a Linux server, you can probably already guess what the attacker did: they simply opened the /etc/passwd and /etc/shadow files and added their backdoor accounts (with an UID of 0). Of course, since they did this directly by modifying the system files there were absolutely no logs.

Very simple, yet also very effective!

So, what can we do against this? One obvious answer is to monitor any changes to these two and some other important files (for example, /etc/hosts, /etc/sudoers .. there are actually many). On Linux servers it is actually really easy to do this thanks to auditd – the Linux Audit daemon.

Auditd is the userspace part of the Linux Auditing system, which integrates deeply with the kernel. Being integrated with the kernel allows it to inspect every little detail of what’s happening on the system. In fact, many administrators turn auditd off due to huge amounts of logs it can create, and potential performance impact on the system. However, it is a true gem in auditing, if used correctly.

In our example on monitoring /etc/passwd we just need to add one rule to the /etc/audit/audit.rules file:

-w /etc/passwd -p wa

This tells auditd to monitor and log any changes (trigger on write and attribute change of the file). So when our attacker tries to modify this file directly, we will get log similar to the following:

type=SYSCALL msg=audit(1360781410.961:24122): arch=40000003 syscall=15 success=yes exit=0 a0=8357590 a1=81a4 a2=1 a3=1 items=1 ppid=17480 pid=8437 auid=510 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=210 comm="vim" exe="/usr/bin/vim" key=(null)
type=CWD msg=audit(1360781410.961:24122):  cwd="/etc/audit"
type=PATH msg=audit(1360781410.961:24122): item=0 name="/etc/passwd" inode=4786344 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00

Pretty cool! So we had the UID and GID of the user who modified the /etc/passwd file, as well as the full path to the process (command) that was used to edit it.

Since auditd creates logs in /var/log/audit/audit.log, we can now send the same file to our SIEM and create a rule to trigger an alert on such actions, so we can catch any modifications to this (and other) system critical files.
For the bonus part, we can even setup a simple cron job (it will suffice in most cases) that will calculate an SHA1 sum of the /etc/passwd file, trigger on any changes and do a diff on the old file (saved before) and the new one.

What other things do you do to monitor your critical files? Let us know!

--
Bojan
INFIGO IS

While lacking any kind of detail, Adobe's PSIRT team is reporting that they are aware of "Adobe Reader and Acrobat XI (11.0.1) and earlier versions being exploited in the wild".

--
Swa Frantzen -- Section 66

This month Adobe decided to fix its Flash and Shockwave players for Black Tuesday:

APSB13-05 tells about the fixes for CVE-2013-1372, CVE-2013-0645, CVE-2013-1373, CVE-2013-1369, CVE-2013-1370, CVE-2013-1366, CVE-2013-0649, CVE-2013-1365, CVE-2013-1374, CVE-2013-1368, CVE-2013-0642, CVE-2013-0644, CVE-2013-0647, CVE-2013-1367, CVE-2013-0639, CVE-2013-0638 and CVE-2013-0637. The fixes are for Flash Player, AIR and AIR SDK.

APSB13-06 tells about the fixes for CVE-2012-0613 and CVE-2012-0636 in the Shockwave Player.

--
Swa Frantzen -- Section 66

Overview of the February 2013 Microsoft patches and their status.

One of the emails that came through on our handlers list pointed out some interesting behavior.  When querying a domain (a sample in this case is shineecs.com), the registrar at the end of the response would include an HTML script tag.  See output below:

When manually fetching that script, all that was retrieved is: document.write(""), so nothing is modified at this instant in time.  The domain in question resolves to an IP that has been implicated in a small number of instances of malware connected to some worm activity, but nothing deeply out of the ordinary.  The same is true for the IP connected to the registrar.  So why is this happening?  The registrar is doing this as a lazy way to do some analytics they find useful, so not malicious in this case.

What is fun, however, is that when I run a WHOIS via the various web tools, most all of them process this HTML tag as HTML instead of text, which means this would be a successful XSS vector if you could maliciously modify a WHOIS record.  

In this case, the registrar adds that script tag, not the registrant.  That said, if a registrar doesn't properly validate the information put in those fields, evil may ensue (the registrar I use does).  Or worse, if the registrar themselves are a bad player, they can do whatever they want.  In this case, an innocous issue, but another episode in the ongoing saga of web applications.  If you get input from a third-party source, make sure to scrub it to ensure that "bad things don't happen" like XSS.  

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

Looks like next tuesday will be a busy patch tuesday. Expect 11 bulletins fixing 57 vulnerabilities. Most of the bulletins affect Windows, but we also got one for Office, two affecting Internet Explorer and one affecting server software. It is a bit odd to see two bulletins affecting Itnernet Explorere instead of just one "roll up patch". 5 of the bulletins are ratesd critical.

Also note that Microsoft released an update for the Flash Player for Internet Explorer 10 today, in sync with Adobe's update for flash player [2].

[1] http://technet.microsoft.com/en-us/security/bulletin/ms13-feb
[2] http://technet.microsoft.com/en-us/security/advisory/2755801

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

The Friend

Does anyone have a friend that regularly still sends you crap via email that usually includes a link or some pic's?  We are all IT security professionals here and know the preacher's drill on this topic. Really, we do not like wasting our time on the junk that is sent to us. Delete, Delete, Delete.

The page loads...

Now.  We Need To Know

Did we just infect our system?  

We need to know.  It is time to act fast.  Get to a shell and pull that page down with a text browser ala wget or curl.   It is possible for this page to disappear quickly.  This sample was sent in by a reader who acted fast.  By the time I got around to verifying some things on this sample, the below pasted code was gone.

There are many diaries posted about javascript obfuscation over the years.  The two that rise to the top are from Tom Liston [1] and Daniel Wesemann [2] .  If your interested in understanding this process further by diving in deeper, I recommend those diaries as required reading.
 

 

The Lazy Liston

 

I deployed a mixture of Tom's method and Daniel's lazy method. (see diaries mentioned above for more info)

 

I stripped the HTML, reformatted the Javascript, and added some useful lines for debugging. The image is highlighted with red showing my additions, blue showing unnecessary HTML, and black showing the javascript code that gets debugged.

I used jsc to help me out with the prepared script above.  jsc is a command line utility that allows you to run javascript interactively.  I inserted a debug and a couple of readline statements to assist.  The readline allows me to pause the script to view the output.  Pressing enter continues it.  

Below is a snapshot of the jsc run of script.js.   I pasted and circled the obfuscated strings and the decoded pieces.  Note the url listed matches the browser shot up above.

In summary, my diagnosis of the original email and sample with the clickable link, is it is only a spoofed email and intended to be spam.  I humbly encourage all to offer any feedback to counter my assessment or offer any added value to it.  Many thanks to Lode V. for sending it in!

 

[1] https://isc.sans.edu/diary.html?storyid=1917
[2] https://isc.sans.edu/diary.html?storyid=2268

-Kevin

--
ISC Handler on Duty

An interesting blog post by Kristian Kielhofer describes how a specific SPI packet can "kill" an Intel Gigabit ethernet card [1]. If a card is exposed to this traffic, the system has to be physically power cycled. A reboot will not recover the system. 

The network card crashed whenever the value 0x32 or 0x33 was found at offset 0x47f. Kristian first noticed this happening for specific SIP packets, but in the end, it turned out that any packet with 0x32 at 0x47f caused the crash. Intel traced the problem to an EEPROM used in this specific card (82574L). There are some links in the comment to the blog suggesting that others have run into this problem before. For example, the commend: "ping -p 32 -s 1110 x.x.x.x" can crash an affected card remotely.

[1] http://blog.krisk.org/2013/02/packets-of-death.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(This is a guest diary submitted by Bill Parker)

Last week, I was debugging the podcast access script, I came across some interesting behaviour regarding the "Range" header in HTTP requests. The purpose of the "Range" header is to allow for resumable downloads via HTTP. The client may ask the server to only sent a certain part of the page, instead of the entire response. Not all servers (or browsers) necessarily support this feature. The feature is very different from "Chunked encoding", another feature that can be used to break up a page, but not to break it up as demanded by the client.

Client Side / Request

A request may include a range header, asking only for a part of the file. For example:

Range: bytes=0-100

would request the first 100 bytes from the response. The server may ignore this header, and the browser should accept whatever comes back, even if it is more or less then the requested range

Server Side / Response

A partial response always uses the status code 206 instead of 200. In addition, a header indicating the range delivered, and the total length of the file will be included:

From the RFC:

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

The Content-Range header indicates the range delivered, and the number following the / is the size of the file. In addition, you should still see a content-length header.

So what could possibly go wrong? I played with various invalid combinations, and so far, what I found is that the browser will ignore them. I haven't gotten around to test them all with respect to an IDS, but assume that a properly configured HTTP preprocessor will reassemble these ranges. Of course, without preprocessor, there will be a wide range of evasion/insertion attacks.

An issue I found is that some podcast clients will first try to download byte range 0-1, then they will download the file. Most of the time in one attempt, but frequently in multiple ranges. This can confuse web log analysis software as it will register them as multiple "hits" to the same file. You need at least to look at the status code (200 vs. 206). Also, the clients did not access the complete file if the server returned the entire file instead of just bytes 0-1. 

It is also possible to specify multiple byte ranges in one request, and older versions of Apache had a denial of service vulnerability if an excessive number of byte ranges was specified.

Let us know if you find anythingelse interesting when it comes to processing the Range header.

References: RFC 2616 http://www.w3.org/Protocols/rfc2616

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

OpenSSL has issued an advisory regarding updates released to address the following issues:

• SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169)
  • Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y
• TLS 1.1 and 1.2 AES-NI crash (CVE-2012-2686)
  • Affected users should upgrade to OpenSSL 1.0.1d
• OCSP invalid key DoS issue (CVE-2013-0166)
  • Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y.    

    
The SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169) is particularly interesting as described in Lucky Thirteen: Breaking the TLS and DTLS Record Protocols.

From their writeup (AlFardan and Paterson):
It's called Lucky 13 because the TLS MAC calculation includes 13 bytes of header information (5 bytes of TLS header plus 8 bytes of TLS sequence number) which, in part, makes the attacks possible. In the context of the attacks, 13 is lucky from the attacker's perspective. At a high level, these attacks can be seen as an advanced form of the padding oracle attack. These new attacks against TLS and DTLS allow a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection when CBC-mode encryption is used. The attacks arise from a flaw in the TLS specification rather than as a bug in specific implementations.
Read Nadhem J. AlFardan and Kenneth G. Paterson's full paper here.

The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2 as well as implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.

Fresh bits available via the OpenSSL project page.

Russ McRee | @holisticinfosec

Last week (30 JAN) Attrition.org (@SecurityErrata) tweeted that the SANS GIAC site was susceptible to cross-site scripting (XSS) via the search field.
XSS is, without question, a vulnerability almost every web application will or has suffered at some point. One need only read Attrition's OSVDB, Secunia Advisories, or Whitehat's website statistics reports to get a feel for how prevalent the issue is. There are many reasons why the vulnerability is #2 on OWASP's Top 10 and SANS, like so many others, is no stranger to the issue as Johannes Ullrich (Dr. J) points out in his ISC Diary entry from 12 JUN 2012.

The particular vector reported last week regarding SANS/GIAC was quite interesting as it was reported as a "simple" XXS. However, upon closer inspection it turns out it was actually quite complicated to exploit and far from simple. Initial reports indicated that the search boxes were vulnerable to simple attacks such as " onmouseover=alert(document.cookie) x=", but the truth was much more complicated. Operating from a place of complete transparency, Brian C from the SANS Web team provided us with explicit details regarding this vulnerability so as to help readers protect themselves from similar issues.
According to Brian, when the web team received the report of the issue they tried all the "basic" CSS attacks and couldn't immediately reproduce the issue. After further research and communication with the reporter, Ryan F figured out how to duplicate the problem, and once verified, the team immediately shut down the search page while they worked on the investigation.  It turns out that, while the attack string used by the original reporter triggered an alert, it was not the same alert they were trying to trigger. The attacker's string was actually dealt with properly by the code,  the alert that was returned was a stored sample from a paper on the GIAC site delivered back to the attacker via the search results. Furthermore, the issue was caused by a compounded series of events, any of which alone would not have presented themselves; thus, the issue was not the "simple" attack that the original reporter thought it was.
Brian stated that root cause was attributed to php "striptags()" functionality. This function is used by PHP to remove HTML tags from strings in order to render them "safe" for display in the browser. When using this function in certain areas of the application the team selectively allows "safe" tags through, an example being the tags used to indicate a paragraph of text (<p> and </p>. The team discovered that while the function does strip tags as it should, if any safe tags are let through it does not check the attributes of the tag.  As a result, any area of the application where striptags() are in use was reviewed. The good news was that most of the places the function was in use, no tags were allowed through. In the other parts of the application the function was not used in conjunction with user input so again the risk was quite low. In addition to reviewing the use of striptags() the team focused on expanding their core validation libraries. These enable whitelisting of attributes which will be used in areas where safe tags are allowed through in order to prevent such issues in the future.
To summarize actions taken, the team:

• Reviewed all uses of the striptags function
• Expanded validation library to check tag attributes when needed

The unfortunate series of events that caused the issue included:

1. The underlying striptags() issue above
2. A paper on the site with an example  of a simple XXS
3. Google indexing the site and converting papers to text for indexing
4. Search string used by the original reporter
5. Section of the paper returned for the search "preview"

This combination of events allowed a JavaScript alert box to display but the alert box was not the "simple" reflected XSS attack the original reporter thought it was. Instead, the issue essentially resembled a stored or persistent attack. This is indeed unfortunate, yet at the same time exploitation would have been nontrivial. Regardless, the SANS Web team will be reviewing logs to ensure no related activity ensues.

Dr. J followed up with the SANS Web team's Ryan C for further technical exploration of the issue. This was indeed a compound problem, not caused by the simple lack of attributes filtering alone. As the application was NOT double-encoding the input it meant that data being sent by Google, which Google had escaped for literal display as part of the search results, was decoded when it should not have been.
As an example:
<div class="description">
Nov 17, 2011 <b>...</b> such as SCRIPT and <b>alert</b> in the uniform resource identifier (URI). <b>...</b> injecting <br>  the script into other places, such as a <b>cookie</b> field. <b>...</b> Jscript onsubmit <br>  copyparentfolder <b>document</b> javascript meta onchange onmove onerror onselect <br>  <b>onmouseover</b> <b>.....</b> &lt;img src=&quot;<b>x</b>:gif&quot; onerror=&quot;window[&#39;al\u0065rt&#39;](0)&quot;&gt;&lt;/img&gt; <b>...</b>
</div>
The above is what was returned by Google and, after running through HTML sanitation, should have been returned to the browser.
According to Ryan C, using the model-view-controller architecture (MVC) pattern, the controller should encode the output before making it available to the view. The view in-turn uses HTML sanitizer to decode and display as actual HTML. However, because double-encoding was disabled in the controller, '&lt;' for instance remained as such, rather than being double-escaped to '&amp;lt;'. The HTML sanitizer re-constituting the HTML in the view, then decoded the '&lt;' to '<' when it should have been converting '&amp;lt;' to '&lt;'.
In summary, as ISC Handler Swa pointed out, the difficulty lay in the fact that snippets of GIAC Gold papers were being sent back and that trying to maintain the formatting by preserving some of the strict HTML created the issue. While the whitelist allowed certain HTML tags, certain attributes such as <div onmouseover=…> were not removed.

Now that we're fully up to speed on the issue, what are some solutions?
Swa reminded us that HTML Purifier is a decent standard library with which to accomplish our mitigation goals above. HTML Purifier is reasonably configurable: it first cleans up the HTML to make sure it is standards compliant to avoid issues with browsers that try to interpret broken HTML, then it removes disallowed tags/attributes.
Dr. J mentioned OWASP ESAPI which is current for Java but is beginning to fall behind in maintenance for the likes of PHP.
Without question, refer to the Top 10 2010-A2-Cross-Site Scripting (XSS) overview which includes the OWASP XSS Prevention Cheat Sheet. Jim Manico's discussion on the Future of XSS Defense is also a great read.
I've long been an advocate for utilizing web application firewall options where possible or applicable. During my years of heavy web application vulnerability research when developers struggled to repair code in a timely or effective manner, I was always quick to mention the likes of ModSecurity as a short-term mitigation that can remain in place after the code fix to allow for defense-in-depth. While a WAF may not have been fully effective in mitigating this oddly chained issue, it can go a long way in blocking the majority of attacks with the likes of the OWASP Core Rule Set (CRS) . Note: ModSecurity for IIS was just voted the 2012 Toolsmith Tool of the Year.

As always, we're interested in your tactics and preventative measures, and look forward to hearing from you.

Russ McRee | @holisticinfosec

In today's world, compromised systems as well as attacks and probes against our networks are sadly becoming the norm.  Because of this, when we see network traffic that violates "normal" behavior, our first reaction is that someone is doing reconnaissance, we have been compromised or we are under attack.  We all want to be proactive and stop the activity, but we also don't want to become the "Boy who cried wolf".  Sometimes the traffic can be outside of what is "normal" but be completely legitimate traffic.  Taking a deep breath and remaining calm while doing the analysis is important.  Ask yourself if the traffic could have a legitimate purpose.  Here are a couple of examples of products that generate traffic that appears threatening, but really are the normal behavior of the system.  

F5 Load Balancer:
I first encountered traffic from an F5 back in 2006.  At that time a reader submitted traffic to us that had the following unusual characteristics:

1.  The repeating IP ID which rotated using only 1, 2, or 3
2.  The windows size was a constant 2048
3.  The TTLs which were usually 44/45 or very close to that.
4.  It was always TCP connections to the primary DNS server.  No UDP traffic was captured from those IPs.  
5.  The 24 0x00 data bytes (keep in mind that these are SYN packets)
6.  The time stamps and source ports were also helpful in determining that these were not TCP retries.

The submitter was not sure what was going on but the traffic certainly was not normal.  I won't rehash the diary here, you can read the diary entry "Packet Analysis Challenge: The Solution" if you like.   The traffic was simply the probes of the F5 Global Traffic Manager.  I am not sure if the L5 probes function the same way today or not.  I do know that the Global Traffic Manager now states this:

By default, big3d agents first attempt to probe the local DNS with a DNS_DOT query. If the probe attempt fails, big3d attempts the following tasks, in the following order:
 •DNS_REV query
 •UDP echo
 •TCP port 53 socket connection
 •ping (ICMP echo)

which can be easily mistaken for a probe/attack against your local DNS server.  In the end, the unusual traffic was normal.


McAfee Rogue System Detection Sensors
With McAfee you can install Rogue System Detection Sensors in your network and manage them via the ePO policies.  These sensors scan the networks to do OS fingerprinting.  You can read about this feature at McAfee's community website.  Here is an example of the traffic you will see if left unmodified:
 
Host discovery
 UDP ports
 53 67 69 123 137 161 500 1434
 
Host discovery
 TCP ports
 21 22 23 25 79 80 110 113 139 264 265 443 1025 1433 1723 5000
 
Service discovery
 UDP ports
 53 68-69 123 135 137-138 161 260 445 500 514 520 1434 1645-1646 1812-1813 2049 31337 43981
 
Service discovery
 TCP ports
 7 9 11 13 15 19 21-23 25 43 49 53 66-68 79-81 88-89 98 109-111 113 118-119 135 139 143 150 156 256-259 264 389 396 427 443 445 465
512-515 524 563 593 636 799 900-901 1024-1040 1080 1214 1243 1313 1352 1433 1494 1498 1521 1524-1525 1541-1542 1720 1723 1745 1755
1813 2000-2001 2003 2049 2080 2140 2301 2447 2766 2998 3128 3268 3300 3306 3372 3389 4045 4321 4665 4899 5222 5556 5631-5632 5800-5802
5900 6000 6112 6346 6666-6667 7000-7001 7070 7777 7947 8000-8001 8010 8080-8081 8100 8888 10000 12345 20034 30821 32768-32790 49152-
49157
 

It can be unnerving if you see workstations scanning your network and your not aware of the functionality of the software.  Again, nothing malicious, just normal software behavior.


Due to time and space, these are only a couple of examples of software/appliances whose traffic falls into the not "normal" range.  Being aware of these can help you save a few gray hairs and make better sense of traffic on your network.  I always find these unusual traffic patterns interesting but they can take a lot of time to research.  The information is not always easy to find and takes some time doing reading and web searches.   If you know of any others, please share them.  If we get enough, we can compile them for easy access as a reference.
 

When I started my shift I was thinking of writing about how it's important to log out of things like Facebook, Gmail, etc. whenever you're not using them.  Then my twitter feed lit up with links to this announcement: http://blog.twitter.com/2013/02/keeping-our-users-secure.html

There are a lot of distractions in the post: references to the New York Times and Wall Street Journal announcement of a compromise, and a warning about updating the java in your browser.  While the NYT/WSJ hack is news worthy and updating your browser's java (or uninstalling it) is a "really good idea"(tm) neither are related to the Twitter incident.  The important bit that you need to look at is this: "investigation has thus far indicated that the attackers may have had access to limited user information – usernames, email addresses, session tokens and encrypted/salted versions of passwords – for approximately 250,000 users."  That's a system-penetration, and while they continue their investigation (which is going to take long time,) they are containing the incident by invalidating session tokens and issuing password resets.

It's good that they share the scope of what was exposed and point out that it was session tokens and encrypted/salted passwords.  It's good news they even use the term salt.

If you have received a password reset message, then you should probably do the following: log out of every one of your mobile apps that interacts with twitter.  From within the web interface of twitter, click on the Settings/gear icon and click on settings.  Click on Apps and it will show you what apps are authenticated and you can revoke access.  See any there you don't recognize?  I was a bit surprised to see a TweetDeck still active from 10-FEB-2012 that had permissions to read, write and direct messages.  Then log out of twitter and follow their instructions to reset your password.  Try to not do this from a shared system or on a public or hotel wifi if you can avoid it.

In general, log out of things.  Log out of linkedin, and foursquare, and facebook, and twitter when you're not using them.  Staying authenticated to gmail or yahoo mail is why your webmail account starts sending out pharmaceutical spam when you happen upon someone's hacked wordpress site.

First off, a huge thank you to readers Ken and Paul for pointing out that Oracle has released Java 7u13.  As the CPU (Critical Patch Update) bulletin points out, the release was originally scheduled for 19 Feb, but was moved up due to the active exploitation of one of the critical vulnerabilities in the wild.  Their Risk Matrix lists 50 CVEs, 49 of which can be remotely exploitable without authentication.  As Rob discussed in his diary 2 weeks ago, now is a great opportunity to determine if you really need Java installed (if not, remove it) and, if you do, take additional steps to protect the systems that do still require it.  I haven't seen jusched pull this one down on my personal laptop yet, but if you have Java installed you might want to do this one manually right away.  On a side note, we've had reports of folks who installed Java 7u11 and had it silently (and unexpectedly) remove Java 6 from the system thus breaking some legacy applications, so that is something else you might want to be on the lookout for if you do apply this update.

References:

http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html

http://www.oracle.com/technetwork/topics/security/javacpufeb2013verbose-1841196.html

Recent Java diaries:

https://isc.sans.edu/diary/Java+0-day+impact+to+Java+6+%28and+beyond%3F%29/14917

https://isc.sans.edu/diary/Java+7+Update+11+Still+has+a+Flaw/14983

https://isc.sans.edu/diary/When+Disabling+IE6+%28or+Java%2C+or+whatever%29+is+not+an+Option.../14947

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu