As I’ve been working quite a bit with Splunk lately I decided to create a DShield for Splunk application that is now publicly available at Splunk base: http://splunk-base.splunk.com/apps/51609/splunk-for-dshield

The idea behind the application is to allow you to have you own, local copy of the DShield database so you can mine data as much as you want.

The application downloads the DShield data (the published All Sources IPs dump) once per day and indexes it into your local Splunk. Once the data has been indexed you can do all sorts of analytics and show top attackers, top attacked ports, their geographical information and much more.

The configuration allows you to specify when you want to download the DShield data (since it’s dumped once per day at 4 AM UTC you should also mirror the data once per day). You can also specify your own IP addresses or networks so the application will nicely list if your IPs have been detected in the attackers list (and, of course, you can change this into an alert).

This is shown in the main dashboard, besides the current Handler on Duty and Threatcon (which are retrieved in real time when you open the dashboard), as well as a panel showing last 10 ISC diaries (so you can jump to them from your local Splunk). The main dashboard is shown below:

Besides this, the application has the following dashboards:
* a dashboard showing top attackers, top attacked ports and protocols
* a dashboard showing Geo IP information about attackers, both in a table and using Google maps
* a search form that allows quick searching by IP address (or CIDR ranges), port or protocol
* a trend dashboard showing number of distinct IP addresses as well as total number of reports DShield received

I hope you will find it useful – if you have any questions or suggestions for improvement please let me know. Also, since Splunk has a free version that allows you to index up to 500 MB of data per day, you can use this for free.

--
Bojan
INFIGO IS

Overview

Ever wondered when, how or why the Internet Storm Center started? Want to know what we do, why we do it and how you can help! We'll summarize the information from https://isc.sans.edu/about.html in this feature and you can click through to read the specific sections in full.
 

Features

About the Internet Storm Center - https://isc.sans.edu/about.html#about
Links to participate in the DShield program https://isc.sans.edu/participate.html and a link to details on the INFOCON threat alert https://isc.sans.edu/infocon.html.

ISC History and Overview - https://isc.sans.edu/about.html#history
Learn about what event prompted the formation of the ISC, how it went down and why.

Behind the Internet Storm Center - https://isc.sans.edu/about.html#behind
Tells about the people that make up ISC and the sensors that make DShield. The who, what and how of the Internet Storm Center and DShield sensor.

Early Warning - https://isc.sans.edu/about.html#early
How the ISC Handlers determine the significance of an event and if/how a warning is disseminated

Participating with the Internet Storm Center - https://isc.sans.edu/about.html#participate
We strongly encourange anyone who is able to contribute logs for analysis, including running a DShield sensor of your own that submits automatically. This section goes into detail of the how and benefits of submitting logs as a registered user. You can get started by visiting https://isc.sans.edu/howto.html.
 

The work is supported by the SANS Institute from tuition paid by students attending SANS security education programs. You can view all the SANS Site Network websites at https://isc.sans.edu/help/site_network or hold your mouse over the up/down arrows to the right of the ISC logo.

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

Reader Yin wrote in after noticing a huge spike in unsolicited border gateway protocol (BGP) traffic. This same spike in BGP connections has also been noted on DShield's sensors [1].  Thankfully he provided a packet capture which contained numerous BGP OPEN [2] messages.

 Here is a snippet of the BGP packet with the relevant details:

These messages all originated from the same system, based in Korea.

The Korean system IP is part of: 

 AS Number          : AS9848

 AS Name            : SEJONGTELECOM-AS

From my understanding of BGP, this system is attempting to pass itself off as AS 65333, a private ASN [3] and poison the router with false details.

Whether misconfiguration or a malicious act is unknown at this point. Most, if not all routers should have basic protections in place to protect against this type of event having an effect [4].

Please let us know if you're seeing the same thing, can added anything further or if my analysis needs correcting.

UPDATE: Thank you to Reader Job for the clarification on private ASNs  

[1] https://isc.sans.edu/port.html?port=179

[2] http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/operation/messages/open.shtml

[3] http://www.apnic.net/services/services-apnic-provides/helpdesk/faqs/asn-faqs#UsePrivateASN

[4] http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/security/index.shtml

Chris Mohan --- Internet Storm Center Handler on Duty

A few days ago I wrote about a few arrests in Belgium in relation to online banking fraud. In the mean time more has surfaced around the globe and the scope of the attacks seem to be much broader than what we knew at the time.

The media are confusing the technically inclined among us, so going back to the source is quite useful: McAfee and Guardian Analytics have published a white paper on these attacks.

--
Swa Frantzen -- Section 66

ISC reader Yew reports that he is seeing a steady increase in probes to tcp/79 ("finger"). Our own DShield sensors confirm this observation, as is visible on the image below. It's been a while since we last had exploit attempts on tcp/79, and hardly anybody is using/running "finger" anymore these days. So .. what's up? Anyone got packets?

Thanks to ISC readers Yin, Doug, Lorenzo, Ron, Jan and Placebo for contributing their data to the ongoing analysis of "Run, Forest!" (JS.Runfore) after our earlier SANS ISC diary last week.  

Here's what we have so far:

• Run, Forest is pretty fickle. They seem to be running an underground web server called "Sutra TDS", and are doing a quite decent job at using this web server's "features" to make analysis hard. Redirection usually happens via two stages of URLs, and only takes place if the correct cookies were set by the prior stage, and the correct referer is provided. It also looks like their web server does geo-location and responds accordingly, and it also black-lists too nosy analysts. If the defenses trigger, the web server responds with "This domain has been suspended for policy violations" or some wording along those lines ... and admittedly, this actually fooled us the first time (aka "Yeeha, someone else already got them"). Turns out that no .. it is just one more clever smoke grenade in the bad guys' arsenal.
   
• If you DO get the exploits, it looks like it currently delivers a regular Blackhole Exploit Kit. The most recent exploit that we've seen included in the package so far was for CVE2012-0507, the Java AtomicReferenceArray vulnerability that affects Java 1.6_30 and Java 1.7_2 and earlier. Bad enough, because there are still lots of unpatched Java installations out there. The other exploits in the pack seem to be for older CVE2010-xxxx vulnerabilities, particularly in Adobe Reader. But don't count on it, the way Blackhole is built, it is quite trivial for the attackers to swap out one exploit against another. That they are not using the latest sploits yet .. simply means that the oldies are still netting the bad guys enough new bots.
   
• If the exploits that we saw were successful, the end result was usually a variant of ZBot, with low detection on Virustotal.
   
• If the machine is well patched and none of the exploits in the pack are feasible, it looks like the kit does some sort of geo location, and then presents a reasonably language and design adjusted variant of Fake AV, in the hope that the user will fall for it and click. We so far had reports of this behavior from Switzerland and Germany only - if you have a full trace of such an incident from its starting "runforestrun" URL all the way through to the Fake AV, we'd appreciate a copy.
   
• If you want to play on your own (be careful!), here's a couple recent Wepawet analysis results
  http://wepawet.iseclab.org/view.php?hash=5e5fbd51d1df4b946917c3710e8058ed&t=1340629274&type=js
  http://wepawet.iseclab.org/view.php?hash=40cc3ddf4bc35ff55880e4740807794e&t=1340630664&type=js
  http://wepawet.iseclab.org/view.php?hash=74cd3f5986b652b6a41dc454380ebf9b&t=1340659298&type=js

How do web servers get infected with Run Forest's initial attack vector?

Good question. All we have so far is that existing JavaScript (.js) files apparently were amended with the obfuscated Blackhole redirect code. Symantec's early analysis suggests that Run Forest comes with a file infector that looks for and changes .JS files.  The sites from where we received infected files didn't have much in common, and also didn't have (sigh!) any useful logs that would have allowed tracking back to the source of infection. If you have additional details, please share!

How to defend

Don't count on anti-virus. While Symantec was quick to detect and name JS.Runfore one week ago, they are now missing the latest versions, pretty much like every other AV Vendor out there.

Here's AV detection for the Blackhole Redirect Script on Virustotal: 4/41
Here's AV detection for the PDF Exploit on Virustotal: 11/42
Here's AV detection for the final EXE (ZBot): 5/42

In a company or university setting, if you can get away with it, block all traffic to 95.211.27.206, which is the IP that has been used by this scam for their 16-byte initial ".ru" URLs for the past week now. Obviously, the IP is trivially easy to change for the attackers, but you might get at least some temporary reprieve to allow the AV companies to get their act together, and catch up.

Your best defense, as usual, is to keep all your software fully up to date, and to make sure all your computer users are educated not to click on scams .. especially not on scams that pop up unexpectedly after visiting a completely unrelated web page.

Let me rephrase that: Your best defense is to go off grid completely, and start growing your own potatoes and cabbage in some remote rural corner of Wisconsin or Idaho. But things are not quite that dire yet :).

Last week Daniel published the diary Run, Forest! If you are using Snort IDS and running some of the Blackhole signatures from Emerging Threats, you most likely noticed they trigger on Blackhole regularly. Using JSDetox, you can finally view the content of these scripts. All you need is a copy of the script and install JSDetox on a Linux system (mine is running on Slackware).

Steps to Decode Java Obfuscated Script

1- Copy the code into the Code Analysis window and select Analyze.

2- The script will then be formatted in the Code Formatted window.

3- Select Execute, then select Show Code and Send to Analyze to show the script in its actual deobfuscated form.

The final result is quite similar to the Wepawet report in Daniel's diary.

[1] http://www.relentless-coding.com/projects/jsdetox
[2] https://isc.sans.edu/diary.html?storyid=13540
[3] http://wepawet.iseclab.org/view.php?hash=e89cfa2fa6a91f90cfeb125c10c1f0f&t=1340389400&type=js
[4] http://rules.emergingthreats.net/open/snort-2.9.0/rules/emerging-current_events.rules
[5] http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/
 

-----------

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

According to this newspaper article (in Dutch), the Belgian government has arrested 2 Russian and 2 Polish nationals -legally in the country- in connection to stealing 3 million EURO through hacking online banking customers.

The article reminds me a lot of a diary we brought in 2007 of a Dutch bank being hacked.In the end they managed to arrest the money mules in that case. It seems they got one step closer to those behind it this time.

It seems customers of 5 large Belgian banks were hit by malware, money was then transferred via mules - who got to keep 5 to 10% of the amount stolen and then our 4 friends above collected it.

Now almost all large Belgian banks use solid protection for their online banking: 2 factor authentication using offline hardware tokens, different procedures for authenticating and authorizing ("signing") transactions -well one of them isn't doing this essential step-, awareness campaigns towards their customers, ...  And still the malware appears to have pulled off the job.

Luckily money leaves a trail that can be followed and lead to arrests of these -no doubt- mere middle men. The investigation is said to focus on a "criminal organization".

Interesting are the numbers they got:

• one bank: 7500 customers for a total of 1836130.52 EURO
• second bank: 4900 customers for 1496012 EURO
• [no data on the other 3 banks]

That's from about 250 to slightly over 300 EUR average per victim - not a huge amount. Still, given enough victims it does add up to significant amounts.

If you're using one of these advanced systems for your online banking: make sure to always validate the transactions before you authorize them, not trusting anything you see on the screen, check what you sign: the amount has to match up! Don't just match up large amounts or most significant digits or so: they're stealing hundreds, not tens of thousands in one go. Also with the upcoming holiday season out here: do only use computers you can trust to be malware-free to do online banking, so avoid cybercafes and other public computers to access your online banking.
Now don't gloat if you're not on one of these systems: you're far more vulnerable.

I've no more details at this point - and with an ongoing investigation we're not going to get all that much details of the malware and/or who's behind it for sure.

--
Swa Frantzen -- Section 66

Microsoft has released an Important update to the Windows Update function (Windows Update Agent 7.6.7600.256) because users have been experiencing update issues. Some users experience failed installation with error code 80070057 or 8007041B. Microsoft has provided a "Fix it" tool that can be directly downloaded here for those cases that won't automatically apply the update and the Knowledge Base article located here. Have you been experiencing this issue? Please let us know!

[1] http://support.microsoft.com/kb/949104
[2] http://social.technet.microsoft.com/Forums/en-US/w7itproinstall/thread/d046bce8-38dd-4be5-8abb-5486200379a6/
[3] http://isc.sans.edu/diary.html?storyid=13453

-----------

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

A number of sites have published an analysis of relatively new malware, ACAD/Medre.A. While we have had some highly specialized malware in recent years like Stuxnet, which targeted Iranian nuclear facilities, and most modern malware seems to have a data exfiltration component, ACAD/Medre.A is somewhat unique in that it seems to be highly targeted and specialized.

The current version of ACAD/Medre.A seems to be targeted at AutoCAD files hosted at IP addresses in Peru. AutoCAD is popular software used to create blue prints, and hardware and chip designs. Obviously these files are valuable intellectual property for the owning company.

ACAD/Medre.A is not just thrown together, low quality malware. Analysis reveals it is well written; at a level that suggests an experienced malware writer wrote it. Some have speculated that this ACAD/Medre.A was been created by a competitor to target a particular Peruvian company.

My belief is that one of two possibilities are more likely. Either it is a limited test of a new malware concept that will be unleashed on the general world in the future. The malware is written using AutoLISP, the AutoCAD built in scripting language. To the best of my knowledge the first malware written in this language. Another possibility is that it is a targeted intellectual property attack by one of the organized malware groups. This malware exfiltrated data to two email addresses in China; while this may provide a clue, it does not really help in identify the involved group.

Who the actors are and what their intentions are is largely irrelevant to us as security practitioners. This type of attack just reiterates that a large part of securing your organization is not technical, but in understanding what data your company owns and needs to protect. Every organization needs policies and procedures for accurately classifying data. Sounds simple in concept, but most organizations struggle to accurately classify data and maintain classification through the data lifecycle. Only once you have a clear understanding of what your most sensitive data is, and where it is stored, can you design and implement controls to protect that data.

What steps have you taken to aid in the accurate classification of your organization’s data?
 

-- Rick Wanner - rwanner at isc dot sans dot org - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Yeah, I know, I probably get the prize for the ISC Diaries with the weirdest titles lately. Blame it on the bad guys, who are showing more creativity in naming their malware than I ever would be able to muster ... and who also don't seem to know the difference between a forest and a Forrest :).

The latest malware sample is what Symantec calls "JS.Runfore". A recent URL might tell you why:

http:// xmexlajhysktwdqe. ru/runforestrun?sid=cx   (don't click)

Plenty of web pages currently seem to be infected with manipulated / changed jsquery files, which contain obfuscated Java Script code that generates the foresty URLs. The domain names generated change based on time and date. "Successful" connections are met by a series of 302 redirects that so far (for me) have not resulted in any real payload. The above URL redirects via moneyold. ru to freshtds. ru, where it ends (for me) in a 404 Error.

Here's a recent Wepawet report for an infected site (OK to click, but better don't click on any of the links in the report)
http://wepawet.iseclab.org/view.php?hash=e89cfa2fa6a91f90acfeb125c10c1f0f&t=1340389400&type=js

Please let us know in the comments below or via our contact form if you have additional information on Forrest (or Jenny, or Lieutenant Dan :).

This initially started off as a diary entry about creating final reports during the Lessons Learned phase of incident response, but I kept referring back to "the timeline" and realized that it needed an entry of its own.

Investigation is all about answering the who, what, where, when, why and how questions. One indispensable tool for organizing this process is the timeline. It can be as simple as a quick sketch in a notebook or as complex as an interactive infographic. It will start off as an un-sorted, un-structured collection of data and if curated properly it will become a tool that will unify your investigation efforts, help identify gaps, and enable you to communicate clearly to management.

What Makes up a Timeline?

The core element of a timeline is the "event." An event can be described as a set of:

• Time-- either precise, or uncertain, (e.g. before Tuesday)

• Place-- physical location, IP address, file-location, etc.

• Person-- the actor, known or unknown

• Action-- the "what happened" part of the event

• Direct object-- if the "what happened" happened to someone or something, this is that someone or something.

Additionally, as events are processed you will want to enrich their entries with:

• Tags-- events will be tagged to help pull out the important events during different stages, as well as help create documents needed later in the investigation
• Evidence-- it's cumbersome and unwieldy to just drop a raw log entry into a timeline, but you will want to provide evidence that an event occurred.

Dealing with Uncertainty

Investigations are constantly dealing with uncertainty. At the beginning of an investigation you have very little information and a seemingly uncountable list of unanswered questions. It's okay to place empty squares on your time line that say things like "victim was web surfing" or leave a blank in one of the time/place/person fields of an event. This helps you call out what you don't know and will help refocus your resources or re-prioritize your efforts. Being able to inventory your "unknowns" is probably a better measure of the progress of your investigation than counting the Gigabytes you've acquired, the number of lines of log files you've analyzed, or other metrics of effort.

Where to Start

When confronted with the empty page, you can start with "when you were informed." This will form the basis of a response timeline. Next you can add events from the report that came in (e.g. the IDS alert, or escalation from your NOC, or 3rd party report.) Gathering events will come naturally as you ask questions about the incident and data comes in. For an example of semi-automated timeline creation I recommend a read of Rob Lee's "SUPER timeline" (http://computer-forensics.sans.org/blog/2011/12/07/digital-forensic-sifting-super-timeline-analysis-and-creation)

Using the Timeline for Coordination

Timeline creation can be spread across multiple teams. For example, your IDS team could build what they see, the firewall team does their part, while system administrators and digital forensic teams will perform their own version of an investigation and can provide you with a list of events. If you agree upon a common tool and standardized format ahead of time, this can allow you to tackle large, complex cases by distributing effort without losing too much context. A very simple format could involve spreadsheets that track: date, time, timezone, person, place, action, tags, evidence link. These could be collected from the different teams, merged, sorted and visualized.

Tagging and Aggregation

Now you've got what seems like a jumbled, insurmountable mess spread across multiple spreadsheets, and stuck in text files-- not to mention crucial details hiding visio diagrams, power points and emails. All of which has references to the memory and drive images that you've taken, the log files you've preserved and the pcap files that were captured. How is a timeline making this any easier?

The timeline is supposed to help you get organized, not clutter everything up. So if you're tasked with coordinating the timeline events from other groups, you will want to settle upon one tool for your own sake. As you're processing/reviewing events you'll want to tag them to note:

• critical phases in the incident response noting when the team determined entry into a new phase (e.g. containment commences, remediation complete)
• the interpreted phase of the attack (e.g recon, exfiltration)
• Control failure/opportunity (e.g. attack identified in system logs, but no IDS alert fired)

You will also need to perform quite a bit of data-reduction to turn a fully-populated timeline into something usable by management and other groups. All of the effort spent tagging events will pay off in this stage since you will be able to easily determine with a little bit of filtering on your spreadsheet (or whatever tool you're using) when recon was started, when the first successful attack struck, when you detected the breach, how long it took to resolve. This is what others are going to be interested in. A set of events can be aggregated and summarized into an overall event renamed using higher-level language, e.g. "Attacker #1 compromises DNS server.

Tangled Timelines?

Even at computer-speed, things rarely happen simultaneously, and one object can't do two things at once. While a lot of events are going to be happening in parallel, you should be able to chain events together into a series of actions. These chains should eventually appear untangled. Even in the case of an ugly internal worm outbreak you should be able to chain one infection to another. If you find that you've got a lot clouds of uncertainty on your timeline, that's just telling you that you have more work to do. It could also indicate that you can't answer those questions, for example the logs are missing or a monitor failed; in that case, flag that as a finding which you'll use later. You may also glean additional insight into the case by examining the blind-spots in the case, or struggling to untangle a set of event-chains. It could be that you're dealing with more than one attacker who happened to leverage the same vulnerability in your network and thus have overlapping incidents.

The Products of a Good Timeline

You should be able to walk through a chain of events and it should feel consistent, and if you've carefully linked to the evidence a compelling narrative of events will emerge. It should be easy to build after-action reports describing the series of events. Metrics for response should naturally come out of the timeline: each phase of the incident response process, time between event and detection, elapsed time from detection to remediation, etc. Preparing a case for law-enforcement should follow naturally from the timeline. The Lessons Learned document can be pre-populated by using the Control Failure/Opportunity tagged events (there are going to be other non-temporal issues like a lack of patches or weak separation of duties.)

You're Doing it Already

If timelines aren't a part of your standard investigative process, you're still very likely subconsciously going through the process. You're collecting the same amount of information was you try to solve the who, what, where, when, why and how questions and you're certainly organizing a chain of events in your head. Your raw case notes probably contains times, places, people, and actions, and you've got log files, and images, and pcaps just waiting to be turned into SUPER timelines. I bet your executive summary is written out as a series of aggregated events.

By keeping the timeline external, and using it to coordinate parts of an investigation, I hope this helps you tackle larger cases with less stress, and less sanity-loss.

Overview

This week features some more tools that will be helpful to skim daily. They are linked at https://isc.sans.edu/tools/#at-a-glance. We've have some pages set up with a variety of information with some overlap so you can use what works best for you!

Features

Quick list of right now, today - https://isc.sans.edu/today.html

• Today's ISC Stormcast! - https://isc.sans.edu/today.html#stormcast
• Today's Diaries - https://isc.sans.edu/today.html#diaries
• Today's HEadlines - https://isc.sans.edu/today.html#headlines

Security DASHBOARD - https://isc.sans.edu/dashboard.html

• More information in a previous Feature at https://isc.sans.edu/diary/ISC+Feature+of+the+Week+Security+Dashboard/12550

Handler Diary Feed - https://isc.sans.edu/rssfeed.xml

• Title Only RSS feed of Handler Diaries for your favorite reader

Consolidated Security News Feed - https://isc.sans.edu/newssummary.xml

• A reduced number of articles from our News Summary page

ISC Site Updates - https://isc.sans.edu/releasenotes.html

• Dated list of notable updates to the ISC/DShield website. Another good way to stay informed about website features!
• Page also has link to https://isc.sans.edu/releasenotes.xml so you can be notified of updates in your feed reader

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

In May I created a poll to sample our readers' preferences concerning the delivery of patches from their vendors.  Do you prefer the predictable delivery of a batch of security advisories and patches?  Or do you prefer a as-they-become-available model? (https://isc.sans.edu/diary.html?storyid=13150)

After the first week, I was surprised that nearly two-thirds of the poll participants preferred the predictable batch method and the few comments that did come in, didn't match up with my expectation that the breakdown would be based on the size of the environment.  Currently it's closer to my expectations showing about 3/4 prefer the "as it becomes available" method.

So, I have new hypotheses and have added a new level of detail to capture in this month's poll.

Considering the results of the poll (https://isc.sans.edu/poll.html?pollid=331&results=Y) did it turn out the way that you expected?

-KL

I thought I'd subtitle this diary more humorously as The Twelve Ways of Pwnmas in celebration of June-uary here in the Seattle area, where it really does rain all the time.

I am priviliged to be party to a wide variety of data and telemetry for malfeasance and evil. One source in particular in use at Microsoft is a list of drive-by attack URLs discovered via detection technology utilized by MSRC Engineering.
From this feed I selected twelve (with me here on the theme?) unique URLs detected as drive-by exploit delivery vehicles bountiful in malicious JavaScript. Unfortunately the reporting for the tool is currently limited only to a basic yes or no response regarding a URL's maliciousness. As such I wanted to dig in to learn more about the attributes of these attacks and share them with you here. To do so I used a specifically configured VM and copied the appropriate obfuscated content between <script> tags and ran it through tools such as Malzilla, Burp's decoder, and JSUNPACK. Obfuscation methods included UTF-16 and HEX encoding, amongst others.

Please note: all URLS herein mentioned should be considered hostile and dangerous. Should you choose to explore, please do so at your own risk with the appropriate prophylactic measures. I will post domains here but not full exploit URLs; I'm glad to do so by request. I'm also glad to share samples as requested.

Such a story is better told with pictures, in keeping with the depth of my analysis skills, but  first some notes of interest:

1. While the likes of the JS/Mult family indicates malicious JavaScript written to exploit multiple vulnerabilities (Adobe, Java, etc.), almost all these exploits universally favor exploiting Internet Explorer vulnerabilities such as CVE-2010-0249, CVE-2010-0806, and CVE-2009-0075. CVE-2010-0249, aka "HTML Object Memory Corruption Vulnerability" was used during Operation Aurora. If you followed Aurora closely back in the day, you'll likely find the country of origin statistics below of no surprise. CVE-2010-0806 was addressed in MS10-018 and and CVE-2009-0075 was addressed in MS09-002 to correct Internet Explorer issues described as unitialized memory corruption vulnerabilities. For what are vulnerabilities where updates were issued as much as three years ago, clearly enough unpatched systems remain to warrant such common exploitation.
2. Six of twelve samples exhibit signs of exact code reuse (Exploit:JS/AdoStream), and a seventh is a very slight variant (Exploit:JS/Mult.EA). Additional reference reading for the samples detected: Exploit:JS/AdoStream

The details on the domains of nefariousness are as follows:

Because infographics are all the rage:

These samples also presented a great opportunity to use an ISC Handler favorite. When you suspect code reuse or matching, Jesse Kornblum's ssdeep is an ideal tool with which to validate your assumption. As seen above, I stated that the malicious JS from six of the twelve URLs was identical. Comparing the sample (Exploit:JS/AdoStream) from Germany against the sample from Brazil proved to be a 97% match.

 The Exploit:JS/Mult.EA sample was also noted as a slight variant of Exploit:JS/AdoStream. Using the German sample to compare against the slight variant from Turkey showed a 94% match.

I found it interesting that the very slight difference in JS resulted in four less detections by AV vendors. Here's the VT detection for www.meydanoptik.com sample (Exploit:JS/Mult.EA) versus the VT detection for  www.stubllanet.com sample (Exploit:JS/AdoStream).

The diff between the two files as seen below shows only that the www.meydanoptik.com sample sets a cookie while www.stubllanet.com does not.

You get the idea. There are clearly commonalities in vulnerabilities targeted, methods used for exploitation, and even country of origin.

Hopefully you've found this relevant and interesting. Please share any related insight or experience you may have via comments.

Cheers.

Russ McRee | @holisticinfosec

A week ago we mentioned a "print bomb" malware specimen doing the rounds, with a gradually improving AV detection ratio. However, we are receiving reports (Thanks Conor!) with variants of what looks like the same malware, with a very reduced AV detection ratio (0/37), so do not relax your defenses.

Virus Total: https://www.virustotal.com/file/90910a49226f6488de42d27ac1b347c68a0d5a9c1b070bf5dfdaea8ac368cfc9/analysis/1340227448/.

This new sample, called "xpsp4ress.dll", is stored on C:\Windows\System32 and creates a scheduled task in Windows with what seems to be a random name (e.g. "UUSCPK"), running "C:\WINDOWS\system32\rundll32.exe 'C:\WINDOWS\system32\xpsp4ress.dll' ". Then it seems to propagate looking for share folders and/or printers (sometimes the DLL or EXE ends up in the spool queue and as a result reproduces the observed garbage printing behavior).

Some of the domains that has been identified when the malware phones home (C&C) are:

• hxxp://http://somethingclosely.com
• hxxp://ads.alpha00001.com
• hxxp://storage1.static.itmages.ru
• hxxp://storage5.static.itmages.ru

Look for them in your logs. There is a related write up available from Symantec: http://www.symantec.com/docs/TECH19098.

The beauty of this unexpected malware behavior is that it can easily be detected throughout the organization printers and print servers, although at the expense of wasting precious paper, and trees as a consequence. Let's save the planet! ... and don't forget this is a good opportunity to evaluate the security of your printing architecture (network isolation, access controls, printer management, etc).

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com

Cisco issued three security advisories today, 20 JUN 2012; two are new, one is an update.

1. NEW: Cisco ASA 5500 Series Adaptive Security Appliances and Cisco Catalyst 6500 Series ASA Services Module Denial of Service Vulnerability
   Cisco ASA 5500 Series Adaptive Security Appliances (Cisco ASA) and Cisco Catalyst 6500 Series ASA Services Module (Cisco ASASM) contain a vulnerability that may allow an unauthenticated, remote attacker to cause the reload of the affected device.
   http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-asaipv6
2. NEW: Multiple Vulnerabilities in Cisco AnyConnect Secure Mobility Client
   The Cisco AnyConnect Secure Mobility Client is affected by the following vulnerabilities:
   Cisco AnyConnect Secure Mobility Client VPN Downloader Arbitrary Code Execution Vulnerability
   Cisco AnyConnect Secure Mobility Client VPN Downloader Software Downgrade Vulnerability
   Cisco AnyConnect Secure Mobility Client and Cisco Secure Desktop HostScan Downloader Software Downgrade Vulnerability
   Cisco AnyConnect Secure Mobility Client 64-bit Java VPN Downloader Arbitrary Code Execution Vulnerability
   http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-ac
   
3. UPDATED: Cisco Application Control Engine Administrator IP Address Overlap Vulnerability
   A vulnerability exists in Cisco Application Control Engine (ACE) software.  Administrative users may be logged into an unintended context (virtual instance) on the ACE when running in multicontext mode.
   http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-ace
   

Russ McRee | @holisticinfosec

A week ago we covered MS12-042 ("Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (2711167)") on the monthly Microsoft patch update cycle. This Microsoft advisory includes two vulnerabilities: CVE-2012-0217 and CVE-2012-1515 (VMware related).

Unfortunately, the official CVE-2012-0217 only makes references to Microsoft Windows OS, but other environments are also affected by this local privilege escalation vulnerability associated to 64-bit Intel processors. From the US-CERT note: "Some 64-bit operating systems and virtualization software running on Intel CPU hardware are vulnerable to a local privilege escalation attack. The vulnerability may be exploited for local privilege escalation or a guest-to-host virtual machine escape." In particular, it affects FreeBSD or Xen (RedHat, SUSE, etc).

More details at "Vulnerability Note VU#649219: SYSRET 64-bit operating system privilege escalation vulnerability on Intel CPU hardware".

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com

A new version of Firefox, 13.0.1, was released today. Although the official release notes say that various security issues have been fixed in this version, by looking at the official security advisories for Firefox I couldn't find any new advisories specifically for 13.0.1, as all them (from MFSA 2012-34 to 2012-40) were fixed in version 13.0 (although unfortunately, the official release notes for Firefox 13.0 do not include the security fixes reference). We already announced these a couple of weeks ago.

In any case, be sure you get the update (via the automatic method or manually) and that it is properly applied (it includes a few functional fixes).

If you have more specific security details regarding 13.0.1 (if any), please share them through our contact page.

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com

No, I didn't make that title up. Someone else did. "vulnerabilityqueerprocessbrittleness . in" is currently one 600+ domains that link to a quite prevalent "Fake Anti-virus" malware campaign. Currently, the domains associated to this scam all point to web servers hosted in the 204.152.214.x address range, but of course the threat keeps "moving around" as usual.

The attackers show lots of "creativity" with their domain names

crashessafetypc. in
keepprotectcare. in
microsoftkeeper. in
hazardactivitytasks. in
hazardon-linekeeper. in
highrisksprotection. in

though they don't seem to have attended Marketing 101 yet, because some of the names appear to be less than ideal...:

keepperfomanceworms. in
dangerwreckguarantor. in
highfail-safetykeeper. in
optimizerwreckdeliverer. in

The current set of threats involves frequently changing malware EXEs (or EXEs inside of ZIPs) with low coverage on virustotal. The download URLs usually follow the pattern of http://bad-domain. in/16 character random hex string/setup.exe or /setup.zip

Example: http://fail-safetytestingcontrol. in/fc1a9d5408b7e17d/setup.exe

Stay safe .. and keep your PCs free of the dangerwreckguarantor!

This CVE-2012-1875 is now actively exploited in "limited attacks" but Microsoft has yet to update its MS12-037 bulletin [1] to clearly indicate that public exploit code is now widely available. This critical Internet Explorer update has a module available in the Metasploit framework.

Users are strongly encouraged to patch this vulnerability before your systems get exploited. Have you seen this vulnerability being exploited in your network? Let us know!

[1] MS12-037 - Critical: Cumulative Security Update for Internet Explorer
http://technet.microsoft.com/en-us/security/bulletin/ms12-037

-----------

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

Handler Swa wrote a diary about Microsoft Security Advisory 2719615. 16 hours ago, Juan Vasquez created the metasploit module for this vulnerability.

Users are encouraged to patch this vulnerability before an attacker can get your computer. Have you seen this vulnerability being exploited in your network? Let us know! 

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

We got a lot of responses to yesterday's "fake Verizon" e-mail. This brings (again) up the topic of authenticating e-mail messages. If you are reading this post, you probably already realize that the "From" header, like anything else transmitted in a default email, doesn't do a thing to authenticate an e-mail message. There are a number of technologies that can be deployed to help this.

1 - SMTP over SSL

There are a number of methods to run SMTP and other mail related protocols over SSL (pop, imap...) . SMTP in particular frequently uses the "STARTTLS" protocol which can start an SSL connection "on the fly" if both servers support it. SSL however only protects the connection. The receiving mail server can verify the identity of the sending mail server, and the connection can be encrypted. In most implementations I have seen, the certificate is not verified, and the SSL connection is optional, which significantly reduces the value of this technique, in particular between mail servers. For mail clients sending e-mail to trusted mail servers, SMTPS can be a meaningful control if for example a VPN isn't available. But the main issue is that e-mail is forwarded from server to server, and the sender or recipient have no control if the path the email took was secure.

2 - DKIM

DomainKeys Identified Mail (DKIM) [1] is mostly an anti-spam feature. It will authenticate if a mail server is authorized to send e-mail on a particular domain's behalf. At this point, some major e-mail providers like Yahoo will implement DKIM. However, aside from its limited scope, DKIM suffers from a number of implementation issues. First of all, it is typically not a default component of mail servers, but has to be added on via a patch or additional software packages. Secondly, once implemented, e-mail for a particular domain has to be sent via authorized mail servers. A users working from home may no longer use his or her ISP's mail server, but has to send e-mail via the corporate mail server. In most cases, this is a good thing, but it can be difficult to implement. The neat part about DKIM is that keys are distributed via DNS, and that validation is done on the server without user involvement. Of course, the use of DNS also requires a secure DNS infrastructure.

3 - PGP

PGP is probably the oldest form of e-mail encryption and authentication. It does provide end-to-end verification of a message or part of a message. It is very flexible in that it can be used to verify the entire message, or just parts of it. Headers are usually not included in the signature, but since the signature is linked to an e-mail address, it can still be used to authenticate the sender. In my opinion, PGP (and GPG for that matter) suffers from two big problems: First of all, support is available for most e-mail clients, but usually not included by default, requiring users to install and configure additional software. Software for iOS for example is available, but poorly integrated with the default iOS mail client. Secondly, PGP key management is not intuitive to the average user. It lacks the use of a central "certificate authority" and leaves it up to the user to trust or not to trust a key. combined with the limited use of PGP in day-to-day e-mail use, this is a big challenge. Usually it is best to establish the validity of a PGP key by continuously using it for all e-mail, making it easier to spot unusual or different keys.

4 - S/MIME

S/MIME probably has the best chance at this point of gaining some acceptance. It does use certificate authorities, so unlikely PGP the decision to trust a certificate is removed form the user to some extend. But as other uses of certificate authorities have shown, this isn't all that safe either. However, I think for the average user (one that hasn't attended a key signing party yet), this is preferred over the decentralized method used by PGP. The main issue with S/Mime is that it does sign the entire message including headers, and there is no option to only sign part of the message. This leads to broken signatures if a message is forwarded to a mailing list or passes other remailers that change headers. But S/Mime has been widely implemented by default in many e-mail clients, including mobile clients.

I really wish more people would take advantage of any of these technologies to verify e-mail. Any e-mail, including e-mail sent by automated processes, should be signed. I think user awareness will follow once users see more signed e-mail. Most of the automated e-mail we sent for ISC/DShield uses PGP signatures and we are working on implementing it for more of our e-mail. DKIM hasn't been an option for us so far as our organization is too decentralized, and for our audience PGP has shown to work pretty well and easier to implement then S/Mime for our scripts. My personal e-mail is usually S/MIME signed. 

[1] http://www.dkim.org/

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

We have seen a couple of reports recently of pretty well done Verizon Wireless phishing attempts. At this point, I haven't gotten one with the target site still up, so they may try to install malware instead of just asking for Verizon credentials. 

update: Paul just wrote in that he caught some of the links still active, and indeed they are trying to install malware and don't ask for credentials. And fellow handler Pedro notes that the malware is a blackhole exploit kit that will try to install Zeus.

See if you can spot the fake one. The answer is below the images (click to open image in new window at full resolution)

The left one is the fake. The only give away is that the fake e-mail doesn't include the partial account number, and typically indicates a large bill > $1,000 (at least large for me). I assume the large amount is supposed to cause panic clicking.

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

VMWare Released a new security advisory (VMSA-2012-0011) for its products [1]. The advisory covers pretty much all of VMWare's virtualization platforms (Player, Workstation, Fusions, ESX and ESXi). 

The in my opinion most severe vulnerability out of the two described would allow an attacker to execute code on the remote host, which could be used to "break out" of the guest. However, this issue requires that the attacker is able to load checkpoint files on the guest, which in turn requires the attacker to have full control of the guest, a typical requirement for VMWare escape.

The second vulnerability can lead to a denial of service. An attacker can crash the virtual machine by manipulating traffic to remote devices like keyboards or disks attached to the virtual machine.

I would not consider either one of these as "super critical", but in particular the first issue should be patched soon.

[1] http://www.vmware.com/security/advisories/VMSA-2012-0011.html

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

Microsoft released an automatic updated for untrusted certificates. A bid sad that we need this, but it does appear to be necessary to have a method to continuously update a bad certificate lists. The goal of the new updater is to allow for updates to the untrusted certificate store in one day or less after a new bad certificate is known.

Key revocation lists and OCSP were designed to notify clients of revoked certificates. However, these protocols haven't shown the scalability necessary to reliably notify clients of invalid certificates.

(thx Alex for pointing this out)

[1] http://blogs.technet.com/b/pki/archive/2012/06/12/announcing-the-automated-updater-of-untrustworthy-certificates-and-keys.aspx

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

As announced before, ICANN today published a list of all new TLDs organizations applied for [1]. Applications had to be submitted by May 30th. Being included in the list does not yet imply that these TLDs will actually be approved and created. This is just another stop in the lengthy process. I counted 1930 new top level domain, which I think is a manageable number. Many of the TLDs use foreign character sets. For example companies like Volkswagen apply for their brand name in chinese (大众汽车). Some other interesting proposals I spotted:

.search : Multiple applicants (Amazon is the company that sticks out among them). and .secure has two applications, one from Amazon and one from Artemis Internet. Google, using a company named"Charleston Road Registry" applied for 101 different TLDs and is the top bidder, Followed by Amazon EU (76) and "Top Level Domain Holdings" (70). The most contested TLDs are "APP" (13 applications), "INC" (11), "Home" (11) and "ART" (10).

There is some criticism that ICANN not only published the TLD and the name of the applicants company, but also full contact details including e-mail addresses.

[1] http://newgtlds.icann.org/en/program-status/application-results/strings-1200utc-13jun12-en

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

Several readers mentioned that Microsoft today issued a Security advisory regarding Microsoft XML Core Services (MSXML). This is in response to active exploitation.

The issues affects Office 2003 and 2007 on all versions of windows. All a user has to do to fall victim is visit the wrong website using IE. 

Microsoft has issued a fixit for it in the form of an msi file (see the KB 2719615 link below)

Alternative strategies would be to use browsers that do not support ActiveX, or disable the support in IE.

Links:

• http://technet.microsoft.com/en-us/security/advisory/2719615
• http://support.microsoft.com/kb/2719615
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1889

--
Swa Frantzen -- Section 66

Toby reminded us that Oracle is releasing Java 7 update 5 and Java 6 update 33 today.

Working links to release notes with security content and the like are more than welcome.

• Pre release announcement
• Release notes for 6u33 - does not include security content
• Release notes for 7u5 - does not include security content
• Downloads

--
Swa Frantzen -- Section 66

Overview of the June 2012 Microsoft patches and their status.

--
Swa Frantzen -- Section 66

This month Adobe decided to fix a ColdFusion vulnerability for Black Tuesday:

APSB12-15 tells about the fix for CVE-2012-2041, a HTTP response splitting vulnerability in the ColdFusion Component browser.

--
Swa Frantzen -- Section 66

I would like to thank Andrew for pointing out a XSS vulnerability in one of our tools. The tool pretty simply echoed back user input without proper output encoding.

XSS is in particular difficult to avoid as it may happen anywhere you send data back to the user. The proper encoding depends on the context the data is used in, and sometimes, a simple "replace < and > with &lt; and &gt;" doesn't cut it [1]. However, in my experience, many cross site scripting errors happen because the coder (in this case me), just didn't bother to properly escape at all.

A while back, I started using a "safe_out" function. This function will do the simple HTML entity replacement before printing the data. By using "safe_out" instead of "echo" or "print", I got a simple check ("grep print") to make sure I didn't miss a spot. The function is only good if you return data in the HTML body of a page, but this is what I am doing 99% of the time. 

function safe_out($sText){
    echo(htmlentities($sText,ENT_QUOTES,'ISO-8859-1'));
}

The function is however a pain to use if you are mixing HTML and user data. Lets say you are trying to replace a print statement like:

print "<tr><td>$col1</td><td>$col2</td><td>$col3</td></tr>";

this would become:

print "<tr><td>";
safe_out($col1);
print "</td><td>";
....

To overcome this, I modified the safe_out function somewhat, to make it easier to use in these case:

function safe_out($sText,$aVars=''){
  if ( $aVars=='' ) {
    echo(htmlentities($sText,ENT_QUOTES,'ISO-8859-1'));
  } else {
    if ( is_array($aVars) ) {
      foreach ( $aVars as $key=>$value ) {
        $value=htmlentities($value,ENT_QUOTES,'ISO-8859-1');
        $sText=str_replace(":$key",$value,$sText);
      }
      echo $sText;
    }
  }
}

safe_out("<tr><td>:col1</td><td>:col2</td><td>:col3</td></tr>",array("col1"=>"abc","col2=>"axy",":col3"=>"123"));

Of course Java users, may want to consider the OWASP ESAPI framework. It includes appropriate output encoders. But for php coders like me, the above snippet may be of help.

[1] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

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

A reader pointed us to F5's SOL 13600, a vulnerability notice by now almost a week old. It details fixes and workarounds for a configuration mistake where unauthorized root access is possible via ssh over port 22. It doesn't exactly spell out their mistake. 

Now any unix administrator will start to wonder: why configure ssh to even allow root access at all ? And moreover you'd still need the appropriate credentials of root.

It turns out that unpatched F5 systems not only allow root to connect over the network, but that they authorize a public RSA key for root and that they also left the corresponding supposedly private key on all of their systems. 

If you have an F5 box and have not installed this update or worked around it properly, better do it now: every F5 customer has the keys to yours. And it takes only one to leak the key for all those who'd like to harm you to have it too.

CVE-2012-1493

--
Swa Frantzen -- Section 66

Apple announced a new update for iTunes today.  Per APPLE-SA-2012-06-11-1, this update addresses a problem when importing a maliciously crafted m3u playlist within iTunes and a problem within WebKit when visiting a maliciously crafted website.

The bulletin is available at http://support.apple.com/kb/HT5318 .

Scott Fendley ISC Handler

Thanks to Jack for pointing this one out to us. I somehow missed this vulnerability this weekend.

MySQL fixed last week an authentication bypass vulnerability that is trivially exploitable [1]. The effect is that a user has a 1/256 chance of being granted access to MySQL even if the password is wrong. So in short: Brute forcing passwords will always work pretty quickly even if you got the wrong password.

The vulnerability does however depend on how your instance of MySQL was compiled. Chances are that you are not vulnerable, but just in case, there is a patch available, and it shouldn't be too hard to test. Write a script that attempts the same password many  times, and see if you get logged after a while. 

As an additional hardening measure, you may want to consider limiting access by IP address. 

[1] http://seclists.org/oss-sec/2012/q2/493

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

One of the important features of last weeks Microsoft certificate patch was that the bad certificate was apparently used to subvert the Windows update process. The complex Windows update architecture represents a huge target to any attacker, and it has held up quite well so far. I do not expect any issues related to the lost certificate this week. However, this would be the last chance for the attacker to use these certificates, and it is a good opportunity to talk about patch security on the day before "black tuesday".

 I do recommend that you apply the certificate patch released a week ago today if you haven't done so already. This way, no patch signed by the bad certificate should be accepted tomorrow. Patch tuesday is one of the best dates to launch such an attack as you do expect patches anyway. Don't forget the WSUS patch: http://support.microsoft.com/kb/2720211

A couple of rules to harden your patch process:

• Avoid patches while "on the road". Apply them in your home / work network whenever possible. This doesn't eliminate the chance of a "Man in the Middle" (MitM) attack, but it reduces the likelihood. If you are on the road for extended periods of time, use a VPN connection. In particular hotel networks and public hotspots frequently use badly configured HTTP proxies that can be compromised and many users expect bad SSL certificates (because of ongoing MitM attacks... ironic, but well, sadly true) in these environments.
• Always validate patches. For Microsoft, this means using Microsoft update which will validate the digital signature applied to patches. The bad certificate broke this process. But it is still a very difficult hurdle to overcome for an attacker.
• Do not accept patches from unknown sources. This includes CDs/DVDs you receive unsolicited, and of course the famous USB stick you found in the parking lot. For Windows, only use Windows Update.
• Patch Tuesday is also an opportunity to verify that other software you own is patched. Secunia PSI does a good job with that for home users, Mac users have "MacUpdate" (for a small annual fee). Qualys provides browsercheck.qualys.com which works great in particular for home users / less experienced users.
• If you run your own WSUS server, make sure it is hardened and uses appropriate SSL certificates

Any other measures you apply to ensure the integrity of your patch process? Post a comment! In general, I usually advice people not to emphasize speed too much when it comes to patching. Instead, make sure you have a well tuned reliable and repeatable process. The biggest problem in my opinion (aside from organizations that don't patch at all) are patches that didn't get applied because it was never verified if the patch was actually applied, or patches that break systems because they didn't get tested sufficiently.

A patch is not applied until you verified that it got applied. Follow vendor guidance to check if the patch was applied, and if appropriate, check using a vulnerability scan.

 Also see: http://support.microsoft.com/kb/2720211

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

As most of our readers already know, there has been some major publicized password breaches involving LinkedIn, eHarmony, and others.  Scam artists have taken notice of these breaches and are using these incidents to prey on confused or unsuspecting users.

For example, one of our readers received a scam message claiming to be from IMDb.  The scam message (see below) claims that there are problems with the security of the user's password which can be corrected by clicking on the link. Anyone who clicks on the link are redirected to a pharmaceutical advertisement site.  Similar messages have been seen elsewhere which purported to be from LinkedIn or eHarmony.  

Unfortunately, this type of activity happens with almost any major incident, no matter if it is a data breach, natural disaster, or other major crisis.  Within the InfoSec community, we need to find effective ways to communicate to our respective user communities about well publicized issues, as well as the scam possibility in the aftermath of the real incident. 

Example Scam:

---
Scott Fendley
ISC Handler on Duty

New Flash updates have been released today.  In addition to this there have been some good changes for flash on firfox with the addition of the sandbox.  More info on the sandbox and a good explanation can be found here http://blogs.adobe.com/asset/2012/06/inside-flash-player-protected-mode-for-firefox.html

Mark.

Jim posted earlier in the week (https://isc.sans.edu/diary.html?storyid=13387) regarding a bind 9 vulnerability.  Whilst possibly unrelated we've had a report regarding a few million DNS responses with static IDs being sent to an organisation.

If you have something similar happening and you are in a position to capture some packets we'd appreciate it if you could upload some for us to have a look at.  Especially of they all have the same ID number.  

Mark  

A few weeks ago I posted a request for packets for the above ports, a big thanks to all that provided information. 

Whilst still not 100% confirmed it looks like 8909 and 9415 are associated with open proxies.  I've seen some IPs that look for open proxies hit 8909 and 9415 as well as the normal proxy ports. 

27977 is still a bit of a mystery, the packets received were all associated with normal traffic that happened to use this port as a source port. 

UDP /7 was an interesting one.  I only received 8 packets that were relevant and these were interesting.  512 bytes long, After the header the first two bytes count up, the second two bytes count down and the rest of the packet is all 000's.  Likely because there was nothing to interact with.  Would dearly love some additional packets for this port.  

If you can help out submit the packets through the contact form and thanks in advance. 

Mark

There have been several reports now of PCs on the network printing what looks like an executable to a large number of printers.  Several scanning tools will cause this kind of behaviour, but in the instances I know of these tools were not being used on the network at the time.  The various AV products aren't great at picking this up, yet. 

If you have this happen in your network use your logs to determine the sending machine (will be in the print logs) and take it offline for investigation and re-imaging. If you happen to have the actual malware upload it via the contact form and make our malware guys and gals happy.

Mark

Some updates:

Other than the excellent comments made to the dairy (thanks), we received a file that is the file reportedly being sent to the printers - e864689c6897dab7daa727f2ab70ef5a. this file is some adware that currently has 21/41 detect rate which is slowly improving. The dropper is BA9D4EFB6622D4DE95C162D95CB171A4  and has a detect rate of 17/41 ATM.

Microsoft released its advance notification for next weeks patch tuesday [1]. We should expect a total of 7 bulletins, 3 of which are rated critical, and 4 important. The bulletins cover the standard components (Windows, Office, Internet Explorer, .Net Framework) but also include one bulletin for Dynamics AX. Dynamics AX is part of Microsoft's enterprise resource planing (ERP) solution. I would expect only few users to be affected by this path . From the looks of it, this appears to be an "average" patch tuesday. 

[1] http://technet.microsoft.com/en-us/security/bulletin/ms12-jun

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

 One of the challenge in managing large server farms remotely is how to deal with crashed / hanging servers once the operating system no longer responds. The classic answer is usually a mix of serial consoles, maybe KVM over IP devices and remote power switches. This equipment isn't just expensive, it also takes up valuable rack space, requires power and lots and lots of extra messy cables.

To make things easier, Intel came up with "IPMI". the "Intelligent Platform Management Interface". Typically found in servers, versions of it can also be found in desktops targeting enterprise deployments. IPMI is by no means new, an the attack described here isn't new, but I still find that many system admins are not aware of the potential of modern implementations of IPMI (good or bad).

Over the years, there have been a number of different IPMI revisions. How much functionality you get depends on the motherboard vendor and the firmware you are using. But there are a few features that are common to pretty much all IPMI implementations:

• IPMI is active once the server is connected to power. It does not depend on the server to be actually "switched on". 
• IPMI is implemented as a specific circuit on the motherboard. Sometimes, you may find it on an optional plugin board. But it does not require CPU, RAM or other components
• It may use an existing network card, and doesn't necessarily need a dedicated network card

If your operating system supports IPMI, you can use special software on the server to connect to it and use it for example to read the status of various sensors. Check the "openipmi" or "freeipmi" tools if you don't already have them installed.

IPMI is useful locally, but its real power comes to play remotely. IPMI version 1.0 was used over serial ports. Its main feature was to be able to remote power cycle as system. You can probably compare this to a kind of "Wake on LAN" but over serial with the ability to turn power off, not just on. This eliminated the need for remote power controllers. As of version 1.5, it was possible to send IPMI messages over IP. The latest version, 2.0, includes support for blade servers, vLans and a number of additional features commonly found in modern networks.

In a current server implementing IPMI, you may find a full blown web server able to control the system remotely, including advanced features like flashing firmware. This pretty much does away with the need for a serial interface. However, you will lose the "out of band" character of a serial connection, that many of us count on for security. There are a couple basic steps you can use to secure IPMI:

• setup a dedicated management network, and limit IPMI to the network card connected to the management network.
• review the BIOS configuration option for IPMI. If you can't have a physical management network, at least try to use a VLAN if supported.
• keep IPMI firmware up to date. It may be included in motherboard firmware updates or delivered as a distinct package.
• eliminate IPMI access over insecure protocols like HTTP. Use HTTPS with proper certificates, or SSH
• do not use default passwords
• try to integrate IPMI authentication with existing authentication systems. Options typically include RADIUS and AD.
• review hardening options your IPMI implementation provides. You may be able to limit access from IP addresses, or turn off various features you do not need
• inventory servers with IPMI capability

Finally as a bonus, a little video showing one recent IPMI implementation: 
 

[1] http://www.intel.com/design/servers/ipmi/index.htm

 

------

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

Reports originally surfaced in Norway overnight that about 6.5 million unsalted SHA-1 password hashes had been posted to a Russian site with a request for assistance in cracking them.  Several highly trusted security researchers have confirmed that the hashes posted include those of passwords they use exclusively on LinkedIn.  There are no usernames associated with the hashes and a number of us have confirmed that our passwords are NOT included, but this seems serious enough to merit a recommendation that LinkedIn users change their passwords.  The folks from LinkedIn have posted to twitter that they are investigating and further information will be forthcoming.

References:

http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-linkedin-6-5-million-hashed-passwords-reportedly-leaked-change-yours-now/

Also see @thorsheim on twitter.

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

The Internet Systems Consortium released a security advisory on Monday about a possible denial of service attack against BIND named DNS servers (which constitute the majority of name servers on the internet).  The advisory states that the primary threat is against recursive name servers (the ones clients workstations/laptops/mobile devices point to to translate DNS names into IP addresses), though authoritative primary and secondary name servers could also be at risk if configured with experimental record types.  While they were not aware, at the time, of any active exploitation of the vulnerability, the details had been discussed in public mailing lists.  The vulnerability involves improper handling of certain requests with zero-length RDATA fields.  From the description, it doesn't appear that the crafting of a packet that would trigger the vulnerability would be too difficult.  The result would be either crashing the named daemon or disclosure of some unrelated contents of memory.  Updates should be applied, especially to your recursive name servers, as soon as practical.

References:

http://www.isc.org/software/bind/advisories/cve-2012-1667

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1667

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

The Mozilla folks have released new versions of Firefox, Thunderbird, and Seamonkey and if you haven't already seen or been offered the update via the automatic updating mechanisms, you should soon.  However, this time, push the issue and manually update, if it doesn't come automatically.  The Mozilla Foundation released a security advisory yesterday regarding a privilege escalation vulnerability introduced by the new updater service (yes, I'm sure they realize the irony there) introduced in the last release.  Bottom line, make sure you update from Firefox/Thunderbird 12 to 13 (and Seamonkey 2.9 to 2.10) ASAP

References:

http://www.mozilla.org/security/announce/2012/mfsa2012-35.html

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

Overview

In honor of IPv6 Day today, Wednesday June 6, 2012, we'll review all the IPv6 features on the ISC website and more! Have you tested your network on IPv6? Need to learn more about IPv6 implementation? All that and more covered in this feature!

Features

IPv6 Diaries and Videos

• https://isc.sans.edu/tag.html?tag=ipv6 - Here you will find a list of many IPv6 related diaries written by various handlers
• https://isc.sans.edu/ipv6videos/ - This page has an abundance of IPv6 videos embedded

IPv6 / IPv4 Conversion and Analysis - https://isc.sans.edu/tools/ipv6.html

• Summary Information - Explination and ipv6test box
• IP Entry Form - Enter an ipv4 IP and you get a table with numerous conversions.
• How to Translate Teredo IPv6 addresses

For more information about IPv6:

• http://www.ipv6day.org/
• http://www.worldipv6day.org/
• http://ipv6ready.org/
• http://www.ipv6actnow.org/
• http://www.kame.net/ - do you see the dancing turtle!

Learn more about IPv6
SANS IPv6 Summit! Friday, July 6, 2012 http://www.sans.org/ipv6-summit-2012/
IPv6 Essentials SEC546 July 7-8, 2012 at SANSFIRE 2012 http://www.sans.org/sansfire-2012/description.php?tid=5086
Security 546 IPv6 Essentials description and events https://www.sans.org/security-training/ipv6-essentials-1022-mid
 

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

We've received a fair number of questions on today's emergency patch from Microsoft ( https://isc.sans.edu/diary/13366 ), and many of them have been simply "Why don't they just put the affected Certs into the CRL (Certificate Revocation List)"?  That is, after all, what the CRL is for, and it's part of the SSL protocol for goodness sake!

Simply put, in most cases the browsers do not consult the CRL, or if they do, they time out the lookup and proceed on *very* quickly.  Jim wrote on this in Febuary when Chrome enabled this behaviour ( http://http://isc.sans.edu/diary.html?storyid=12556 ).  But this behaviour has been in force for some time (to various degrees) in most browsers an platforms.  A quick google led me to some excellent articles on this topic:
http://www.imperialviolet.org/2011/03/18/revocation.html
http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html

You'd think after the Diginotar compromise just last year (http://isc.sans.edu/diary.html?storyid=11500 , http://isc.sans.edu/diary.html?storyid=11512 and many others), we'd have learned and changed this behaviour.

Unfortunately, it's truly become a race to the bottom for Browsers where SSL security is concerned.  And sadly, it's we, the browser users who insist on "the fastest browser" that have forced them to go there.
 

===============
Rob VandenBrink
Metafore.ca

Microsoft just released an emergency bulletin, and an associated patch, notifying users of Windows that a "unauthorized digital certificates derived from a Microsoft Certificate Authority" was used to sign components of the "Flame" malware. 

The update revokes a total of 3 intermediate certificate authorities: 

• Microsoft Enforced Licensing Intermediate PCA (2 certificates)
• Microsoft Enforced Licensing Registration Authority CA (SHA1)

It is not clear from the bulletin, who had access to these intermediate certificates, and if they were abused by an authorized user, or if they were compromised and used by an unauthorized user. Either way: Apply the patch.

The bulletin also doesn't state if this intermediate certificate authority or certificates derived from it could be used to fake the patch. Microsoft Certificates are used to sign patches, and a compromise could lead to a sever break in the trust chain. The use of a "real" Microsoft certificate is surely going to increase the speculations as to the origin of Flame.

[1] http://technet.microsoft.com/en-us/security/advisory/2718704
[2] http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx

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

This past week (June 1) VMware has posted version 1.0 of it's vSphere 5.0 Hardening Guide.  They've changed their approach from previous Hardening Guides, the current version is gridded out an Excel doc, with the benchmarks split out between those that apply to Virtual Machines, ESXi, Network and vCenter.

The thing I really like about this new version of the Hardening Guide is that it further emphasizes script-based assessments of as many of the benchmarks as possible.  Examples of how to assess many of the benchmarks are supplied in vCLI, PowerCLI and direct shell scripting within ESXi.

This approach is near-and-dear to my heart, we spend an entire day on script based security assessments of vSphere ESX and ESXi environments in SANS SEC579 ( https://www.sans.org/security-training/virtualization-private-cloud-security-1651-mid )

You can find the vSphere 5.0 Hardening Guide here ==> http://communities.vmware.com/docs/DOC-19605

For assessing vSphere 4.1, the vSphere 4.1 Hardening Guide can be found here ==> http://communities.vmware.com/docs/DOC-15413

Thanks to Charu, his team and all the contributors to this great series of resources!

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

There are numerous ways of concealing sensitive data and code within malicious files and programs. However, attackers use one particular obfuscation technique very frequently because it is simple to implement and offers protection that's usually sufficient. This approach works like this:

1. The attacker picks a 1-byte value to act as the key. The possible key values range from 0 to 255 (in decimal).
2. The attacker's code iterates through every byte of the data that needs to be encoded, XOR'ing each byte with the selected key.

To deobfuscate the protected string, the attacker's code repeats step #2, this time XOR'ing each byte in the encoded string with the key value.

For example, consider the malicious Microsoft Word document "World Uyghur Congress Invitation.doc", which was submitted to victims as an email attachment in a targeted attack. (To understand how this exploit works, see my earlier posts How Malicious Code Can Run in Microsoft Office Documents and How to Extract Flash Objects From Malicious MS Office Documents.)

In this case, the attacker embedded an ActiveX control inside the Word document to execute JavaScript, which and executed downloaded a malicious Flash program, which targeted a vulnerability in the victim's Flash Player. The payload of the exploit extracted and executed a malicious Windows executable, which was hidden inside the Word document.

To locate the executable file within the Word document, you can use Frank Boldewin's OfficeMalScanner tool. The "scan" option directs the tool to look for the embedded malicious Office and Windows executable files. The "brute" option tells the tool to look for these artifacts even if they were obfuscated using several common methods, including the XOR technique described above.

In this example, OfficeMalScanner automatically locates and extracts the embedded Windows executable, saving it as the "WUC Invitation Letter Guests__PEFILE__OFFSET=0xfc10__XOR-KEY=0x70.bin". (The tool automatically determined that the attacker used XOR key 0x70 to conceal this file.) According to PEiD (see screenshot below), the extracted file is a Win32 program that is not packed and that was probably compiled using Microsoft Visual C++.

The deobfuscated and extracted Windows executable file can be analyzed using any means, including your favorite disassembler and debugger, as well as using behavioral analysis techniques.

It's quite possible that the extracted malicious executable also contains obfuscated data. Given that everyone, including malware authors, takes shortcuts once in a while, it's possible that this data is protected using the simple XOR algorithm we discussed earlier. Didier Steven's XORSeach tool can scan any file, looking for strings encoded using simple techniques, including this XOR method.

You need to know the clear-text version of the string you'd like XORSearch to locate. One good value to look for is "http", because attackers often wish to conceal URLs within malicious code. Another good string, as suggested by Marfi, might be "This program", because that might identify an embedded and XOR-encoded Windows executable, which typically has the string "This program cannot be run in DOS mode" in the DOS portion of the PE header. 

As you can see below, XORSearch locates the string "HTTP/1.1" within the extracted malicious executable; apparently it was encoded using the key 1B. (Sometimes you get a false positive, as seems to be the case with the key 3B.)

When invoking XORSearch with the "-s" parameter, you direct the tool to attempt decoding all strings within the file using the discovered key. In our example, this results in the creation of the "WUC Invitation Letter Guests__PEFILE__OFFSET=0xfc10__XOR-KEY=0x70.bin.XOR.1B" file. If you look at this file using a hex editor, you can locate several decoded strings that you might use as the basis for custom signatures and further code-level analysis.

XOR and related methods are often used by attackers to obfuscate code and data. The tools above help you locate, decode and extract these concealed artifacts. If you have recommendations for other tools that can help with such tasks, please let us know by email or leave a comment below.

-- 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.

One of our supporters, Jags, saw an old alert on their Cisco IDS appear in their logs today.  The specific signature is being classified by the IDS as Opachki, a dated link hijacking program.  Bojan Zdrnja wrote an excellent diary on this malware in November 2009.  Not much we don't already know about this malware, so on a rainy Saturday I thought I would put it to the readers: Anybody else seeing new Opachki alerts?  If so, we'd love to hear!  Maybe something new appears...

And as always, we are always listening for something new here at ISC, so we'd love to hear if it's new and not Opachki.

tony d0t carothers

Overview
As a quick follow on to last weeks feature Country Report, today we'll take a look at the Country list page at https://isc.sans.edu/country.html. This page lists country, region and total reports by date with option to limit by port number. Also, this links to Region Report at https://isc.sans.edu/regionreport.html for overall reports per region with date and port criteria.

Features
Usage text at the top explains a few points of the page and here's the details

• Choose the date for data you want to display on the page then click Update. Default is the current day.
• Enter port number if you want to restrict then click Update.
• Click column header to sort by column. Click again to reverse sort order.
  • Country: result linked to https://isc.sans.edu/countryreport.html for details
  • Region: Limit to a specific region by choosing from drop-down and clicking Update. Click the region abbreviation to go to Region Report page which gives total reports per region with similar criteria options.
  • Reports: Total reports for country row based on date/port criteria

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

the Internet Society has declared this coming Wednesday, June 6th, "IPv6 Day" [1]. We had a similar IPv6 day last year, but this year things will be a bit different. First of all, like last year, numerous large web sites declared their participation in IPv6 day.

As of June 6th, participating web sites will be reachable via IPv6, and they will remain reachable via IPv6 beyond June 6th. Last years IPv6 day was different in that it only lasted one day, and IPv6 connectivity was disabled the next day. Last year was more of a trial run and based on it's success, it was decided to maintain IPv6 connectivity beyond IPv6 day this year. 

So what does this all mean? First of all, the web sites in question will still be reachable via IPv4. However, if you do have some form of IPv6 connectivity, you will likely use IPv6 to reach them (see my "Happy Eyeballs" video about some of the odd issues that may arise . https://isc.sans.edu/ipv6videos/HappyEyeBalls/index.html )

If you are using an IPv6 tunnel, or in particular if your operating system decides to auto-configure a tunnel, you may see some degradation in speed and reliability. It is time to get a native IPv6 connection. I know most of you can't get it. But this is another problem... "Teredo" connections will not be used if IPv4 connectivity is available.

Get ready to secure your IPv6 network. Right now, IPv6 is a blind spot to many detective controls. Don't consider IPv6 a threat. Use it as an opportunity. There are a lot of neat things you can do in IPv6 to secure your network better. But get on it and learn about it now.

In the end, we do need IPv6. IPv4 was designed as a research network for the 70s/80s. It has outlived its purpose. The current global business network we call the Internet can not continue to run and grow much. Already, we are running into issues not just with address utilization, but also with routing efficiency, integration of modern networking paradigms like mobility, modern hardware opportunities that make IPv4 inefficient. I consider it like the DC power grid as a nice starter network that helped us get going, but in the end, AC was the way to go to actually create large efficient power grids that jump started so many great innovations.

We do also have a special summit coming up: The Security Impact of IPv6. See http://isc.sans.edu/ipv6 .

[1] http://www.worldipv6day.org/

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

Apple released a nice document with details about iOS 5 security features. The document is NOT a hardening guide. Instead, it provides more insight into the iOS architecture and sandboxing feature, as well as lists of available security features.

This document should be read by anybody working on an iOS hardening guide to better judge the risks associated with iOS and various settings within iOS. One problem with standard hardening guides is that some of them may be too restrictive for your environment, and you should always customize them to your needs. The Apple documents will allow you to make more intelligent choices as to what hardening features to apply.

[1] http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
[2] http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml

(A google search for "iOS hardening guide" will lead to a large number of relevant hardening guides you can use as a starting point for your own).

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