Malware Forensics at Large Firms

The malware forensics work-cycle is fairly tight at the day job.  It focuses more on answering questions like:

·    What are we dealing with?  (e.g. an adware like Monkif, or an information stealer like Zeus?)
·    Grab a sample to submit to the AV vendor
·    Identify network behavior so we can identify infected machines on the wire
·    How did it get in?

Depending on the workload, resources, etc. we don’t always get to answer all of the questions before the demands of keeping the business running or more severe incidents reallocates the response staff.
 

Smells Like Zeus

Last week, a sharp-eyed user noticed that their on-line bank was asking more questions than they usually do when they log in.   During the initial triage I noted that it “smelled like Zeus.”  Once we had got onto the box with EnCase we immediately looked for, and found, c:windowssystem32sdra64.exe on the system.  Sure, case-closed.  Submit the sample to AV to get them to update their signatures, examine the user’s proxy logs to identify the phone-home behavior and make signatures from that.  There, the organization is protected.
 

But How Did It Get In?

The final-step in incident handling and the most-often ignored is the root-cause analysis or lessons-learned.  With this particular case, I had a timestamp of when sdra64.exe was dropped on the box (if I trusted the MAC times) and could start digging through the web proxy logs for that machine at that time.  That sounds like a lot of something-that-isn’t-much-fun.

You know what sounds like more fun?  Timeline analysis.
 
(For more on doing your own Timeline Analysis in your environment, I recommend starting here: http://blogs.sans.org/computer-forensics/2010/03/19/digital-forensic-sifting-super-timeline-analysis-and-creation/)

In EnCase it’s not too hard to organize the view of the file system to track what files were modified or added around the time of sdra64.exe.  I was at first interested in the files in the Temporary Internet Folders location of the user, since it will help me narrow down what website was hosted the exploit.
 

Java Applet Cache Files

In addition to the HTML and image files in the Temporary Internet Folders there were also files created in c:Documents and Settings[victim]Application DataSunJavaDeploymentcache[numbers]

There were files that had hash-like names, some with no extension, some with .idx, some with .hst.

The extentionless file is a zip archive of the .class files or bytecode of the java applets downloaded to the system.  The .idx file looks suspiciously like the HTTP session used to pull it down, and .hst was the IP of the source.

That’s pretty handy information to have on hand.  But what is the significance of java applet?  On a whim, I submitted it to virustotal and it tells me that it’s an exploit for CVE-2009-3867.  Neat, now I know how it got in and where it came in from.
 

Prefetch Files

With the tight deadlines, and the rushed process of identifying the process generating the bot-net traffic, or what dll is getting injected into iexplore.exe I know that I’m missing a lot of the other files that get dropped onto the system.  If we’re lucky enough to get a memory snapshot of the system while it’s doing its evil I can use something like volatility to tell me what files a process has open.  If it’s after-the-fact, I can glean some of that information from the prefetch files.  In our zeus case while jumping into look directly for sdra64.exe I also saw SDRA64.EXE-[hash].pf.

The normal forensic value of prefetch files is it will tell you how many times an executable has been run and the last time that it was executed (I refer you to Harlan Carvey’s “Windows Forensic Analysis DVD Toolkit” pp 226 in the first edition.)  The real purpose of a prefetch file is to improve the efficiency of the OS so it tracks what files are opened by the executable.  Using something like BinText you can see the list of files open by the application.  This gives me an additional list of files to check against the whitelist for.  In this particular example the .pf file also had a bit of HTML in there that looked like an iframe, I’m not sure if that’s a fluke or not, but it held additional clues about the exploit.
 

A reader reports that a new version of the Opera browser has been released today for Mac and Windows.  The release notes are available here: http://www.opera.com/docs/changelogs/windows/1053/

The notes are simple, this is a security update to address a security vulnerability detailed here: http://www.opera.com/support/kb/view/953/

This is likely handled as an auto-update in most installations.

The Set-up

So you’ve just spent your morning digging through web proxy logs figuring out how one of your users managed to get infected with the latest rehash of FakeAV and you’ve got a handful of malicious URLs that you need to block on your perimeter.  Let’s also suppose that you hold some goodwill towards your fellow sysadmin and wish to help stop further damage.  Where do you start?

Depending on what vendor you use to manage your web proxy filters, you may be helping out by simply protecting yourself.  That information should bubble up to their other customers and expand protection.  Another way to help smaller organizations and individuals is to share this information with free security solutions.
 

Google Safe Browsing

Get the biggest bang for your buck by leveraging the Google Search engine which many folks rely on to save them from exposure to typo-squatters and other badness.  URLs can be submitted here: http://www.google.com/safebrowsing/report_badware/

BlueCoat K9

Although it’s advertised as web protection for your children, I find it works for parents and grandparents too.  You can submit URLs and classify them here: http://www1.k9webprotection.com/support/check-site-rating.php

OpenDNS

If you have an OpenDNS account you can submit a domain for tagging as malicious via their dashboard.
 

Your Turn

If you have a favorite list for submitting the results of your malware research, please leave a comment below.

Summary

Microsoft acknowledged the existence of a cross-site scripting (aka XSS) vulnerability in SharePoint Server 2007 and SharePoint Services 3.0.

CVSS(Base): 4.3 (unofficial)

Exploit Availability: public proof-of-concept

Impact: a specifically-crafted URL targeted to the users of an organization will allow arbitrary code to be executed in the context of the user in the security domain of the organization’s SharePoint server. 

Patch Availability: patches are currently unavailable and projected to not be available until June 2010.

Workaround: Microsoft has provided workarounds for both the server and the endpoints.  Details are available: http://blogs.technet.com/srd/archive/2010/04/29/sharepoint-xss-issue.aspx

Urgency: Although the vulnerability taken by it self is not that severe, it does open up opportunities to leverage other exploits that may not be otherwise exposed by your environment.  This issue should not be considered an internal-only problem because your organization’s SharePoint servers are not on the Internet—all users of SharePoint are exposed.  It is recommended that most organizations consider the workarounds proposed by Microsoft.

Microsoft published KB article #983438 late yesterday, with details about a XSS vulnerability within a SharePoint site. This vulnerability may be used to elevate privileges in Sharepoint. SharePoint Services 3.0 and SharePoint 2007 are affected.

Microsoft notes that the vulnerability is harder to exploit if Internet Explorer 8's built in XSS filter is used by administrators of the site. Another action that may help to mitigate the problem is to restrict access to the vulnerable Help.aspx file. With SharePoint using "httponly" cookies, the impact of the vulnerability is somewhat limited.

[1] http://www.microsoft.com/technet/security/advisory/983438.mspx
[2] http://blogs.technet.com/srd/archive/2010/04/29/sharepoint-xss-issue.aspx

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

For last couple of years we have been all witnessing a huge rise in number of social engineering attacks. Rogue/Fake anti-virus programs (see my old diary at http://isc.sans.org/diary.html?storyid=7144) is just one example of such very successful social engineering attacks.

About a week ago a friend of mine e-mailed me about a very suspicious Fan page in Facebook. Since Facebook is so popular, it is not surprising that the bad guys are crafting new attacks that use or abuse various interfaces on Facebook (while we're on that, Facebook has an excellent security team that does not only quickly deals with new attacks/abuses but also has a nice, informative web page at http://www.facebook.com/security that I encourage everyone to check).

Anyway, this suspicious Fan page promised to reveal "The Truth" about text messaging, as you can see in the picture below:

So, the user is asked to become a fan. Once that is done a special screen is revealed that contains a bunch of obfuscated JavaScript and the user is asked to copy&paste this into his browser's address bar! You can probably guess what the encoded JavaScript does. Below you can see two screenshots (shortened) – one with the original, obfuscated JavaScript and one with final, deobfuscated JavaScript:

Deobfuscated JavaScript:



This is what the attackers do:

- first they modify the FB application's HTML (the Truth fan web page that the user adds),
- then they select all contacts (the setTimeout fs[select_all()] call which gets executed after 3 seconds).
- then they invite all user's friends to the group
- finally they display the text in that application

Luckily the final web page, at least when I checked it, didn't contain any malicious code so attacker's goal was probably to create some kind of viral-looking code – similar to clickjacking, but in this case they relied on social engineering and users actually copying their code into the browser.

While I was testing this, I noticed that the javascript: command in browser's address bar works only in Mozilla Firefox and Google Chrome (you can easily test this by writing javascript:alert("test") into the address bar), so the attack didn't work for Internet Explorer users (is that a first ;-).

As this, and many other attacks show, social engineering can go a long way which again reminds us that we must not ignore security awareness.

--
Bojan
INFIGO IS

It's been a while since we talked about Layer 2 Security, I thought that today we might talk about how this applies to Disaster Recovery Sites and processes.

A common requirement for today's Datacenters is a DR (Disaster Recovery) site - a secure, remote location that has a full copy of the critical servers in the primary Datacenter.  The DR site is generally kept to some level of currency, usually the IT group tries to keep the DR servers either within 15, 30 or 60 minutes of the primary servers, or replication happens in the evening when WAN traffic is light, and the DR Servers are at last night's timeframe.  Replication can use things like replication tools for virtual or physical hosts, stretch clusters or SAN mirroring.

Replication aside, a common problem with DR sites is that you can't have a discontiguous subnet in a routed network.  What is meant by that is - if your datacenter is 192.168.10.0/24, you can't have your DR site use that same subnet if you have a routed network between the two sites.  So in a routed network the DR site and the Primary Datacenter need to use different subnet addresses.  There are three main implications for DR that this drives out:

a/ if you declare a disaster, you need to take the primary datacenter offline, and give the DR site that subnet address
b/ this means that there's a significant manual effort to re-address and re-route all the affected subnets
c/ this also means that it's next to impossible to declare a disaster that only affects one or a few servers.

So, is there a way around this, besides buying a new network that will allow you to bridge rather than route between the two subnets? As you've guessed from the title of this article, yes, you can use L2TPv3 (Layer Two Tunnelling Protocol, Version 3) to do exactly this.  On a routed network, L2TPv3 will build a virtual bridge between the two sites. 

Let's run through an example configuration, then discuss how it's built  - -  first, the network diagram:

You can see that the primary and DR Datacenters have the same ip subnet (10.17.10.0/24), but are separated by some arbitrary WAN network

The config snips that build the tunnel that bridges the two datacenters are:

As you'll see, the L2Tpv3 tunnel is usually tied to a loopback address.  Because loopbacks are logical interfaces, they are not subject to media failures, they remain up no matter what (unless you shut them down manually) This allows you a simple way of handling backup and load balanced paths - as long as the respective loopback ip's are routed through both a primary and backup path,  the config is tremendously simplified. 

Almost every networking vendor supports L2TPv3 - it's standards based, described in RFC3931, and is pretty easy on the router/switch CPU.  L2TPv3 is also encryptable - so if the goal is to communicate to the DR site over a public network (like the public internet for instance), the data in transit can be encrypted using standard VPN algorithms (we hope that you're using at least AES256). L2TPv3 can also be prioritized - so, using time based access lists (TBACL), you can for instance run replication at a lower priority during the day, giving priority to VOIP and business apps, then crank the priority up in the evening to catch up on replication of larger servers - just be sure that your time services are solid before you take this route !  Authentication and a truckload of other features are also supported - none of these are covered in this article, what we're describing here is a very basic configuration only.

Things to watch out for - as in any protocol, compromises are made as the protocol is designed, and you'll want to be aware of some of these when you implement.  L2TPv3 has some overhead (it varies, depending on how you implement it).  Also, L2TPv3 is perfectly happy to carry spanning tree BPDU's (Bridge Protocol Datagram Units) - so if you have a potential loop built with a fiber primary and L2TPv3 backup for instance, be sure to factor that into your layer two design.

Other protocols that could be used to deliver similar functions are  Ethernet over MPLS and 802.1QinQ tunnelling (commonly called QinQ).  The downside of these is that they both require support from the service provider.  This means that they'll typically cost money, and generally can't be deployed over public internet.  They're also tough to troubleshoot if you provider makes a config change that breaks things on you a few months after it's running (guaranteed at least a few hours of finger pointing before you start fixing anything!).

  L2TPv3 allows you to dramatically simplify the networking requirements for DR.  With the prevalence of Virtual Datacenters now, it's very common to see a rack of servers running VMs as a primary datacenter, and a smaller rack of servers running the DR site.  Given the replication tools, and now simplified networking, the technical delivery of a DR site can easily be a short 1-2 week project.

Just be sure that you don't treat DR as a purely technical IT project.  Be sure to involve other groups in the business, have them dictate the SLA's for server currency, what services are critical, when to declare emergencies and the rest.  Also be sure not to go overboard on using old gear at the DR site.  Remember, everything data-wise that is at the primary site is also at the DR site - you need the same security controls, change control and the rest at the DR site as you have at the primary, or you've just spent a large effort building a nice backdoor for whoever wants to use it !
 

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

Besides other common sources of real security vulnerabilities made public, such as the full-disclosure mailing-list, zone-h.org (well known for the publication of web defacement and vulnerabilities), or the xssed.com (that publishes websites that are vulnerable to Cross-Site Scripting, XSS), a new website saw the light this month: the Vulnerable Sites Database (http://www.vs-db.info).

This disclosure repository publishes web server and web application vulnerabilities, such as Local File Inclusion (LFI), Remote File Inclusion (RFI), SQL Injection (SQL), Cross-Site Scripting (XSS), Cross-Site REquest Forgery (CSRF), Directory Traversal, etc. The site says they practice "Responsible disclosure no details are made public (details of vulnerabilities are privately reported to developer or web site owners).", with limited details about the vulnerability, but definitely becoming a new wall of shame. A new place to keep an eye on and try not to show up in the picture.

Although similar initiatives existed in the past and then disappear, and although it is too soon to confirm, for now, the site remains very active with multiple daily entries.

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

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

There has been a lot of confusion between the rule update packs.  Some people would see the word "snortrules-snapshot-CURRENT_s.tar.gz" in the rulepack name, or the "snortrules-snapshot-2.8_s.tar.gz" name, and not know which ones to use, or which version of rulepack to use with which version of Snort, so hopefully with this change we've eliminated that confusion.  Now the Snort RulePacks are specific to "Version released".  

What does that mean for you?

If you are using 2.8.5.3 and are updating to 2.8.6 (recommended)

You need to go into your oinkmaster / pulledpork / wget / any updater that you are using, and change the name of the rulepack you are grabbing to the version that is specific to your environment, so if you are changing to 2.8.6, you will not only need to update to 2.8.6, but you will also need to change your rulepack name to:

snortrules-snapshot-2860.tar.gz

If you are using 2.8.5.3, and are NOT planning to update to 2.8.6 at this time

You STILL need to go into your oinkmaster / pulledpork / wget / any updater that you are using and change the name of the rulepack you are pulling to the version that is specific to your environment.

In short, everyone that uses Snort will need to make this change.  For the next 30-days, the "snortrules-snapshot-CURRENT.tar.gz" and "snortrules-snapshot-2.8.tar.gz" links will symlink to the "snortrules-snapshot-2853.tar.gz".  So if you update to 2.8.6 you will need to change to the appropriate rulepack.  

These symlinks will exist for the next 30-days.

If you are a Snort VRT rules subscriber (aka, you pay for it), the symlinks will be of use to you for 30-days, however, you are strongly encouraged to make the change now so that after the symlinks are removed, you won't get 404 errors.

If you are NOT a Snort VRT rules subscriber (aka, registered user, you don't pay for it, and you get the rulepack after the "30-day free window" is lifted) you need to make the change.  So for example, if snortrules-snapshot-CURRENT.tar.gz is in your rule download URL, you need to update it to snortrules-snapshot-2853.tar.gz (or snortrules-snapshot-2860.tar.gz if you update).  The Symlinks will NEVER apply to you, as the new packages won't be available to registered users for 30 days.

If you are running a version of Snort that is < 2.8.5.3.  

You will need to modify oinkmaster / pulledpork / wget / whatever update system you are using to remove 2.8.5.3 version specific rule keywords or Snort will fail to load.

Be sure and read my post in order to make sure you are fully up to date with everything going on. Also be sure and read the VRT blog for further information: http://vrt-sourcefire.blogspot.com

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

It's a phrase that causes dread in the hearts and minds of many a security professional, including myself.

The firewall is on and tightly configured, AV is is installed .. all the usual precautions are in place but inevitably, somehow, every few months, the system becomes infected.

With three family laptops in the house ... well I think you see where this is going.

My wife and kids have been resistant to move to linux systems so I've been considering running a linux hosts with Windows VMs that I just revert to snapshot as needed.

I know I'm not the only one who is in this situation so if you have a better solution, send it in and I'll add it to the diary.

If you're in the same boat that I am, check back as someone may have a solution for you.

Oh, and, uh .. in addition to fixing the laptop, I have a "honey-do" list so I may take a bit to get back to you, but I will.

Anyone know how to install a built in dishwasher?  ;)

Christopher Carboni - Handler On Duty

/* This is a blog cross-post from a two-part article published on Taddong's Security Blog */

This week, during my Internet Storm Center (ISC) shift, Firefox 3.6.3 (the latest available version) displayed a digital certificate error when accessing the ISC login page through SSL/TLS: https://isc.sans.org/myisc.html. I confirmed this on a couple of Firefox instances running on Mac OS X and Windows XP.

We also got a few reports from ISC readers on the same issue, although other people running the same browser version, and even language (EN), on the same OS platforms, didn't get any error message. Finally, the reason was a new ISC digital certificate had been recently installed, and the required intermediate certificate was missing in some web browsers. As a result, the browser couldn't validate the full digital certificate chain to ensure you were really connecting to the website you intended to connect to.

This is a common scenario on security incidents, where Man-in-the-Middle (MitM) attacks or direct web server breaches modify the SSL/TLS certificate offered to the victim, and when accidentally accepted, the attacker can intercept and modify the "secure" HTTPS channel. As you may find yourself dealing with a similar situation in the future... how can you (as I did) check what is the real reason behind the SSL/TLS certificate validation error? By manually verifying the SSL/TLS certificate trust chain, or certificate hierarchy, through openssl.

The goal is to manually follow all the validation steps that are commonly performed it an automatic way by the web browser.

 Step 1: Check the certificate validation error and download the controversial digital certificate.

From the output, ans specifically the verify return code at the end, you can see that the server certificate cannot be verified.

First of all, create a "certs" directory to put all the required files in. Copy and paste to a file ("ISC.pem") the digital certificate, that is, the text between "-----BEGIN CERTIFICATE-----" to "-----END CERTIFICATE-----" (including both lines).

Step 2: Identify the issuer and get its certificate.

Open the "ISC.pem" certificate file (by double-clicking on it on most operating systems) and inspect the following fields:

• The certificate thumbprint or fingerprint that identifies the server certificate: "bd:95:df:ac...46:aa" (SHA1).
• Issuer (under the "Certificate" section): Who did generate and issue the server certificate? "USERTrust Legacy Secure Server CA" from "The USERTRUST Network".
• The "Certificate Authority Key Identifier" or fingerprint (under "Certificate - Extensions"): "af:a4:40:af...86:16".
• The "Authority Information Access" (under the same section): It contains a pointer to the digital certificate of the issuer certification authority (CA): "URI: http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt".

Obtain a copy of the issuer certificate. The most secure option would be to get its certificate through HTTPS and not HTTP, but this only depends on how the CA decided to make it available. Double check with the CA website that the URL and the fingerprint are valid. In this case, USERTrust was acquired by Comodo, and the issuer certificate is available here (https link) and referenced in its list of certificates. This certificate belongs to the USERTrust intermediate CA and was the one not available in Firefox 3.6.3 by default, hence, the root cause of the initial SSL/TLS error on the ISC website.

Although you might be tempted to perform the manual verification all from the command line, it is not the most secure option, as you could be forced to use http vs. https when using wget or curl. Depending on the version and platform of these tools, they may be distributed without a default list of trusted root certificates or do not use the list available on the system. Therefore, ** this is NOT the way to get the intermediate certificate **, use a web browser instead:

Step 3: Try to verify the digital certificate again, but this time make use of the previously downloaded certificate ("USERTrustLegacySecureServerCA.crt").

Before using the downloaded certificate, we need to convert it to the PEM format (not required this time; exemplified later), and build the certificates directory required by the openssl "-CApath" option. The Unix "c_rehash" script helps to create the appropriate directory structure and certificate hash symbolic links. Be sure to rename all the certificates in PEM format to .pem, such as "USERTrustLegacySecureServerCA.crt":

If we try to validate the certificate again, and if we already have the certificates for all the intermediate and root CA's identified in the trust certificate chain stored on the "certs" directory, we will get a positive response: "Verify return code: 0 (ok)".

If the certificate chain or hierarchy contains additional certificates, that is, there are multiple intermediate CA's involved, you may need to repeat the same process and download the certificates for all the other intermediate CA's and the root CA (omitted for brevity). For example, the intermediate USERTrust certificate was issued by "Entrust.net Secure Server Certification Authority". This root CA certificate can be manually obtained in DER format from Entrust website, with a fingerprint of "f0:17:62:13...d0:1a".

Once again, this DER file must be converted to PEM format using openssl:

Finally, you will need to rebuild the certificates directory again, using "c_rehash", once it contains all the intermediate and root CA certificate files that belong to the certificate chain being tested, and try to verify the certificate again.

We used the Internet Storm Center certificate as an example, whose chain has three elements: the ISC (isc.sans.org) certificate, an intermediate USERTrust CA, and the Entrust root CA.

A quick look in the Firefox Preferences (Mac OS X) or Options (Windows and Linux), and specifically on the "Advanced - Encryption - View Certificates - Authorities" section, confirms the intermediate CA certificate from USERTrust was the one missing on Firefox 3.6.3 and, therefore, the one invalidating the certificate trust chain. None of the available USERTrust certificates has the right fingerprint, "af:a4:40:af...86:16".

The client browser does not have the intermediate certificate to be able to verify the full certificate trust chain, and generates the error.

The most common method to avoid this type of certificate validation errors at the web server level, thus for all the web server clients, is by delivering the missing intermediate certificate from the web server itself to the client at connection time.

In the Apache web server world, you simply need to get a copy of the intermediate certificate, in this case "USERTrustLegacySecureServerCA.crt" (see Part 1), and enter a reference to it through the "SSLCertificateChainFile" directive in the Apache configuration file, "httpd.conf", and specifically, in the section associated to the virtual host. Example for the ISC web server (not the real config file):

These three mod_ssl directives point to the server certificate, the server private key, and the intermediate CA certificate, respectively.

End-user awareness regarding the acceptance of invalid digital certificates is a must!

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

Earlier today the shadowserver.org botnet rules were not included in the emergingthreats.org rule set. If you notice that they are missing download the rulset again.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

PDF files are a common way to distribute documents on the Internet and even are used for distributing documents with redacted (removed) content.  However, when you distribute redacted documents make sure that the data you don't want out there isn't, in fact, still in the file.

Case in point, take the upcoming trial of former Governor Rod Blagojevich. He just submitted a motion to force President Obama to testify during his criminal trial.  As you can imagine, there is sensitive information in the motion.  You can read the motion here. The areas that are redacted are pretty obvious.  Now, hit Control-A.  Open a text editor or Microsoft Word (or the like).  Hit Control-C.

Hello, Mr. Face.  Meet, Mr. Palm. This particular mistake isn't new. There was a well-publicized SNAFU involving the US Department of Defense publishing a redacted document that contained classified information which was happily leaked on the Internet using the same method.

If the data is important enough to redact, it is probably important enough to verify that the data is actual gone.  Of course, this is a problem for more than just PDF documents.  An amusing HR trick is to take a look at Microsoft Word resumes, particular the "Track Changes" history.

The take away is to make sure to use commercial tools (or tools specifically designed for the task) to delete, not just mask, redacted information and to check to ensure that the redacted information is not easily retrievable... especially with something as trivial as "Copy-Paste".  If you are too stingy for a commercial software package, just print the document with the redacted portions and re-scan it as PDF to ensure the text is gone.

(You can read about the issue from this article which is heavy on the facts of the particular trial in question).

--
John Bambenek
bambenek at gmail /dot/ com

I have received several emails today "from" support@twitter.com. (Of course they really aren't from support.). We are also receiving reports from our readers that they are seeing the
same thing.    The emails claim that you have unread messages from Twitter and contain a link that you can supposedly click on to view the messages.  The links are to various
locations other than Twitter.  Don't be fooled.  The emails are not from Twitter and the links are not at Twitter.  Just a reminder NEVER click on links in emails.  Always login to your
account to check it out.  I have contacted Twitter and reported the emails. 
 

Thanks to Alex for reporting his receipt of the emails to us.

Deb Hale Long Lines, LLC

Our community has a unified disaster system.  We have several organizations, local government, county government, city government, hospitals, school district and businesses involved in Disaster Planning and Response. Because we are in the northwest corner of the state of Iowa with border neighbors in Nebraska and South Dakota we often have regional exercises.  Several times a year we have Disaster Exercises where all of our teams "play together".

Today was one of those days.  At 8AM this morning the team started to gather at the local event center to prepare for the arrival of the exercise "victims".  The victims were made up of students from local high schools and colleges and a few "adult chaperone" victims.  The scenario was to be a Bioterrorist event at a sold out concert at the local event center.  All of the players arrived and were briefed on the activities of the day.  At precisely 9AM the exercise began.  The first call went out to our 911 Center to notify them that an event was unfolding at the local event center.  Information was being relayed to the 911 operator that something was going on at the Event Center with approximately 130 victims exhibiting various breathing/respiratory symptoms. The 911 operator was going through their normal fact finding questions when about 3 minutes into the call the 911 operator indicated that her computer had just quit.  She was about to transfer the call to another dispatcher when all of the computers in the 911 center began to power down.  At this point they knew something was going on but just not sure what. 

Our on scene team at first thought that this was someone's idea of adding a little twist to the exercise.  The 911 operator assured us that it was not.  A call was made to the IT department and the
911 center soon discovered that the problem was not limited to their computers but that computers all over the system were shutting down.  The local county and city governments share the network, resources and support staff for the computer systems.  They began getting calls from city and county employees from all areas, police, fire, emergency management, financial, HR, etc.  The first thing that came to mind was that a worm/virus was wrecking havoc on the City/County network.  They began an emergency shutdown of all equipment in the network to prevent spread and additional damage from being done. 

About an hour into their investigation they discovered that the culprit for the shutdown was not a worm/virus but an update that was being pushed out for the McAfee Antivirus program.  The IT staff will have a long night tonight getting all of the machines that were damaged repaired and ready to go for the morning startup. They expect to have 80% of the machines backup by tomorrow morning and 99% back up by lunch time tomorrow.

So you may assume that the loss of the 911 Center caused the Disaster Exercise to be called.  After all, how can you have a Disaster without your 911 Operators, Right? Not us.  When the 911 Center went offline at 9:05am we had to decide if we were to continue the exercise or call it due to the loss of 911.  Our EMS Director for the County decided to continue the exercise.  He began to do dispatch and communication using our 800Mhz shared radio system.  We continued the exercise, decontaminated and transported roughly 120 people to the local hospitals. We successfully completed the exercise at 11 am. 

While we were in the Hot Wash Debriefing we received a call letting us know that it was not a worm/virus but was the McAfee update that caused the entire City/County to come to a screeching halt.  Many of the individuals in the debriefing grabbed cell phones to call back to the office with the news of what happened.  For a few it was too late, the updates had already run and their organizations too were experiencing the same problems.  For those that hadn't updated yet the updates were turned off. Others were relieved to find out that they were using the competitors AV and were not in any danger.

Thanks to McAfee we were forced to test our response to a Disaster while in the midst of a real "disaster".  The positive that came out of the exercise is the fact that we had a successful exercise while using our "backup" communication system.  It was a true test of our ability to adjust to and respond to a disaster in less than perfect circumstances.  Isn't that really what our goal was?  We all know that many "disasters" having multiple components and today we saw firsthand how true that is.

Deb Hale Long Lines, LLC

The MS10-025 security update (affects only Windows 2000 Server) has been pulled today because Microsoft has found it did not address the underlying issue effectively. A re-release of the update is planned for next week. Additional information available here.

-----------

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

The Open Web Application Security Project (OWASP) released an updated version of its "Top 10" [1] . If you are in any way responsible for the development, maintenance or general upkeep of web applications and related infrastructure, this is a MUST READ document for you.

According to the OWASP press release, this update focuses more on "Risks" vs. "Vulnerabilities".

[1] http://www.owasp.org/index.php/Top_10

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

We recently installed a new SSL certificate for "isc.sans.org" . Our goal was to support some of the old ISC hostnames like incidents.org. However, we had reports that some browsers didn't support the new certificate. As of today, this should be fixed. However, if you are still having issues, please let us know.

Before you send your message, please click on the "Debug" link at the bottom of the page (it is a bit hidden in the dark blue footer). Please include the output of the debug page to make it easier for us to help you. This is true for other bug reports as well.

Bug reports may be submitted via our contact page [1]  or via email to handlers@sans.org .

URLs to test the SSL certificate: https://isc.sans.org/login.html and https://isc.sans.edu/login.html (the index page includes content from non-SSL sites)

Another "public service" announcement: Our URLs end in ".html" for the last couple years. However, many links still point to the old ".php" version. We are using redirect to accommodate them. If you are linking to ISC, please make sure you link to the ".html" version.

[1] https://isc.sans.org/contact.html

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

McAfee's "DAT" file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and loose all network access. We have individual reports of other versions of Windows being affected as well. However, only particular configurations of these versions appear affected. The bad DAT file may infect individual workstations as well as workstations connected to a domain. The use of "ePolicyOrchestrator", which is used to update virus definitions across a network, appears to have lead to a faster spread of the bad DAT file. The ePolicyOrchestrator is used to update "DAT" files throughout enterprises. It can not be used to undo this bad signature because affected system will lose network connectivity.

The problem is a false positive which identifies a regular Windows binary, "svchost.exe", as "W32/Wecorl.a", a virus. If you are affected, you will see a message like:

The file C:WINDOWSsystem32svchost.exe contains the W32/Wecorl.a Virus. 
Undetermined clean error, OAS denied access and continued. 
Detected using Scan engine version 5400.1158 DAT version 5958.0000.

McAfee released an updated DAT file, and an "EXTRA.DAT" file to fix the problem. An EXTRA.DAT file is a patch to just fix the bad signature. McAfee's support web sites currently respond slowly and are down at times, likely due to the increased load caused by this issue.

Several readers reported that this procedure worked to recover:

1 - Boot the system in "Safe Mode"
2 - copy extra.dat in c:/program files/common files/mcafee/engine
3 - reboot.

If you lost "svchost.exe", then you need to copy it back to c:/Windows/system32/svchost.exe while in safe mode.

Additional information from McAfee: http://community.mcafee.com/thread/24056?tstart=0
McAfee Knowledgebase Article: https://kc.mcafee.com/corporate/index?page=content&id=KB68780
EXTRA.DAT file: http://home.mcafee.com/VirusInfo/VirusProfile.aspx?key=265240.

 THANKS TO ALL THE CONTRIBUTORS! We got too many to mention here. Please keep it coming using our contact page: http://isc.sans.org/contact.html

-----------

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

... I mean a big volcano ash cloud, like the one from the Iceland Eyjafjalla volcano, that is affecting Europe (and the whole world) since the past week.

If you are not ready, this is a good opportunity to learn the lesson, and plan for the worse. Review your incident response, emergency, and business continuity plans, and evaluate this kind of incident. If you were cautious enough perhaps you already included it in your plans, but more realistically, this type of event had a low probability in your risk analysis. Reality has demonstrated it is time to reconsider it, specially, with the threat of other nearby volcanoes starting to get active, such as Katla.

Having found myself trapped on the middle of the current European nightmare (news make it a a bed of roses compared to what it is really going on), and more specifically, on the main Paris airport - Charles De Gaulle (CDG), closed since Thursday night, while trying to escape I identified three scenarios for your people in this situation (from low to high based on its critical nature and range of options available):

• Your flight (or travel plans) gets canceled on origin. Lucky you, start to find an alternate transportation method as soon as possible, as you will be competing with a few other people, but you have all your local resources available to accomplish the task.
• Your flight gets canceled on destination (return flight). The situation is pretty similar to the previous one, although you will be more limited than in origin. In reality, for both situations, the success rate is based on how close was your flight and the cancellation event to the real problem. If you are one of the first being canceled, there is a much better chance you can find an alternate transport.
• You get caught in transit. Moooove!!! You are competing with thousands of people trying to reach to the same (or other) destination(s). Once you are confirmed there is no chance of being there in almost a week, then the same competition starts to get back to your origin country/city.

Plan for the worse: In this case, the air transportation closure was surrounded by a train strike in France. The result was it became almost impossible to scape from the city. Rental cars were not available, and had prohibitive prices, in the range of the thousand of euros for a few hundred kilometers. There were no seats in the few available trains for 4-5 days. You can only be lucky and get out by road, catching a ticket on a backup coach long trip (hired for the occasion).

Do you have an adequate technological infrastructure to keep your business moving without requiring your people (or customers) to meet each other face to face (such as, videoconference)?

Is the available solution a valid option for those in transit, in the middle of nowhere, with low bandwidth Internet connections in the best case?

If you have suffered the current situation and want to share your opinion, send you comments through our contact page.

--
Raul Siles (www.raulsiles.com)
Taddong is comming soon...

When ISC reader Josh realized that only five people at his firm had received the "legal threat" malware email that we reported on earlier, he started digging. The targeting of the bad guys had been spot on, all five recipients were in fact involved in the handling of money for Josh's employer, a large real estate firm. Two were in cash operations, two in accounts payable, and one in treasury/finance. After a couple minutes of googling, one potential culprit was found: All five staff members were maintaining profiles on LinkedIn, and had their profile proudly proclaim a job title that made it patently obvious that they had access to the firm's banking information.

Can any other of our readers corroborate this finding? If last week's "Legal Threat" email also only targeted 2-5 specific users in your firm, and the targeting was very precise, please let us know if you have any indication on where and how the bad guys could have gotten their intel.

We are receiving numerous reports that several web sites hosted through Network Solutions have apparently been compromised and amended with malicious JavaScript.  Network Solutions has by now acknowledged that things ain't how they are supposed to be, and that they are working hard on a fix.  This comes only days after an earlier round of hacks that also affected several WordPress customers of the same hoster.

 -----------

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

While I do take the time to look at General Information surrounding each Security Update
that Microsoft releases, a couple of news articles here and here that surfaced this
week (pertaining to the MS10-021 Security Update) made me go back and have a closer
look at the full Microsoft Security Bulletin details for MS10-021 here.

If you were to open the Frequently Asked Questions (FAQ) section (a section I honestly
don't take the time to read) sure enough, there is a general statement concerning the
prevention of the update from installing "if certain abnormal conditions exist on
32-bit systems".

So if you happened to be using WinXP and encountered an error while performing an Update
for MS10-021, Microsoft has provided a link here to officially explain what the
error means and what resolution steps can be taken.

Thanks to reader Angela for submitting the second news article referencing this condition.
 
G.N. White
Handler on Duty
 

 We have had a few reports on IP addresses in certain parts of the world sending INVITE requests to Asterix servers and attempting to make calls.  Looking at the port 5060 data there does seem to be an uptick in targets. 

  

If you have some packet captures of this or logs. I'd be interested to take a look at them. 

Thanks

Mark

Joining the club is Adobe who is releasing their update as well to Reader and Acrobat http://www.adobe.com/support/security/bulletins/apsb10-09.html 

Update

Joining the "and me too" club is java with update 20.  Two security fixes by the looks of the release notes.  http://java.sun.com/javase/6/webnotes/6u20.html

Happy patching, as always test before doing production and Friday 5pm is never a good time to push out updates.

Mark H - Shearwater

A reader reminded us of the impending April 15 deadline for the support of ClamAV version 0.94 and earlier. ClamAV will be releasing signatures greater than 980 bytes on May 15.  ClamAV version 0.94 and earlier will not be able to deal with these.  To prevent issues on April 15 there will be a signature released that effectively disables version older than 1 year (version 0.94 and earlier). The application will not start.  

Most of you will no doubt already be using a later version, but the product is used in many a gateway and is used as part of a number of commercial appliances.  If you are not certain what version you are using, you may wish to do a quick check.  

Some more information is here http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/

Mark H 

Just when you thought you had finished patching for the week.  Oracle has released 47 security fixes for its products. This includes the SUN products. In addition to this there will be a number of additional patches that address interdependencies between products.  If you are running Oracle products you'll want to have a look here http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuapr2010.html  to see if your product is affected.  As always make sure you test before putting it into production. 

Mark H - Shearwater

Adobe has also released updates for their Reader and Acrobat products. The advisory is available here: http://www.adobe.com/support/security/bulletins/apsb10-09.html

" Critical vulnerabilities have been identified in Adobe Reader 9.3.1 (and earlier versions) for Windows, Macintosh, and UNIX, Adobe Acrobat 9.3.1 (and earlier versions) for Windows and Macintosh, and Adobe Reader 8.2.1 (and earlier versions) and Adobe Acrobat 8.2.1 (and earlier versions) for Windows and Macintosh. These vulnerabilities could cause the application to crash and could potentially allow an attacker to take control of the affected system."  Essentially opening a PDF file within an affected version of the products can possibly lead to arbitrary code execution. The updates cover the following CVE entries: CVE-2010-0190, CVE-2010-0191, CVE-2010-0192, CVE-2010-0193, CVE-2010-0194, CVE-2010-0195, CVE-2010-0196, CVE-2010-0197, CVE-2010-0198, CVE-2010-0199, CVE-2010-0201, CVE-2010-0202, CVE-2010-0203, CVE-2010-0204, CVE-2010-1241.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

Update 2 

Looks like Don's issue relates to old, old versions of software

 Update

Don reported the following:

"I had a problem with MS0-020 (KB980232) and had to uninstall it.  --snip--"

 Overview of the April 2010 Microsoft Patches and their status.

A few readers pointed us to an announcement by the Apache Foundation about a breach of their bugtracking software.

First of all: Kudos to Apache for publishing a nice and detailed incident report [1]. The attack included a number of elements that in itself are frequently ignored, but if combined in an attack like this one, turn out to be deadly.

Reading the blog post, a cross site scripting attack or simple password brute forcing was used to compromise the attack. While either attack appears to have the potential to succeed, it is not clear which one was finally used to gain access.

The cross site scripting attack used an additional twist in hiding the malicious URL via tinyurl.com. This made it more likely that an administrator would actually click on the URL.

Once the bug tracking system was compromised, the attacker modified it to log passwords. An administrator happened to use the same password to log in to the bug tracker as they use on the system itself.

Lets skip to the lessons learned:

• While it is not clear if the XSS attack was successful, it is important to note that attacks like this happen and can work. A simple mitigation would be to use the "httponly" option for session cookies. This way, session cookies can not be stolen via injected Javascript. It doesn't fix the XSS vulnerability, but it makes exploiting it harder.
• It is important to mitigate against brute forcing attacks. This mitigation should include two parts: (1) detection of brute force attacks and an automatic lock out mechanism. (2) a strong password policy backed up by password audits (to avoid "strong" passwords like password1! that may satisfy the policy but are still easily guessed.
• Don't forget the ability to quickly un-lock accounts to avoid a brute force attack turning into a DoS attack.
• Shared passwords are bad. Really bad. I actually recommend that people use some form of "password safe" software or write them down (yes... flame me for it. But I currently list 540 strong passwords). In the past I recommended different types of passwords for different purposes. But I found that sometimes a password starts out as "unimportant" and later becomes "important".

See the full blog post for more details and more lessons learned.

[1] https://blogs.apache.org/infra/entry/apache_org_04_09_2010

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

This is more of a reminder then "breaking news". But it may be worthwhile to include this in an awareness newsletter or similar presentation to keep your staff up to date on current social engineering malware. Our reader Andy sent us this e-mail he received. The domain name in the link has been modified. We of course had similar malware in the past claiming to be court documents or intellectual property violation notices.

----------------
Subject: Notice: Contract terms breached.

5 April, 2010
Hello,

You are hereby put on notice that as of 7/1/2010 you are in breach of our contract dated 3/12/2007.
The nature of said breach is: False Advertising, Breach of Contract, Bad faith Breach of Contract, Fraud and Deceit.
It is our desire to inform you of the foregoing and afford you the opportunity to cure said breach.
You may in any event be held responsible for all damages arising from said breach.

To view a copy of the complaint please visit our company website: http://---URL REMOVED---/
Please use the CASE ID located at the end of the document to find the copy of the complaint.


You have until 10th of May 2010 to cure said breach, after which we will be forced to pursue further legal action.
Regards,
Jim Karter

CASE ID: 4322524

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

As security testers we tend to always be on the lookout for new or updated tools to test the security of web based applications. Some of these are of course commercial, but most of us also make extensive use of the free and/or open source offerings. In no particular order here are the ones I am currently making use of:

Burp Suite - http://portswigger.net/suite/
Fiddler2 - http://www.fiddler2.com/fiddler2/
Watcher - http://websecuritytool.codeplex.com/
Ratproxy - http://code.google.com/p/ratproxy/
Grendel Scan - http://grendel-scan.com/
W3AF - http://w3af.sourceforge.net/
Skipfish - http://code.google.com/p/skipfish/
Exploit-me - http://labs.securitycompass.com/index.php/exploit-me/
Wikto - http://www.sensepost.com/research/wikto/
Tamper data - http://tamperdata.mozdev.org/
Wmap - http://www.metasploit.com/redmine/projects/framework/wiki/WMAP
Nikto - http://cirt.net/nikto2

Special mention to Samurai WTF - http://samurai.inguardians.com/

Please let us know if there are any I haven't mentioned that you find useful, and why! I'll add them to an update of the list after wards.

firebug - http://getfirebug.com/
webscarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
curl and wget
Various versions of different web browsers
Various scripts in different scripting languages

I've deliberately decided to exclude commercial scanners, either web application specific or network scanners that can also do some web application tests.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

Sung to the tune of 'Get yer ya-ya's out' Street Fighting Man http://seclists.org/nanog/2010/Apr/821

From their announcement "Team Cymru is pleased to announce a significant addition to our bogon reference project.  The new portions of the project are offered at no cost to the community, and the original bogon lists and feeds are not being changed or cancelled, just augmented."

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

One of our readers recently asked us if we were aware of any integrated tools that would let an analyst compare network events against process events on a specific computer.  As he pointed out, there are many tools that can tell you what is going on network-wise (netstat, tcpdump, portmon, etc.) and plenty that can tell you what the computer is doing (procmon, process explorer, etc.) but none that bring them all together.  Here is how he described his wish list:

I want a tool (or set of tools) for monitoring a Windows PC in such a way that:

* it monitors packets in pcap, like tcpdump and
* it monitors each process network activity like netstat -anpb while
* being able to keep log and records of process activity changes, not just showing the past few seconds' changes.

A sample usecase scenario: I wake up in the morning and check my Wireshark or NetWitness Investigator logs and notice a strange session and I want to be able to quickly glue that session to a process that has been responsible for that...

While a mix of netstat and command-line Foo for piping outputs to a log file among Wireshark can do the job, I hope there must be a decent and handy tool out there, for this purpose.

So, readers - got any ideas?  We had a lively debate between some of the handlers earlier today but could not come up with exactly what he is looking for.  If you know of such a tool please use the comment feature below to tell us all about it.  Of course, we are aware of Microsoft's Sysinternals suite by Mark Russinovich but that is not what our reader is looking for. 

Thanks for any ideas.

Marcus H. Sachs
Director, SANS Internet Storm Center

Update: It didn't take long. This vulnerability is now used in the wild. For details, see http://krebsonsecurity.com/2010/04/unpatched-java-exploit-spotted-in-the-wild/

---

It looks like Tavis Ormandy posted an interesting "bug" in javaws application to Full Disclosure yesterday. I have yet to verify all the details, but if what Tavis posted is true it opens up a rather interesting scenario for an attacker. (one which Tavis in his PoC code outlines rather well!)  We will try and update this post as more information is discovered.  I have been talking to a few other security researchers who have verified his claims, i have yet to successfully verify his PoC on any of my vms.  (might be version issues)

Tavis's post (full information here)

http://seclists.org/fulldisclosure/2010/Apr/119

Tavis also did an excellent job in not only formatting of his alert, but also in the content (again, i have yet to verify all this my self!). The below is a snippet of the mitigation portion of his alert. 

-------------------
Mitigation
-----------------------

If you believe your users may be affected, you should consider applying one of
the workarounds described below as a matter of urgency.

- Internet Explorer users can be protected by temporarily setting the killbit
  on CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA. To the best of my knowledge, the
  deployment toolkit is not in widespread usage and is unlikely to impact end
  users.

- Mozilla Firefox and other NPAPI based browser users can be protected using
  File System ACLs to prevent access to npdeploytk.dll. These ACLs can also be
  managed via GPO.

Detailed documentation on killbits is provided by Microsoft here

http://support.microsoft.com/kb/240797

Domain administrators can deploy killbits and File System ACLs using GPOs, for
more information on Group Policy, see Microsoft's Group Policy site, here

http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx

You may be tempted to kill the HKLM...JNLPFileShellOpenCommand key, but
the author does not believe this is sufficient, as the plugin also provides
enough functionality to install and downgrade JRE installations without
prompting (seriously). However, if none of your affected users are local
Administrators, this solution may work (untested).

As always, if you do not require this feature, consider permanently disabling
it in order to reduce attack surface.

 A quick update on the outage for our site and related processing. 

Yesterday we experienced a power outage as well as a link outage in the main processing location for the storm centre.  This affected elements of the web site, but also our contact form, the handlers-a-t-sans.org email address and log processing.  These three issues have been resolved and are relatively stable (unlike the link at one datacentre).

I have replied to all the emails that made it through in the last 24 hours.  If however you have not yet received a reply please do re-submit your question, query, or information and we'll process it as per normal.  

With regards to log processing. The servers are happily churning through the backlog of data and will catch up, so you should receive confirmations.  

There are still some elements of the site that may be broken, however the team is working through these.  If after, say 12 hours from now, you find something that is still broken please let us know. 

Thanks

Mark 

 Late last month Didier discussed a POC relating to the /launch functionality in PDF files (http://isc.sans.org/diary.html?storyid=8545)

Adobe published a reply and a work around for this on their blog pages (http://blogs.adobe.com/adobereader/2010/04/didier_stevens_launch_function.html)

The article shows a few default settings that can be changed and a registry modification to reduce the risk of this type of attack.  Adobe is examining the issue and are deciding what to do.  They may make a fix available as part of their quarterly updates to the product.

Mark 

Microsoft announced earlier today that they will be releasing a total of 11 bulletins (5 critical, 5 important, 1 moderate). If exploited, eight of the bulletins could allow for remote code execution. More details available here.

-----------

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

First the Nmap Project was once again accepted for the Google
Summer of Code program, so he will have full time coding help this
summer!  SoC previously brought them the Nmap Scripting Engine, Zenmap,
Ncat, 2nd generation OS detection, and great developers such as David
Fifield, Doug Hoyte, and Patrick Donnelly.  But one of their biggest
challenges is getting the word out.  They won't get great applicants if
they don't know about the program.  So if you know any college/grad
students (or are one) who might be interested, please point them to
http://nmap.org/soc/ ASAP.  They gain valuable experience writing code
used by millions of people and even earn a $5,000 stipend!  But the
application deadline is THIS FRIDAY at NOON U.S. Pacific Time (that is
19:00 UTC).  Our project ideas are listed at http://nmap.org/soc/.

He is also pleased to announce the 2010 Nmap/Sectools Survey! He
previously ran this survey in 2000, 2003, and 2006, and it helped
guide Nmap development as well as sharing our collective wisdom
through http://sectools.org/.  He had 3,243 responses in 2006 and is
trying to reach 5,000 this year.  And this year he has upped the ante
by offering prizes!  So please take this quick survey, and in return
they will build you a better Nmap and a new and improved Sectools.Org:

http://nmap.org/survey/

We are still having connectivity issues at one of our hosting locations. Most of the ISC site is now working ok. DShield.org is just showing the ISC page for now (working on this).

E-Mail is still a problem, and reports are currently not processed. But the contact form should be working. Reports will be processed once we get back online.

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

I know that most of you are probably already sick of malicious PDF documents, but one of our readers, Will Thomson, sent a really interesting malicious PDF document that used some more advanced obfuscation techniques that I wanted to share with everyone. So, let's get to work.

The PDF document Will sent contains a JavaScript section that gets called immediately after opening the document. This is today really standard. The JavaScript section is relatively short and we can see that it uses the app.doc.getAnnots() (line 17) call to get Annotations, from the code excerpt below:

When called like this, the app.doc.getAnnots() call will return an array of objects that will contain all annotations. This is important to remember.

Now, in line 4 you can see that the num variable is set to 1 which will cause the sum variable (line 18) to contain the second annotation's subject field (array members start with 0). This will then be deobfuscated with a loop at line 27 and finally at line 39 the second JavaScript layer gets called with an eval() call.

This second JavaScript layer at first sight looks familiar – the huge "blob" of obfuscated data is passed as an argument to the function called iXM__8f_ITb, which is then deobfuscated. One trap is immediately visible – the author used the arguments.callee() call to prevent us from modifying the deobfuscation function but this can normally be easily evaded by redefining the eval() call. However, if this is done, and the function is called it will only print out some meaningless numbers! Yet, the PDF is malicious when tested on a vulnerable Acrobat Reader so something else must be going on here.

Take a look at the code below, which I tidied a bit for you so you can read it easier:

Especially important are lines 6-13. So, what do the attackers do here:

• First the variable n_AXr11_7Wdj is assigned value 0,
• Then, on line 8, the existence of the app object is tested. This object is created by Acrobat Reader so if you run this outside (for example, with SpiderMonkey or another JavaScript interpreter) this call will fail since the object will not exist. We can create that object easily, but we are still not done,
• On line 10, the h__l_S_1__f variable will contain pr[n_AXr11_7Wdj].subject. Since n_AXr11_7Wdj is 0, this equals to pr[0].subject. Remember what the pr array is? It contains annotations. In other words, this will use the first annotation.

If all this passed correctly, the contents of first annotation are used as the deobfuscation key – if any part fails, the deobfuscation function will simply just print some numbers. Clever indeed! The final JavaScript layer just exploits the old Collab.collectEmailInfo vulnerability.

Why are the attackers going to this length with obfuscation you might ask? Well, the obvious answer is to make detection (and analysis) more difficult. And it indeed looks as they were successful with this since when I uploaded the document to VirusTotal (VT) only 6 out of 39 AV programs detected it as malicious, with most of big names missing it. Wepawet, another great service for analyzing malicious JavaScript/PDF/Flash files by UCSB (Wepawet) handled the file better and managed to analyze it correctly – kudos to the UCSB team.

While there has been a lot of words and warnings about how patching Adobe Reader installations is important, I would like to stress this out again as attackers are clearly not sleeping.

--
Bojan
INFIGO IS

We are running out of our secondary location, however this means that not all parts of the site will work.

This includes the contact form and the email address handlers@sans.org.

To contact us please use the alternate address handlers-at-handlers.dshield.org

MH

Promoting Security Awareness  is an ongoing challenge in our field.  Without a good understanding of Security Awareness and issues, getting appreciation at the senior management level for security issues is a real problem.  Security Awareness is critical in influencing business decisions to include (and hopefully fund) security components into every project, protecting the corporate assets from both theft and lawsuits.

However, Security Awareness does not mean the same thing to everyone in a company. 

Senior Management, for instance, will be more concerned with legal and regulatory requirements, as well as the impacts of security on overall corporate performance. 

Department managers will be more zoned in on budgets and funding, as well as directing their reporting groups towards policy compliance. 

People who work on the actual deliverables of the company may be concerned about personal incentives, system uptime, or may be influenced by corporate policies.

Awareness for developers tends to concentrate on secure coding and peaceful co-existence with system administrators who are enforcing policies at a technical level in the Datacenter and desktops.

From a Security Awareness perspective the blanket term “end user” grows to encompass many audiences – not only folks with basic desks and phones, but developers, senior managers, salespeople, engineers, health-care professionals, all kinds of people with different concerns, different goals, and a different set of reasons/excuses for exceptions to one thing or another. 

Sadly, even today almost everyone tends to view security concerns as impediments to their job rather than as actions and factors that assist and support them.

So how do we influence our coworkers or customers to factor Security Awareness into their daily decisions and actions? 

The short answer is "it varies". 

The best answer that I’ve seen is that we need a toolkit of methods, and for any particular audience we need to dip into that arsenal and pick the 2 or 3 or 5 methods that we think will work best to deliver your message successfully, get them to take your message to heart and see that desired positive change in behavior. 

Over time, the goal of Security Awareness is to have your organization or client organization realize measurable movement towards the positive side of spectrum  - both of actual awareness of security concerns and measurable security behaviors and metrics.  As in most things, Security Awareness is all about the journey, there is no destination – you can always get better, but you never “arrive.”

I’m very interested in how people are delivering security messages to their organizations and customer organizations, raising awareness and influencing behaviors (in a positive way) in that process.  If you have a moment, we’d really appreciate your input in the survey attached to this diary.  It's set up as a matrix, feel free to indicate whichever methods you've seen used successfully in your situation.  Multiple answers are ok and are encouraged (just please don't click them all).  Feel free to post any text input either in the survey text fields or in the diary comments (at the bottom of this page)

We’ll collect data on this survey and report back in a follow-up diary in a couple of weeks.
 

 (This survey requires Javascript - If you are running Noscript or a similar tool you will need to "permit" this site)
(Depending on your browser this survey will open in a new browser tab or a new browser window)

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

The application development community has come a long way in armoring their programs against the OWASP Top Ten and SANS Top 25 type of security problems, and I'm not being cynical here: While SQL injection and Cross Site Scripting are still widespread, most developers nowadays know about these problems, and are even competent to avoid them if not pressed by due dates, budgets or management to take short cuts. 

Cue the next big thing that InfoSec will have to convey to the developer community: How to write code that produces meaningful application logs. As an example, almost every country has laws in the books that ask for safeguarding of sensitive medical data, and these laws are explicit in their demands on the security controls that need to be in place. Like diligent monitoring of logs.

Well, yeah. But if an application log of a medical application looks like the example below

2010-04-06 09:57:18,773 [arch.PROCESS_CONV] INFO - JavaToDataObjectConverter.convert TransportData _PI:9d030227.c3692d30 notifyDataFlowCompletionResponse Start
2010-04-06 09:57:18,773 [arch.PROCESS_MAP] INFO - ServiceResponseTranslator.buildMessage TransportData notifyDataFlowCompletionResponse Start
2010-04-06 09:57:18,212 [arch.PROCESS_SERVICE] INFO - Invoker.createRequest TransportData notifyDataFlowCompletion

then nobody except the developer him/herself can do any monitoring. An application log file is not supposed to be a techie-only pile of debugging jargon. In my ideal world of application auditing, the authorized application users themselves would see (and be able to interpret) some of the audit records, and thus collaboratively ensure acceptable use.

Imagine, for example, an application in a hospital that displays medical files and x-ray pics. An "audit log" somewhere on the server does very little good, but displaying underneath a celebrity's X-ray picture who of the medical staff last looked at the same picture: now there's effective auditing. Doctor A is far more likely to think it odd that Doctor B looked at this x-ray than, say, some IT techie in the backroom who was charged with watching the hospitals "Security Info and Event Management" (SIEM) tool. 

Firstly though, the logs have to become more meaningful: Who did when what to which record is pretty much all it takes. Too much volume? Well, then focus on read access to privacy relevant/sensitive objects, and write access to integrity relevant objects like account balances. Once we're there, we can always go further if needed.

But, dear developer, please spare us the debug log that got swiftly re-branded into "audit log" five minutes before project completion.

Last Wednesday an interesting report was released called "The Financial Management of Cyber Risk: An Implementation Framework for CFOs".  Please take advantage of this new document that the Internet Security Alliance (ISA) and the American National Standards Institute (ANSI) have graciously provided.  The PDF guide is free for download, after registering, on the ANSI web site.  The document assists in assigning dollar amounts to the possible cyber risks and is further designed to place cyber attack mitigation on the C-level function. 

The report is endorsed by Melissa Hathaway, former Acting Senior Director for Cyberspace for the National Security Council.  The CFO guide is a direct response to the Cyberspace Policy Review released last May.   That report stated, "Between 2008 and 2009, American business losses due to cyberattacks grew to more than $1 trillion in intellectual property."  Copies of the documents from the Fed review can be found on the White House website.  (http://www.whitehouse.gov/cyberreview/documents)

Just another opportunity to educate your management staff on the possible financial repercussions of cyber attacks.   

Happy Easter!

Mari Nichols -  Handler on Duty

Oracle released a collection of patches for multiple security vulnerabilities in the Java SE and Java for Business which includes security and non-security fixes. This update contains 27 new security fixes across all products. The security bulletin is posted here.

Note: Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply CPU fixes as soon as possible.

Affected product releases and versions:

Java SE:

JDK and JRE 6 Update 18 and earlier for Windows, Solaris, and Linux
JDK 5.0 Update 23 and earlier for Solaris
SDK 1.4.2_25 and earlier for Solaris

The Java SE update is available here.

Java for Business:

JDK and JRE 6 Update 18 and earlier for Windows, Solaris and Linux
JDK and JRE 5.0 Update 23 and earlier for Windows, Solaris and Linux
SDK and JRE 1.4.2_25 and earlier for Windows, Solaris and Linux

The Java for Business update is available here.

-----------

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

Foxit Reader has released a security that fixes an issue that runs an embedded executable in a PDF document without asking the user's permission. The update can be launch from Foxit (select version 3.2.1.0401) or download it from here.

This update is related to a recent ISC diary "PDF Arbitrary Code Execution - vulnerable by design" published on the 31 March 2010.
 

-----------

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

QuickTime 7.6.6 addresses 16 CVEs affecting both Windows and Mac. Additional information regarding the security fixes incorporated in this version is available here. Apple has rated several CVEs can lead to an unexpected application termination or arbitrary code execution.

iTunes 9.1 addresses 7 CVEs affecting Windows and Mac. Additional information regarding the security fixes incorporated in this version is available here. Apple has rated several CVEs can lead to an unexpected application termination or arbitrary code execution including Denial of Service.
 

-----------

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

VMware has released the security advisory VMSA-2010-0006 affecting the ESX Service Console. Update are available for samba and acpid.

The following CVE numbers are part of this advisory: CVE-2009-2906, CVE-2009-1888, CVE-2009-2813, CVE-2009-2948, CVE-2009-0798. Additional information is available here.

-----------

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

Our apologies, e-mail (including via the contact page) is not getting through to us since about 17:00 EDT (21:00 UTC).  We are aware of the issue and it is being worked on.  If you got a bounce message, you'll probably need to resend once the problems are fixed.  Again, we apologize and hope to have things fixed soon.

Update: (2010-04-01 01:50 UTC) E-mail seems to be flowing again.  Thanx for your patience.  If you tried to send anything in the last few hours, please resend.

---------------
Jim Clausing, jclausing --at-- isc [dot] sans (dot) org