This article over on the Websense blog is warning about a new mass sql-injection attack that they have dubbed "Lizamoon".  (As that's the domain that the sql injection attack is referring people to.)

By searching for the string in Google, an estimated 226,000 sites have been attacked and defaced with this method.  (We know that the numbers from Google aren't accurate, we are putting them there to display the size of the attack -- BIG.)

While I don't necessarily agree with the title of the article (implying that iTunes is infected), this attack and the Mysql attack from earlier this week are just more examples of how there isn't enough emphasis put on preventing sql injection.

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

Normally two Cisco security advisories would warrant a "One-liner" of their existence, with URLs pointing to them. In this case eagle eye fellow handler Daniel noticed some of the wording in one of them. Its name is "Cisco Secure Access Control System Unauthorized Password Change Vulnerability" and it lives at: http://www.cisco.com/warp/public/707/cisco-sa-20110330-acs.shtml

This is the summary: "A vulnerability exists in some Cisco Secure Access Control System (ACS) versions that could allow a remote, unauthenticated attacker to change the password of any user account to any value without providing the account's previous password. Successful exploitation requires the user account to be defined on the internal identity store. "

So essentially pretty much anyone can change anyone elses password, any time they feel like it, as long as they know the user account. So far so good. The interesting part comes next: "This vulnerability does not allow an attacker to perform any other changes to the ACS database. That is, an attacker cannot change access policies, device properties, or any account attributes except the user password."

So, hypothetically speaking if I knew a user account, changed its password to one only I knew, could I not then start changing stuff? I would suppose that the account I changed would have to have privileges to make changes. Therefore, it must be impossible to guess or find any accounts that are able to make changes? There are some caveats: "This vulnerability cannot be used to change the password for the following types of users accounts:

• User accounts that are defined on external identity stores such as a Lightweight Directory Access Protocol (LDAP) server, a Microsoft Active Directory server, an RSA SecurID server, or an external RADIUS server
• System administrator accounts for the Cisco Secure ACS server itself that have been configured through the web-based interface
• Users accounts for the Cisco Secure ACS server itself that have been configured through the username username password password CLI command"

So which accounts does that leave that may be able to make changes?

The other advisory summary "Cisco Network Access Control (NAC) Guest Server system software contains a vulnerability in the RADIUS authentication software that may allow an unauthenticated user to access the protected network. " is here: http://www.cisco.com/warp/public/707/cisco-sa-20110330-nac.shtml

Comments?

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

"Thank you for ordering from Cellphone Inc" is what the email says ... what it doesn't say is "have a nice day cleaning your infected PC". Reader Scott had just taken his mobile phone to a store for repair, but being the savvy security specialist, he was still suspicious when he got the following email shortly thereafter

Thank you for ordering from Cell Phone Inc.

This message is to inform you that your order has been received
and is currently being processed.

Your order reference is Cell Phone Inc. You will need this in all correspondence.
This receipt is NOT proof of purchase. We will send a printed invoice by mail to your billing address.

You have chosen to pay by credit card. Your card will be charged for the amount
of 629.99 USD and "Cell Phone Inc." will appear next to the charge on your statement.
Your purchase information appears below in the file.

Cell Phone Inc.

Turns out of course that this email had nothing to do with Scott's phone, it is just the latest malware scam. The email comes with a PDF attachment that - at current count - tries to exploit collab.getIcon, media.newPlayer, collab.collectEmailInfo and util.printf -- all rather "old" Adobe Acrobat vulnerabilities, but apparently still "good enough" for the bad guys to warrant a new spam run.

The PDF's guts are obfuscated JavaScript, as usual, and currently showing up with a lousy 2/43 on the Virustotal radar. 

Keep your users from clicking ... and keep up with those pesky almost-feels-like-weekly Adobe updates!

Past August, we ran a story about the dangers of abandoned email and chat accounts. Since then, we've been getting a steady trickle of requests from readers for advice on how to get a provider to delete an unused profile or address completely.

Reading the fine print of legalese is never fun, and therefore it's no surprise that many users apparently read the privacy policy of a "free" web site for the first time when they want to cancel the account. More often than not, they then find out that ... there is simply no way to back out. Or rather, that the legalese gives the provider ample rights to delete an account at any time, without warning, but that there is no way for an user to request such an action.

Today's question on the topic came from reader Mike, who tries to have his old and unused ICQ.com account properly closed and deleted. Not so easy, it turns out: The "support forum" on ICQ is full of users who post "please close my account" requests, but don't seem to be getting an answer or action. If you know an approach that works for ICQ, please comment below, or let us know via our contact page.

 
Following up on the earlier post by fellow ISC handler Rob on the RSA Breach, here's a couple practical things you can look for in the audit log of your RSA ACE (SecurID) server. In line with Rob's scenarios, an attacker who is in possession of the "seed" values of your SecurID tokens still has to guess the userid and PIN to get a successful login. With ample foresight :), the authors of the ACE/RSA software seem to have expected such a scenario, and have implemented an audit log that fits to the case:

AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE will show up in the audit log whenever someone has a good token (or the seed values) and either fumbles or tries to guess the associated PIN. You'll get quite a few of these in normal use, simply because authorized users sometimes forget or mistype their PIN. If you see a lot of these against one single userid, chances are it will lock after "n" failed attempts and no harm is done. But if you see 1-2 of these per user and enumerating several of your users .. then you should take a closer look for sure.

AUTH_PRINCIPAL_RESOLUTION / AUTH_ALIASES_NOT_FOUND will appear in the log if the userid that tries to log in does not exist. Again, you can expect a couple of these per day in normal operation, it is just a fact of life that users can't type their own names ... But if you get a lot of these, and especially if the username format is completely different than the userids in use, someone might be trying to guess your users from a phonebook or LinkedIn accounts. Take a closer look!

Irrespective of the recent RSA breach though, there is one audit log entry that you should keep a close eye on:

NEW_STATIC_PCODE_AUTH_SUCCESS shows up in the log whenever someone logs in with a static passcode. This means that the user has lost his token, or never had one, and that someone with ACE Admin privileges has assigned a static password instead. Yes, this is possible, and it basically turns two factor authentication into two-password authentication, while still everyone can claim to the auditors that "login goes via the SecurID server". There are legitimate emergencies for this kind of login, but it certainly is a dangerous option to have - if someone can smooth-talk your Helpdesk, they can get in, without needing a token. 

Considering the latter, you probably shouldn't worry all that much about what was or wasn't stolen in the recent RSA heist. But if you're not doing so yet, you certainly should check your ACE server audit log.

(Credit to fellow ISC handler Richard Porter for the idea given to someone who e-mailed in looking for ways to detect rogue APs)

Most organizations have policies to disallow wireless access points not controlled by the organization which then requires trying to find such devices when they crop up.  There are commercial devices that can be deployed to do this and you could always have someone do a walkthrough with a laptop.  However, there are some network tricks you can use to provide another "dirty" detection method.

If rogue APs are plugged into your network, they will decrease the TTL value in all packets by one that traverse through the access point.  This can make it easy to detect the presence of those by using p0f/tcpdump/snort to look for packets that have TTL values that are lower than expected.  This also works for unauthorized routers, virtual images, bad network stack configurations, etc.  It won't detect APs that aren't plugged into your network and has some gaps (for instance, a savvy individual could modify the TTL they use before sending packets out), but again it is a "dirty" method of detection.  The advantage of looking for bad "TTLs" is that you will also have advance detection of network problems as well.

You can profile your network and find legitimate TTL values by running tcpdump -v and verifying the information with a network diagram (each router, NAT device, etc will lower TTL by 1).

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

In the past month or so, I have observed some strange Shockwave files that surprisingly, contain 2 other files attached inside the end of the file. First, an EICAR test file is found at the end of the Shockwave file portion which is immediately followed by a Window executable. Most IDS would trigger on that window binary transfer, including Snort. The shockwave file portion did not contain any malware.

The EICAR test file found X5O!P%@AP[4PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* is a typical ANTIVIRUS test file. [1]

However, after carving the Windows binary and submitting its MD5 for analysis to VirusTotal, it returned some surprising results. The MD5 of this file is 22a0c9e8f8c83f70caf04d757732eb21 and shows if this file manages to run, it could compromise to the client.

Have you seen anything like this? Let us know via our contact form.
 

[1] http://www.eicar.org/anti_virus_test_file.htm

-----------

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

The recent RSA Breach ( http://www.rsa.com/node.aspx?id=3872, http://isc.sans.edu/diary.html?storyid=10564 ) has got lots of people asking lots of questions, and as a security consultant, I seem to be getting lots of them directed my way. I thought it was time that someone said "How bad could it possibly be?" and outline just what the worst case might be, along with what the associated risks are (or are not, please read on).

First, let’s review how the RSA Authentication solution works. Your users have a keyfob (or a soft token on a phone or PC), with a token code that changes randomly. They also have a personal PIN code (4-8 alphanumeric digits), which only they know. These combine to make their password, which is normally used for secure access to a VPN, Web Server, Terminal Server or some other resource.

The more astute readers will have already seen the error in the paragraph above. The token code is *not* random (true randomness is a very tough nut to crack). The token code derived mathematically from a seed which is provided by RSA when the server is originally installed, the serial number of that particular token (printed on the back) and the system clock.

In short, RSA’s ACE server is a traditional multifactor authentication system. It combines something you have (the keyfob) with something you know (your PIN code) to authenticate you. Once authenticated, it is up to you to handle Authorization (ie – now that you are in, what do you have access to?).
 

So, back to the RSA event  - what is the worst case breach that might have occurred? Well, for all I know, the information that was stolen was RSA's Christmas Card list, they really aren't forthcoming yet on exactly what the extent of the breach might have been.

The absolute worst case I can think of (and I am NOT implying that this happened), would be if an attacker obtained a complete or partial customer list, complete with seeds and serial numbers. Again this is my own worst case - read on, even this is not as bad as you might think.

First of all, like all good cryptographic algorithms, RSA's token code algorithm is both math heavy and public. If you have the seed, plus the serial number of a token, an attacker can easily calculate the token code at any given time. CAIN for instance is a popular tool that has an interface for this.

This seems pretty bad, but don't forget the rest of it. When a user logs in, they need to supply their userid, their token code, and their pin code. There is no way that an attacker could have obtained the userids (specific to the organization) or pin codes (known only to the user) from RSA.

An attacker could easily obtain a list of users from several sources - your company website might have several senior staff listed, or even a corporate directory. Facebook, Myspace and especially LinkedIn are other likely sources for user names. Combining your first and last name in any of the common formats gets you a list of account names that will work for many environments. (note that some shops will have userids that are not related to your actual name)

This leaves the PIN code and the serial number. The assignment of serial numbers to usernames resides only on the customer’s ACE server - RSA does not have this information. The user’s PIN code is set by that user, and is 4-8 alphanumeric digits, though many organizations still only use 4 numeric digits. Unless people use trivial PINS, such as "1234", or the last 4 digits of their public phone number or extension for a PIN, the PIN is also probably "secret enough", since no-one knows it but the user.

All this being said, RSA's advice <sent in an email to RSA customers, and then re-posted here along with loads of other locations on the web  - http://www.sec.gov/Archives/edgar/data/790070/000119312511070159/dex992.htm > is spot on, and just plain common sense.   Some of the high points I've summarize here (in my own words and order), but RSA’s list of recommendations boil down to “defense in depth” against brute force login attempts (both in protecting against them, and minimizing the impact if successful).

• Implement account lockout on your RSA server - if someone gets their login wrong 3,4 or 5 times, either they are attempting a brute force login, or they are legit, but need a refresher course and shouldn't be logged in tonight. Oddly enough, this one is NOT in RSA’s list, but it’s certainly first on my list !!
• Review your logs regularly. Or even better, use common log monitoring tools like SWATCH, Kiwi Syslog (now owned by SolarWinds), or any other monitor to raise an alert when you see successive failed login attempts. SEIM tools do a bang-up job of this as well.  Have a procedure in place to take action when you see an alert.
• Enforce strong password and PIN policies
• Keep systems patched
• Get your helpdesk on board, both the helpdesk and your users should know what a social engineering attack might sound like and what they should do if they see one.
• Don’t let your workstation get owned. If your workstation is owned, a keystroke logger can snag your PIN, and all is lost. RSA's advice on this includes being careful on social media, don’t open suspicious emails, the usual suspects.
• Use access rights and other authorization methods to implement least privilege access. If you don’t need access to critical information, then you shouldn’t have it.
• Harden your servers

Long story short, no matter how bad RSA's breach might or might not have been, System Administrators have it in their power to implement truly effective mitigations.  In fact, after reviewing the list, all of us should be doing this stuff already – if not, there’s no time like the present to start !

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

First a Few Words About the Use of the Term "APT"

Advanced Persistent Threat (APT) has been getting a lot of press in the past year. There is plenty of debate over whether APT is a "who" or is a "how." However, there is little debate over APT's buzzword status. This is how I'm using the term today: as a buzzword to get you managers' attention and to get them to the table for this exercise. Like all security efforts, if you lack management support, you are likely to fail.

Why you Need an Exercise

An APT occurrence is a low-frequency high-impact incident. You are not likely to have policies, procedures and run-books prepared. There are not a lot of people who have first-hand experience dealing with it, and they will be hard to find when you actually need them. This is why you need a flexible response framework and run through scenarios like these to stay prepared.

Before the Exercise

You will want to prepare the appropriate communications to get your message out to management and the participants, this can be as simple as emails, but my require full reports or presentations depending on your organization. The message should minimally include a description of the threat, and how it may affect your firm. Or, "what is APT" and "why should we worry?"

Describing APT-like events

You can Google around and find some really great bloggers discussing APT. Management won't know these people so it might not be the only source that you want to include. I'd recommend media reports (especially the media that your management reads) about the following high-profile events:

• Google Aurora
• NASDAQ
• Night Dragon
• RSA

Why Should We Worry?

This is the classical "why should I care" question which you're used to dealing with. If you're not on the obvious-targets list already you may want to point out that every organization has its secrets, and other groups probably want those secrets, either for direct profit or to simply post them on the Internet to make you look bad. These groups may employ tactics similar those high-profile events, and that's the purpose of this exercise, to determine if you're prepared to handle such attention.

Preparing the Notification

You will start off the exercise with the "notification." Undoubtedly your organization will become aware of the event through a visit or phone-call from a government or law-enforcement agency. They will contact your upper management, not your security team or help-desk. This will not be a good day for any of you, so again, it's a good idea to involve upper management in this process so they know who to contact after they are made aware of the incident.

The scenario will be something like: "we have learned, by way of an informant, that your crown jewels have been stolen, we think the compromise occurred over six months ago and the attackers possibly used one or more of the following IP addresses," and they provide a list of 62 IP addresses.

Always include a list of things to look for and the list will contain many false-leads, and probably be difficult to leverage in your environment. It's not uncommon to receive a list of dozens of IP address, domain names, and MD5 Sums of suspected malware with little or no context, and if you're told a time-frame of the event the window is usually very wide due to the uncertainty that the investigators have in the early stages of an event.

The First Exercise

Before assigning tasks and spinning up the incident response process the first thing that the participants must determine is "who should be informed of the incident," and "who should be involved in the response." Are there people missing from the table that should be participating? Once you've captured your list of people that need to be immediately informed, work out how that notice will be delivered. Do you have after-hours contact information for everyone on that list?

This should be the first deliverable produced from this exercise.

If you have the luxury to hold a multi-day exercise this would be a good time to break. Invite those who were identified as missing from the table, and prepare the emergency contact process documentation. Participants should be taking time to think how they would investigate the limited information provided in the initial notification.

Creating the Time-line of the Attack

As the organizer you know what really happened in the scenario and drive the participants' discovery process. Take the sample time-line below and customize it for your environment. Some changes will be easy to make, others may take a bit of creative and devious thought (e.g. coming up with a plausible way the attackers can establish a command and control channel out of your firm.)

The time-line below is the product of a synthesis of many of the recent details that have been published, stories told to me at bars, and other unreliable and speculative sources. As they say on TV, any similarities to real events is purely coincidental. Efforts have been taken to make the time-line realistic so that there may be value gained from the exercise.

Throughout the time-line I will call out certain check-points for flags as the adversary achieved critical stages in the attack. These flags are presented to organize the discussion and break this large, complex event down into manageable chunks. These can also be used by any future pen-testing process to measure success, or be examined on their own by audit to measure the detection and control efforts in place to defend that flag.

First Phase

First they will collect information about you, your organization and your environment. This will be extremely hard to detect, and you will likely never know when that began or what information they gathered. You can be fairly certain that Google and your own marketing and PR efforts were involved.

There will be some sort of reconnaissance; network scans, or vulnerability scans of your web applications. It will be very difficult to identify what was related to the eventual attack and what was just another day on the Internet.

The first successful attack will likely involve a web application. A SQL injection or file-injection vulnerability will be exploited on one of your web-servers. This is the first flag, a SQL injection leaks out password hashes, or account details. These will be exfiltrated out among HTTP requests from the attack, and any hash values will undergo a cracking process. They have rainbow tables, and parallel-computing resources, so eventually a password will fall to these efforts and they will have a working account on the system. This is another flag: working username and password pair. However, if a remote file-inclusion vulnerability is found and exploited (flag) they now have the opportunity to drop files on the system and execute them via web requests. First it will be a simple file-uploader page that they drop using the file-injection. Then they will upload a web-based control panel on the system (flag), and using the same web access that you provide to the Internet, they can upload and execute any code using the privileges of the web server process ID.

They will drop more tools on the server, targeting the password hashes on the system itself (flag.) These will be pulled off of the system via HTTP and subjected to the same password attacks. One they have working accounts at the system level (flag) they will will use that to log into other systems via the web-based control panel (flag-- can you detect that your web-server is logging into other systems?)

Their target is your Active Domain server (or your firm's equivalent centralized access control system.) Once they have a working account on that server, they will attempt to elevate privileges enough to grab the password hashes. If you use the same admin password on your web servers as you use on your Active Domain server, then they can skip that step-- you made it a lot easier for them.

Second Phase

Armed with working accounts, and user-lists, and other public information about your firm/environment, they will craft targeted emails for key players in your organization. These messages will either contain malicious payloads, or provide links to sites that will compromise the reader and install a remote-access-tool on the system (flag.)

The command and control method used by these tools will be a mixture of novel and old school. Expect something clever like encoded DNS traffic to something as simple as a reverse telnet shell out to a compromised hosting provider. This is where you will need to be creative and customize this for something that would work in your environment. It's also an opportunity to shed some light on any glaring security holes that you're aware of and want upper management to help out with (e.g. A lack of egress filtering, or wide open proxy policy.)

The Heist

At this point, the attackers are in a position to research where your key documents are held and how to grab them. Once they have an internal system under their control, and it's just a matter of time before they either have the Administrator password or the ability to promote an account (flag-- are you alerting on when accounts are reclassified or when administrator is logging in directly to systems?) to administrative privileges. They will move from machine to machine looking for their ultimate target (flag.) Once found, it will go out via existing command and control channels (i.e. The remote access tool or HTTP control panel) or right out via email.

Example Flags for an Exercise

These are the flags I would use for the exercise listed above:

Phase One

• SQL injection discovered on web application
• SQL injection leveraged to expose web application authentication hashes
• Accessed to web application gained using cracked password
• Remote File Inclusion vulnerability discovered in authenticated area of web application
• RFI vulnerability leveraged to execute a control panel
• File uploader script installed on the system via control panel
• Password hash extraction tool uploaded to the web server
• Web-server password hashes extracted
• The web-server attempts to log into the Active Domain controller.

Phase Two

• Member of Upper management receives malicious PDF file
• Member of Sales department receives a malicious spreadsheet
• Member of IT department receives a link to a malicious video
• Remote-Access-Tool is installed on one or more of the spear-phishing targets
• Command-and-Control channel is established to an internal desktop or laptop
• Password extraction tools are installed on the compromised system.
• Password hashes are extracted
• The compromised system logs into the Active Domain controller.
• New accounts are added to the Domain and granted administrator privileges.

 The Heist

• The compromised system mounts the drive containing the crown jewels.
• Files are compressed and uploaded to website on the Internet

Detailing the Flags

For each flag you are going to give an approximate time that it occurs. Starting with the first flag, "SQL injection discovered on web application," note the approximate time elapsed. Some flags will follow in quick succession, others may wait for weeks or months as password hashes are attacked. Phase one and phase two may overlap. You may want to put more flags in to model how the group may explore your environment and try different techniques.

In addition to the timing of each flag. You will want to note how that flag may manifest itself in your organization's logs to justify how the step was discovered in your firm. Not every flag will leave easy log evidence. You might note a flag as being "currently undetectable" by your system, and it would be "discovered" in the exercise from something more intensive like forensic analysis or the discover of a fictitious outside consultant brought in to supplement your team.

Presentation of the Events

After you finish working up your customized time-line of the attack, list out all of the individual flags in chronological order. Come up with a plausible method that you may discover that event, this will guide you in writing the discovery stages of the exercise. For example, given the IP addresses provided by the notifying agency, you might find one of those IP addresses as one of the command and control endpoints and that would lead you to one of the internal infected systems.

It's common to work backwards from the discovery of the incident to the cause. So it makes sense to present the flags in reverse-chronological order-- although there may be a case where discovery of the first and second phases of the attack occur in parallel.

Once you have listed out the order that you present your events prepare some questions surrounding each flag. Initially you will discuss how you would instigate that event, but later you should focus on how you would generically detect an attacker reaching that flag. Another product of this exercise will be a list of recommendations so that you can detect future attackers while they're trying to get in and stop them before they get too far. Nobody wants to get that phone-call telling them that they've had a major compromise.

Wrapping Up?

At the end of this exercise you should have a working CERT contact sheet. Even if they're not initially aware of it, everyone that should be informed of an incident like this is now a member of your organization's Emergency Response Team.

For each flag, you should have listed out your plan to detect when an attacker achieves that stage in your environment. You should have identified existing controls, or point out a need for additional controls. You will likely have identified instances where individual alerts would not warned you of the big picture, but in concert, multiple alerts would have properly highlighted the heist. Followup with a discussion on how you can get your various groups cooperating and sharing log and alert data.

The results of this exercise should be written up, shared with upper management, audit, and your pen-testing team. After that, you'll find that you have a lot more work to do. Sorry. All I can say is that it's better than your CEO getting a phone-call from Special Agent Smith.

Finally Comodo spoke up to let us know more about the certificate issue we have been covering this morning with Firefox and Microsoft releasing "certificate black list" updates. [1]

Comodo states that none of the keys and signing/intermediate CAs were compromissed. Instead, systems at an affiliate were compromised to trick the affiliate into signing fraudulent certificates. The attacker obtained username and password to log into the partners systems, and was thus able to to issue the fraudulent certificates.

According to Comodo, the breach was discovered quickly and they are pretty sure that the attacker only issued the now blocklisted certificates.

[1] http://blogs.comodo.com/it-security/data-security/the-recent-ca-compromise/

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

Microsoft just released an advisory [1] alerting its customers that a total of 9 certificates where issued using the leaked/stolen CA certificated from Comodo.

The affected domains are according to Microsoft:

• login.live.com
• mail.google.com
• www.google.com
• login.yahoo.com (3 certificates)
• login.skype.com
• addons.mozilla.org (already known from an earlier announcement by Mozilla)
• "Global Trustee"

The advisory states that Comodo has revoked these certificates and listed them in its revocation list. Microsoft also is releasing an update that will blocklist these certificates.

Of course, this issue is "serious", not just considering the household brand names affected. Probably even worse then the possible man in the middle attacks that may have happened is the simple fact that this fundamentally breaks the trust model of SSL. SSL is using a "trust pyramid", A few certificate authorities are trusted to issue certificates to entities they trust. Of course this trust should be based on some kind of verification and the ability to secure the private key that goes with the root certificates and the signing certificates based on it. This event more and more looks like the trust pyramid was really more a stinking pile of doo . No surprise given the rush to the "no paper work required bargain basement certs". I recently started using free certs from startssl.com just for that reason: At least startssl doesn't charge me for not verifying who I am.

In short: Patch... and hope you will be ok until the next time this happens. It would be nice if Comodo would come forward with details. It was probably the APT Monster that ate it.

 [1] http://www.microsoft.com/technet/security/advisory/2524375.mspx

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

At the heals of yesterday's Firefox 4 release, we today got 3.6.16 and 3.5.18. As usual, Mozilla will provide security updates for some older browsers after the release of a new major version. If you are not planning to update to Firefox 4 soon, you should update to the newest 3.x version.

This wouldn't be worth a full diary (usually we just publish a "one liner") if it wouldn't be for one interesting change: Mozilla decided to add some new blocklisted SSL certificates.

SSL certificates are usually considered valid if signed by a trusted certificate authority. My version of Firefox 4 on a Mac includes certificates from about 80 trusted organizations. If a certificate authority finds out tht a certificate was signed by mistake, they may add the bad certificate to a revocation list. Each certificate includes a URL for a revocation list, and the browser may check if the certificate is listed as revoked.

However, browsers are not required to check revocation lists. In addition, if a certificate authority is compromised, it may lead to compromised revocation lists as well. The black list feature in Firefox (same feature exists in Chrome) lists a small number of certificates that the browser will not trust.

The recent addition is rumored to be due to a compromised certificate authority, which has been used to issue fraudulent certificates. [1] In particular it is suggested that a certificate for "addons.mozilla.org", the site used for Firefox plugins, was created using the compromised CA.

 [1] https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

Also see:

https://github.com/ioerror/crlwatch#readme
https://www.eff.org/observatory
http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates

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

Like no other release before it, Firefox 4 includes a number of significant security features. These features are addressing attacks that are in particularly hard to avoid by developers and in which the browser is more so the victim then the server.

These attacks, Cross Site Scripting (XSS), redirects to HTTP pages from HTTPS and Clickjacking use vulnerable web applications more as a mirror to bounce attacks into the browser. The browser can provide meaningful protection against these attacks, unlike for more server centric attacks like sql injection, for which the attacker is in full control of the client.

XSS and Content Security Policy (CSP)

We have seen a couple of prior attempts to assist browsers to detect XSS attacks. All of these attempts, (the NoScript plugin or the IE 8 "X-XSS-Protection:" header had the same problem: They had no idea what kind of script to expect on a particular page. In some cases, they could prevent reflected XSS just by comparing strings sent by the browser to strings being returned by the server. Neither NoSpring nor IE 8 did a sufficient job in preventing XSS and many users or web developers turned it off due to high false positive rates.

CSP takes a different approach: It uses server headers to tell the browser what kind of content to expect. That way, the browser can make a more intelligent decision as to how to block content that does not match the policy communicated by the server. I will probably discuss this feature in more detail in the future, but if you are interested, last months Monthly Threat Update webcast covered the main points. [1]

One CSP feature I would like to point out: The server may communicate as part of its policy a "Report-URI" which the browser can use to report any violations of the CSP. This is not only great to detect attacks, but even more so to detect legitimate features on your site that are not sufficiently covered by your policy.

If you would like to experiment: Just add "?csp=Y" to any isc.sans.edu URL. It will enable our test CSP. Right now, it is not very restrictive as I am still refining some of our content. We do also have a little CSP test page at http://isc.sans.edu/tools/csptest.html which highlights some of the features.

Strict-Transport-Security

Another neat feature to tell the browser more about how to connect to a given site. If the "Strict-Transport-Security" header is set, the browser will refuse any attempt to connect to the site via HTTP. The threat model here is that an attacker will inject a redirect to the HTTP version of the site while the user is browser a non HTTPS site (any site, not just the target). This could lead to the disclosure of confidential information like authentication cookies. Sure. This attack can be mitigated in part by setting the "secure" option of your session cookie. But it may not be so easy if the injection of the redirect happens during the login process.

This header has two parameters: A "max-age" indicating for how long this rule should be obeyed and a "includeSubdomain" parameter that will extend the rule to all subdomains. This header should be used on all HTTPS only sites.

Other changes

A few other changes:

- X-FRAME-OPTIONS Header: it can be used to prevent a site from being included in a frame. This option exists in other browsers as well (IE, Safari, Chrome). Some of the recent 3.6 versions of Firefox already included it and NoScript implemented it. CSP implements a more fine grained restriction on framing.

- User-Agent Header: Firefox 4 uses a less verbose user agent header which makes it a bit harder to track users

- Do-Not-Track Features: More about this later. It does signal sites if you don't want to be tracked.

[1] https://www.sans.org/webcasts/isc-threat-update-20110308-94078
[2] https://developer.mozilla.org/en/Firefox_4_for_developers#Security

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

The sad demise of readily available, cheap USB sticks with a switch to flip the device to be read only has caused some problems when dealing with suspicious machines, especial when I’m off duty and I hear the dreaded words “Oow, you’re in IT – could you have a look at my computer quickly?”

Back in the good old days, I could pick them up at nearly all my favourite shops and the vendors gave them away by the bucket load, but alas, they seem to have all but disappeared.

CD/DVD or Blu-ray disks are great, but lugging around a harden CD case really does clash with some of my outfits and doesn’t always send out the right message, particularly at: romantic diners, standing at a checkouts or trying to order drinks at a bar. This is where a small USB key, fitting neatly in to a pocket, helps me blend in with the rest of humanly almost seamlessly.  Almost. 

The standard read/write USB keys fall prey to being infected and compromised the very second they are insert in to a machine, which, as we know is a bad thing.

Stuck with this dilemma, I stumbled upon a neat solution – Secure Digital (SD) Memory Cards.
 
SD Memory cards have a small lock switch on them, making them read only; they can reach up to a whooping 32GB, are only slightly more expensive than similar size USB drives and are common place (I can find them in the petrol stations, corner stores and on aeroplanes). Now add in a small SD reader, around the size of a normal USB drive, and this is perfect for incident response on an untrusted system in a pinch or when a full response kit isn’t viable.

With the size of SD memory cards, it means I can have my favourite recovery [1], incident handling and fun at -someone else’s  - party [2] boot images each on their own SD card, hidden in a wallet, jacket lapel or hat band for ease of use. Producing them, seeming out of thin air, to fix a broken or infected machine amazes and astounds plus get brownie points at unexpected moments in life.

Another option for the uncluttered, nattily dressed Incident-Handler-around-town’s toolkit.

As always, if you have any better suggestions, insights or tips please feel free to comment.

[1] BartPE - http://www.nu2.nu/pebuilder/
[2] Backtrack - http://www.backtrack-linux.org/downloads/

Chris Mohan --- Internet Storm Center Handler on Duty

Adobe Flash Player update addresses a critical security issue (CVE-2011-0609):

http://www.adobe.com/support/security/bulletins/apsb11-05.html


RSA have released a further list of recommendations to their customers of security best practices via email. No further information on the actual breach.


And finally, the www.play.com, a large on-line retailer, has had a security breach. Some customer names and email addresses may have been compromised from a 3rd part company that handles part of their marketing. Emails notification have been sent out to existing customers.

Thank you to those readers for writing in with these updates.

Chris Mohan --- Internet Storm Center Handler on Duty

Apple has released some Security updates and various fixes today.  
Here's some handy links with a summarized list of software.

We're interested to know what's happening out there.  It has been observed through DShield data that Slammer traffic has had a sudden decline.  I played with the data for a while.  I could make it look like many things, such as slow and steady decline over time.  However, the most compelling story is the one where the data drops on March 9 and 10.

Below is the DShield data and graph on port 1434 for March 2011.  It's speculative at this point as to the cause of the sudden drop.  Japan's earthquake or Patch Tuesday have been kicked around.  I would be remiss if I did not mention Kevin Liston's series on Slammer Cleanup during October. We are loving the thought his great effort was a catalyst for the eradication of it.

So go back and take a look at your data for us and share what you're seeing.  Send us your thoughts on this.

  

# portascii.html
# Start Date: 2011-03-01 
# End Date: 2011-03-21
# Port: 1434
# created: Mon, 21 Mar 2011 10:15:34 +0000
# Date in GMT. YYYY-MM-DD format.

date    records targets sources tcpratio
2011-03-01      42862   37215   129     0
2011-03-02      62157   50028   158     0
2011-03-03      46789   37745   140     0
2011-03-04      37634   32068   109     0
2011-03-05      62649   50868   121     0
2011-03-06      62221   49475   149     0
2011-03-07      44110   39895   144     0
2011-03-08      60921   46609   140     0
2011-03-09      38503   32512   151     0
2011-03-10      23459   19438   106     0
2011-03-11      1411    1282    49      1
2011-03-12      1740    1702    30      0
2011-03-13      1414    1384    30      1
2011-03-14      1151    944     33      0
2011-03-15      1256    883     50      2
2011-03-16      1021    667     52      4
2011-03-17      1542    599     48      2
2011-03-18      978     515     37      8
2011-03-19      794     639     33      3
2011-03-20      766     635     34      3
2011-03-21      533     435     16      1
# (c) SANS Inst. / DShield. some rights reserved.
# Creative Commons ShareAlike License 2.5
# http://creativecommons.org/licenses/by-nc-sa/2.5/ 

--
Kevin Shortt
ISC Handler on Duty

Most of us have faced a time when a machine gets compromised with malware. In some cases it gets to the point where cleaning the infected computer is too time consuming or too difficult to clean, so the easy option is to wipe the machine and rebuild it.

Just before the forensic community (or some of my fellow handlers) lynch me for making this over generalised, evidence eliminating statement, allow me to elaborate.

“Nuke it from orbit”*

The format and rebuild statement normally comes from the following groups:

• Management
• Over worked IT staff
• The owner who’s just spent the last hour on search engines on how to fix their “slow” (utterly infected) PC
• The security team

The first three can be grouped as those that are not interested in analysing, understanding or knowing what happened on the particular machine. They just want their machine(s) back to normal ASAP as they can go about their business.

The security team, in contrast, have made this call as part of a calculated decision, after collecting the evident they need to get the business running safely again.

The decision to rebuild is considerably easier for those with a standard operating environment (SOE) or managed operating environment (MOE). This allows for a rapid deployment of a fully functional operation system with all the previous applications. This is a thing of beauty, bringing tears of joy to the most harden PC tech, as it’s a fast, reliable and easy completely re-deployment with a simple press of a few buttons. The assumption is - and I want to be very clear on this - that any user data is safely saved elsewhere, not on the PC about to be formatted and rebuilt.

The problem child

So what happens when you are confronted with a machine that needs to be wiped and re-built but no-one has a clue what’s on it and if it’s ever been backed up?

I like to call this the friend/family pc scenario or the forgotten machine, out back, that runs the company disaster-in-waiting issue.

Before even thinking about nuking this type of PC, there are normally two distinct areas to be worried about on these systems: data and applications

For the very wise or very paranoid amongst us, a full image of the troublesome system is the way to go. This provides a working image of the machine to refer back to quickly and avoids a great deal of painful conversations along the lines of “but you never mention that”.  Tools such as Sysinternals' Disk2vhd [1] makes a complete on line virtual image of the problem system. For those that run other virtualisation software it’s pretty easy to convert the Disk2vhd's .vhd file to other formats using your favourite virtualisation technology.

Close encounters

You have a backup, whether it is a virtual image, a standard backup or a copy of the PC's entire contents on an external drive; the next step is to know what you’re getting into.

An audit of all the known software on the machine, with first a verbal interrogation of the owner followed by a physical examination of the machine, provides a solid picture what needs to be on the clean system.  This is where recording your findings, conversation with the owner and processes to rebuild the machine can help in the future, should this happen again.

Dude, where’s my data?

Losing data doesn’t sound too bad until that data is someone’s child first steps or the company payroll. As a suggested list of files and folders to be sure you have:

• Browser favourites and configuration files
• Microsoft Office configuration
• Email folders (.pst files and the like)
• The entire My Documents folders
• Game files
• User profiles
• File and folders saved in weird location only know to the owner or application

To alleviate some of the pain of manually hunting for these files, Microsoft offers a number of tools to export data off and these are well worth reviewing:

• Office Save My Settings Wizard [2]
• File and Settings Transfer Wizard [3]
• User State Migration Tool [4]
• Windows Easy Transfer [5]

Game over man, game over

Applications are just as important for any system, so ensuring you can get copies of the installation media the license keys for software, including the original operating system is a must.

For lost license keys, software such as The Magical Jelly Bean Keyfinder [6] can get back most standard products keys.

For those applications which the original installation media no longer exists and the vendor can’t supply a replacement copy, this may be an opportunity to upgrade or migrate to a new application.

As a final note, be aware that there may be Wacky hardware installed and the drivers for ancient ISDN/video/sound/modem/and so on cards were last seen back in the 90’s. The very of best luck with that.

As always, if you have any better suggestions, insights or tips please feel free to comment.

[1] http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx
[2] http://support.microsoft.com/kb/312978
[3] http://support.microsoft.com/kb/293118
[4] http://technet.microsoft.com/en-us/library/dd560801(WS.10).aspx
[5] http://windows.microsoft.com/en-US/windows7/products/features/windows-easy-transfer
[6] http://www.magicaljellybean.com/keyfinder

*This frequently used phrase is taken from the movie Aliens and the actual quote from the character Ripley is: "I say we take off and nuke the entire site from orbit. It’s the only way to be sure."

Who knew James Cameron was really making a movie about the folly of poor incident response? Ripley is the lead incident handler dealing with this infection outbreak and she’s decided that Step 4 of the incident handling process [7], eradication, is the only real way forward. The business owner, Burke, disagrees; he later discovers he should have really taken Ripley expert advice to save him from, what is certainly, a very painful way to go.

[7] http://www.giac.org/resources/whitepaper/network/17.php

Chris Mohan --- Internet Storm Center Handler on Duty

RSA have announced that they have discovered a breach in to their systems.

This open letter from RSA's Executive Chairman, Art Coviello, http://www.rsa.com/node.aspx?id=3872 alludes to the attack extracting data on their RSA's SecurID two-factor authentication products.

Information on the attack and what other information may have been extracted by the attack is limited to this RSA open letter so far.

RSA have also sent out an email to a number of their customers with a similar warning and notification of the breach.

Chris Mohan --- Internet Storm Center Handler on Duty

What do you do when you receive an antivirus alert on your home system?

You're checking your mail in the morning before heading to work, you click on a link sent to you by a friend and your AV throws up an alert. What do you do next?

Is it time to start from scratch and rebuild the system?

In that particular scenario, probably not. The antivirus was likely successful in thwarting the attempt to compromise your system. You can most likely get away with booting up in safe mode (we're talking about windows here not your smartphone) updating signatures and running a full scan. A quick look at autoruns (http://technet.microsoft.com/en-us/sysinternals/bb963902) or hijackthis (http://free.antivirus.com/hijackthis/) output would also be a sound step-- in fact, you should do that before you have an alert, just to get a baseline.

Then look into how you were exposed and report that appropriately.

When is the Worst Time to Get an Alert?

Having an alert pop-up in the middle of your Internet activities is one thing. Yet it's worse to receive alerts right after the signatures have been updated. Now you don't have much information on how long you've been compromised, and the odds that the chain-of-compromise (http://isc.sans.edu/diary.html?storyid=9880) was complete is much larger.

This is when it's time to have a serious discussion with yourself about rebuilding your system.

What Does that Alert Tell You Anyway?

Not all AV alerts are created equally. There are alerts that are sensitive, alerts that are specific, and alerts that are precise. Sensitive alerts are good at finding malware, viruses don't easily get by it. The problem is that sensitive alerts will also flag non-malicious files in its zeal to detect viruses, leading to False Positive errors. Specific alerts, on the other hand, are very good about being certain that a detection is actually malicious. Its caution can create scenarios where it will miss viruses, aka False Negatives. A precise rule will tell you what virus you have, not simply that you have a virus. Just remember to not confuse precision with correctness. Your alert may tell you SillyFDC instead of a generic Trojan Horse, but it could still be a false positive or simply categorize anything that creates autorun.inf on all USB devices as SillyFDC instead of differentiating SillyFDC from a Stuxnet spreader.

As you can see it's a delicate balancing act to get the sensitivity, specificity and precision right in anti-virus solutions-- or any rule/signature based system for that matter. Are you aware of any anti-virus solutions that allows the client to tune these values?

How this Gets Tricky in the Workplace

It's one thing to make a clean-versus-rebuild decision based on your first-hand knowledge about how the system was exposed (i.e. Did I see the cause that led to the detection, or did this detect an old infection?) but yet another when you're sitting at the console receiving alerts from tens-of-thousands of systems in your organization. How do you make the clean-or-rebuild decision in that situation? How do you differentiate the broken compromise-chains from detections of successful-infections?

Like most difficult questions, the answer is: it depends. It's also a question best left answered by a security professional familiar with your environment, since they will have a better handle on your firm's needs and how to find the right balance point between the need to clean versus the need to rebuild.

What Alerts Could Include to Help the Situation

 The anti-virus alert itself could include a little bit more information to help address the precision problem and equip the full-time analyst with better information to answer the clean-versus-rebuild question.

Not having a centralized collection point for quarantined files sometimes causes me headaches at the day job. Having a simple way to recover the identified file is always a plus for large organizations that can afford and justify the costs of malware analysis and reverse-engineering. There are not a lot of organizations that are in that position, so I'm not surprised when this feature isn't available. Mostly I see quarantines used to recover gracefully from False Positive events.

You can eliminate the need to deploy a technician or a remote-agent to perform a live-response on a machine if the alert delivers a little more information than just the signature name, filename, and file location that most solutions provide. Ideally the report would include:

• Size of the file in bytes
• MD5 or other hash value of the file (even a fuzy hash like ssdeep, http://ssdeep.sourceforge.net/,  while we're asking for the moon)
• The Modified, Accessed and Created times from the file (http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx)

With the MD5 and the size of the file an analyst could leverage existing malware collections like virustotal (http://www.virustotal.com/search.html) or threat expert (http://www.threatexpert.com/) to gain more insight into the malware which would improve the precision of the results. The value could also be compared to known-good lists such as Bit9 (http://fileadvisor.bit9.com/Services/search.aspx)

Fuzzy hashes could be compared to other files in the day's alerts or recent events to determine similarity to other malware events.

Using the time of the alert and the MAC times of the file, an analyst would be better equipped to determine if the compromise-chain was broken or if this detection followed soon after a signature update.

Conclusion

 Antivirus alerts can be a very useful source of intelligence for your firm.  Don't ignore them because "AV took care of the problem."

There are plenty of tools to extract files that are transmitted via HTTP. For example Jim Clausing's brilliant perl script [1], or the Wireshark "export features among many others (chaosreader, xplico, network miner ...).

However, I am sometimes faced with a different problem: You do have a network capture of a set of HTTP requests, and you are trying to "replay" them in all of their beauty, which includes all headers and POST data if present.

There are two parts to this challenge:

- extracting the HTTP requests from the packet capture.
- sending the packet capture to a web server

"tcpreplay" may appear like the right tool, but it will just blindly replay the traffic, and the web server will not actually establish a connection.

"wireshark" can be used to extract the data using the tcp stream reassembly feature, but this can't easily be scripted. "tshark" does not have a simple feature to just extract the http requests. You can only extract individual headers easily or the URLs.

The probably easiest way to parse the packet capture, and extract the request, is the perl module "Sniffer::HTTP". This module will not only reassemble the TCP streams, it will also extract HTTP requests:

#!/usr/bin/perl                                                                                                               

use Sniffer::HTTP;
my $VERBOSE=0;
my $sniffer = Sniffer::HTTP->new(
  callbacks => {
      request  => sub { my ($req,$conn) = @_; print $req->as_string,"n" if $req },
  }
);

$sniffer->run_file("/tmp/tcp80");

Will read packets from the file "/tmp/tcp80", and print the HTTP requests. The output could now be used to pipe it to netcat (or directly send it from perl).

[1] http://handlers.sans.org/jclausing/extract-http.pl

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

Performance and security enhancements of Internet Explorer 9 make the browser upgrade worth one's consideration. If you need to rollback to the installation of IE 9 for whatever reason, you shouldn't have any issues. I tested the IE 9 uninstall process to revert a Windows 7 system to when it had Internet Explorer 8 installed.

You can uninstall Internet Explorer 9 by using the "Uninstall a program" applet in Control Panel. Then, select "View installed updates".

Then, select "Windows Internet Explorer 9" from the list and click "Uninstall." After the removal process, Windows will probably prompt you to reboot.

After the reboot, you should have Internet Explorer 8 back in its full glory.

-- Lenny Zeltser

Lenny Zeltser leads a security consulting team and teaches how to analyze and combat malware. He is active on Twitter and writes a daily security blog.

Microsoft released version 9 of its Internet Explorer web browser. You can download IE 9 from windows.microsoft.com.

Microsoft also set up a domain dedicated to the new browser: www.beautyoftheweb.com. Unfortunately, that site isn't hosted under the microsoft.com domain, nor does it have an SSL certificate to confirm that it belongs to Microsoft. Using this site to distribute the browser goes against the advice of downloading software only from known vendor websites. Copycat malicious sites claiming to distribute IE 9 will probably appear shortly, if they aren't around yet.

Internet Explorer 9 includes a number of security improvements that make the upgrade worth your consideration. These include application reputation capabilities that are part of the SmartScreen feature that helps protect the user against socially-engineered malware. The browser also supports the notion of Pinned Sites, which implements "secure launch" capabilities to safeguard users' sessions with important websites. Internet Explorer 9 also improves its resistance to exploits by embracing support for DEP/NX, ASLR and SafeSEH memory protection capabilities. The new browser also improves the messages its users see when they download files and programs; the messages are designed to make it easier for the users to assess the risk of opening such files.

Have you had a chance to experiment with Internet Explorer 9? Let us know what you think of its security capabilities.

-- Lenny Zeltser

Lenny Zeltser leads a security consulting team and teaches how to analyze and combat malware. He is active on Twitter and writes a daily security blog.

Windows Vista, 7 and Server 2008 includes a feature called integrity levels, which is arguably the most under-appreciated security mechanism built into the operating system. Yet, it provides powerful ways for mitigating the risks of computer attacks and malware infections. For instance, integrity levels can shield processes from keyloggers; they can also protect files from being accessed by malware running on an infected system.

Another potent benefit of integrity levels is the ability to limit the capabilities of an exploit that manages to compromise an application. This is what I'd like to discuss in the note below.

What Are Windows Integrity Levels?

Microsoft designed Windows integrity levels as a mechanism for enforcing mandatory access controls, which apply even when access would be granted according to the traditional discretionary controls that we're accustomed to. According to Microsoft:

"The integrity level is a representation of the trustworthiness of running application processes and objects, such as files created by the application. The integrity mechanism provides the ability for resource managers, such as the file system, to use pre-defined policies that block processes of lower integrity, or lower trustworthiness, from reading or modifying objects of higher integrity. The integrity mechanism allows the Windows security model to enforce new access control restrictions that cannot be defined by granting user or group permissions in access control lists (ACLs)."

This means that integrity levels can restrict one process from interacting with another process even if both processes are running under the same user account and even if the user has administrative privileges. 

Protecting Higher Integrity Objects from Malware

A process running under the Low integrity level will be prevented by the OS from modifying the process running under the Medium integrity process or from modifying a file assigned the Medium integrity level. (By default, Windows assigns the Medium label to objects.)

This is why it's advantageous to run the processes that are likely to be targeted by exploits under the Low integrity level. For instance, if a browser running under the Low integrity level gets exploited, the attacker's payload will have a hard time injecting itself into the majority of other processes or modifying critical files.

Didier Stevens illustrated the effectiveness of integrity levels for mitigating DLL injection risks by showing how the OS blocked the injection attempt from a Low integrity level process to a Medium one. He concluded that integrity levels may be a "good security feature to sandbox vulnerable, Internet facing applications."

Applications Designed to Run Under the Low Integrity Level

Though it may be possible to force an application to run under the Low integrity level if it wasn't designed for it, this will likely cause issues, such as the application not being able to load its configuration settings. Fortunately, some end-user applications are designed with Low integrity level in mind when they run on Windows Vista, 7 or Server 2008:

Internet Explorer's parent process runs under the Medium integrity level, while the process that represents each tab runs under the Low integrity level, thanks to the browser's Protected Mode feature:

Similarly, Google Chrome runs its tabs under the Low integrity level on Windows as part of its sandboxing capabilities:

Acrobat Reader 9 and lower runs under the Medium integrity level, like most processes in Windows:

Fortunately, most of the code of Acrobat Reader X runs under the Low integrity level. This is one of the security features built into this version of Acrobat to limit the capabilities of exploits delivered to the application's users through malicious PDF files:

Running a process under the Low integrity level helps minimize the damage it can do when exploited by malicious code. Hopefully, more programs will be build to take advantage of this feature of Microsoft Windows (ahem.. Firefox?).

-- Lenny Zeltser

Lenny Zeltser leads a security consulting team and teaches how to analyze and combat malware. He is active on Twitter and writes a daily security blog.

Adobe posted a security advisory (http://www.adobe.com/support/security/advisories/apsa11-01.html) about a new 0-day vulnerability in Flash player. According to the post about this vulnerability (available at http://blogs.adobe.com/asset/2011/03/background-on-apsa11-01-patch-schedule.html), Adobe says that they had reports of this new vulnerability being used in targeted attacks. These attacks seem to be particularly sneaky – the Flash exploit is embedded in an Excel file which is also used to setup memory so the exploit has a higher chance of succeeding.

We will keep an eye on this and if the 0-day starts being used in the wild. If you have more information that you can share about this let us know.

--
Bojan
INFIGO IS

Just for grins, I opened my spam folder on a gmail account I have and thought I'd take a look at what was in there since I hadn't looked lately.  By the way, my spam folder is one of my first sources of new malware for those who ask quite regularly where they can find malware to analyze.  In the last 30 days, I have approximately 707 spam emails, which averages to about 24 pieces of spam a day.  I can find topics such as:

"Please i need your assistance"

and

"YOUR EMAIL HAS WON $500,000.00 USD"

to the more malware malicious ones (complete with attachments) such as:

"Kindly open the attachment"

or

"You have 1 unread Message!"

  and those that ask me for my data like:

"Fill & Return For Claims"

or

"Fraud Alert!!!"

This doesn't even include the ones where I can buy drugs, save my visa card from being canceled, update my password before it expires, open a greeting card from someone I don't know, etc. I even found one in there from a friend's email address so they are either compromised or their email address is being used (yes, I'll tell them and ask them to check their system). 

One would think from looking at the scam names used above; the misspellings and bad grammar in most of the emails ; the amount of publicity on the topic of spam/phishing attempts, etc. that they would not work.  However, the sad reality is that spam/phishing is so rampant because it does work.  We are seeing again first hand the efforts to capitalize on the Tsunami disaster that Bojan wrote about in the diary entry isc.sans.edu/diary/Tsunami+in+Japan+and+self+modifying+RogueAV+code/10543.  Antivirus vendors are reporting that on average that spam makes up over 80% of email traffic.  That is a significant amount of email that is spam (no wonder my spam folder is so full) and just by shear numbers, it is going to work.  Many organizations at work have email gateways to filter out the miscreants, but at the same time, many do not block web based email accounts which defeats the whole purpose of having an email gateway. 

According to what I have been able to research (I didn't even have a computer then to know anything about it), the first spam email was sent on May 1st, 1978.  It was sent by a DEC marketing representative to every ARPANET address.  Spam in one form or another has been increasing every since then and really picking up steam in the 90s.  One would think that with the passage of that much time, that we would have been able to educate people how not to fall prey to such events. 

I still think education of the user is key and sadly SPAM/Phishing attempts have become part of the "normal" noise on the internet.  As sad as this is there is one bright note, at least with my daily dose of spam, I'll be able to have all the fresh malware I can analyze.

A lot of people are still surprised how quickly bad guys catch up with events in the real world - this is especially true for the RogueAV/FakeAV groups which constantly poison search engines in order to lure people into installing their malware.

We can also see even many AV vendors warning people to be careful when they search for this or that (currently, obviously the search query that generates most attention is related to the disaster in Japan). While it is good to constantly raise awareness and warn people about what’s happening, one important thing to know is that the RogueAV/FakeAV guys poison search engines and modify their scripts automatically. This means that they are constantly on top of current trends and events in the world – whatever happens, their scripts will make sure that they “contain” the latest data/information about it.

Back last year I wrote two diaries explaining how a certain RogueAV/FakeAV group works; if you haven’t seen them before I’d strongly recommend that you take a look, they are available at:

http://isc.sans.edu/diary.html?storyid=9085
http://isc.sans.edu/diary.html?storyid=9103

There are many RogueAV/FakeAV groups so the analysis posted above just concerns one of them (it’s interesting to see that they are still very much active).

With the disaster in Japan striking on Friday we saw another RogueAV/FakeAV group heavily poisoning the search engines – even Google which normally removes them quickly still contains hundreds of thousands of such pages. Since this campaign can be easily identified, here is what the current count says:

Yes, 1.7 million pages (!!!). Keep in mind that there are multiple pages listed here with different search terms (they modify search terms through a single parameter), but the number is still staggering. According to Google, in past 24 hours there have been 14,200 such pages added so it’s clear that the bad guys are very active.

This RogueAV/FakeAV group uses different code than the one I previously analyzed. They actually drop pretty interesting, self modifying PHP code.
The code contains a list of current searches/trends. The list contains hundreds of such keywords, some of which are shown below:

$lastquery = "<keys>cee-lo-green-grammyswhat-chilli-wants-finale … japan-tsunami-newsokinawa-japan-tsunami-2011tsunami-and-earthquake-in-japan</keys>";

Notice how the list is delimited by <keys> tags. This allows the owner of the script to automatically update the keywords the script will react to – by using a special parameter to identify himself, the owner can submit a new keyword and the script will modify itself by adding this parameter if it hasn’t been found in the $lastquest list before:

Same function is used if Google’s or another search engine’s bot visit’s the web page – the main script check’s the user agent that was submitted and even has a list of networks that can help the script owner identify “visitors” he or she does not want to get redirected to the final site hosting RogueAV.

But this is not all. When visited by a search engine’s bot, the script (among the other things) tries to create a very legitimate looking web page that should help poison the search engine. In order to create this legitimate looking web page, the script automatically queries Google to see related searches for the current search query (the hottrends web page at Google). Besides Google it will also use Yahoo to search for new pages and, what’s probably the most interesting, will retrieve images from Google images that are related to the same query term!

This way the RogueAV/FakeAV guys can create very realistic pages that can, unfortunately as we’ve all witnessed, successfully poison search engines.

(to be continued)

--
Bojan
INFIGO IS

There will probably be some emails scams and malware circulating regarding the recent Japanese earthquake that occurred overnight. If you receive such emails, could you provide samples using our contact form?

Be aware off

Fraudulent Organizations: If possible, donate to organizations you know and trust, not to new organizations just set up for this particular event. The IRS maintains a list of tax exempt charitable organizations [1]. This list is not 100% up to date, and it takes a while for a new organization to be added. But it can serve as a first sanity check.

Malware: Malware may be advertised as a video report of the event or come under other pretenses.

-----------

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

I have just released an updated CD of a hardened OS that includes Snort IDS sensor (version 2.9.0.4) with all the Sguil components ready to use. It is available in two versions, 32-bit and 64-bit. The CD has 3 options: sensor only, database only or all components on the same system.

The CD includes some new tools and updated scripts. The install.pdf document on how to install and configure the system is located in the rel_note directory.

Checksum for 32-bit available here and 64-bit available here.

-----------

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

Apple released a new version of iOS for iPhone, iPad and iPod Touch devices. Besides some new features that are being introduced with this release of iOS, Apple also patched a number of security vulnerabilities.

You can see the whole list at http://support.apple.com/kb/HT4564 - some of these are really low risk but if you scroll down to Webkit fixes, you can see that Apple patched 49 (!!!) security vulnerabilities that, according to Apple “may lead to an unexpected application termination or arbitrary code execution” (in other words: having your device pwned).

While we are not aware of exploits of these vulnerabilities being abused, it’s always better to be safe and update your i* devices as early as you can.

--
Bojan
INFIGO IS

Included in this Patch Tuesday is a Forefront update KB2508823[1] (Client Version: 1.5.1996.0).

We have received a number of reports that the KB2508823 update fails during the install. Once the update fails, the existing Forefront client is also removed. This leaves the machine without any anti-malware protection.

We recommend you hold off deploying the update until confirmation from Microsoft.

Microsoft have posted a similar warning here:
http://blogs.technet.com/b/clientsecurity/archive/2011/03/08/fcs-v1-march-2011-update.aspx

[1] http://support.microsoft.com/kb/2508823

Chris Mohan

The Pwn2Own contest by HP Tipping Point held at CanSecWest each year has a new sponsor this year. Google.

Google has offered up a bounty for breaking into Google Chrome.  As a seemingly direct defensive measure to prevent a big pay out, Google has published updates the day before the competition kicks off that fix numerous problems.

Yesterday, Google published 23 updates for the Chrome browser.  15 of them were rated high by Google.  So get those browers patched!

       http://googlechromereleases.blogspot.com/2011/03/chrome-stable-release.html

The nice part is Credit and Cash go to the individuals that report and assist with patch development.

--
Kevin Shortt
ISC Handler on Duty

Some readers from Montreal, Canada wrote in about a problem with AVG Anti-Virus 2011 Free Edition 10.0.1024.  The issue is with the all PDF's being quarantined and marked as infected by Luhe.Exploit.PDF.B.

Apple has also released a couple of updates today.  Apparently, they are catching up on some Java updates that Oracle released earlier.  The updates are for Mac OS X 10.5 update 9 and 10.6 update 4

References

http://support.apple.com/kb/HT4562

http://support.apple.com/kb/HT4563

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

Here are the March 2011 Black Tuesday patches.  Enjoy!
 

Overview of the March 2011 Microsoft Patches and their status.
 

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

SANS SEC401 coming to central OH beginning 17 May, see http://www.sans.org/mentor/details.php?nid=24678

We had a user over the weekend send us some interesting traffic primarily destineto port 80.  The TCP option used is in an option kind that appears to be in unassigned range, the sequence numbers are not changing, but the source IPs are.  They also throw in a packet here and there to destination ports other than 80 such as ports 21, 22 and 1.   If anyone is seeing something similar and has logs or preferrably packets, please send them to us.  

The Codegate CTF last weekend was finally an event that I was able to spend some time playing with – it was unfortunately only couple of hours but it was fun nevertheless!

As I haven’t seen any writeups about the crypto 400 – here go hell come (bonus question – guess the E! channel's host name who likes exploiting this :).
So, we are presented with a log file (mirror available at http://repo.shell-storm.org/CTF/CodeGate-2011/Crypto/400/2404656D5DA22F5DBA41CDD7AA1C1F7B) that has 2468 HTTP requests coming from a single host. An excerpt is shown below:

We can see a valid request (HTTP status code 200) and then a series of 500 requests, as well as a single 403 request. If you were paying attention last year you almost certainly heard about oracle padding attacks that were demonstrated at BlackHat Europe – these attacks allow an attacker to decrypt certain data (and encrypt, depending on some other circumstances) when CBC encryption is used. An excellent description of how these attacks work is available at http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/.

Knowing how oracle padding attacks work, we can analyze the logs of our (Codegate) server. The URLs shown in the picture are base64 URLSafe encoded – after decoding we are left with 32 bytes. Since the attacker started changing the 16-th byte, this means that the block size here is 16 bytes too.

The 500 server errors were clearly caused by an incorrect padding sequence. However, we can see one 403 error (forbidden) – it means that the attacker guessed a correct padding sequence. The attacker simply cycles from byte 0x00 to 0xFF, until the response is something different than 500. When the first value has been guessed, the attacker has to XOR it with 0x01 to get the intermediate value (read more at the link shown above). Now the attacker needs to find the second byte of the intermediate value, so the padding needs to be 0x02 – the value that has been already found is first XORed with 0x02 and the second byte is again cycled from 0x00 to 0xFF until a valid sequence has been found. And the process repeats for 0x03 … to 0x10.

This can all be seen in the log file as there are 16 requests that resulted in HTTP status code 403 (among thousands of other requests).
The challenge here was to guess what the attacker retrieved with the first (200) request. In order to decypher this we need to find all the intermediate values by following the process described above. Then we need to XOR the intermediate values with the initialization vector (IV) of the 200 request – the IV are first 16 bytes of the request.

In order to solve this I wrote a simple perl program that does this:

Now we just need to feed the 16 403 requests as STDIN and the program will solve the challenge for us:

This was a fun challenge (my team ended up as #24, but we were too casual ;-).

Anyway, in case you haven’t checked your servers/web applications for oracle padding please do so (there are lots of resources describing how to protect from such attacks). The attacks are real, they work and there are dozens of tools out exploiting this vulnerability.

--
Bojan
INFIGO IS

We had some readers (kuddos for watching your traffic closely!) report outbound traffic from HP Virtual Connect Blades to 49.48.46.53 on port 22.

No response is received from this IP address, and we guess it is a bug. Interestingly (I think Daniel noted it first), 49, 48, 46, 53 happens to be the ASCII code for 1, 0, . , 5 . So we suspect some buggy code trying to use an IP address starting with "10.5" (in this case, the blade's IP address started with "10.5").

To confirm this guess: If you have an HP Virtual Connect Blade, do you see similar traffic? Is it directed at a different IP address? Does the ASCII rule still apply for you?

This workaround helped some users affected by this problem:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02720395&lang=en&cc=us&taskId=101&prodSeriesId=3794423&prodTypeId=3709945

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

Seriously, its a good trend and should be encouraged.
Here are two efforts that recently came to my attention.

DOD is launching a program that will send members of their IT teams to industry to improve the government's IT expertise particularly in cyber security.
http://www.washingtonpost.com/wp-dyn/content/article/2010/12/30/AR2010123003292_pf.html

Estonia is building a Cyber Defense League with private sector cyber defense experts and government agencies.
http://www.npr.org/2011/01/04/132634099/in-estonia-volunteer-cyber-army-defends-nation?sc=tw&cc=share

I have been involved in several similar efforts in the past and while not all produced the desired results IMO such sharing benefits the parties involved. Private industry has people that, as part of their day to day job, watch for cyber security threats and trends. Government agencies have personal with the similar responsibilities and similar abilities.

Both have different views into various portions of "cyber land" and may see different things at different times but eventually will probably see whatever the other is seeing. Sharing that type of information just makes sense. The "bad guys" share. If the good guys don't we will always be one step behind them.

Other Government and private industry cyber security sharing forums in no particular order include but are NOT limited to:

nsp-security, ops-trust, infragard, NCFTA, ICASI, ISACS,  and many others.

http://www.ncfta.net/about-ncfta

"Since 1997, the NCFTA, a non-profit corporation, evolved from one of the nation’s first High Tech Task Forces and has established an expansive alliance between subject matter experts (SMEs) in the public and private sectors (more than 500 worldwide) with the goal of addressing complex and often internationally-spawned cyber crimes. These SMEs, from industry, academia and government, each bring specific talents and experiences to the partnership. Through a steady cycling of such cross-sector national and international resources, both embedded at the NCFTA and through initiative-specific intelligence channels, the NCFTA is well positioned to adapt and regularly reinvent itself to better address today’s evolving threat landscape."

http://puck.nether.net/mailman/listinfo/nsp-security

"The nsp-security [NSP-SEC] forum is a volunteer incident response mailing list, which coordinates the interaction between ISPs and NSPs in near real-time and tracks exploits and compromised systems as well as mitigates the effects of those exploits on ISP networks. The list has helped mitigate attacks and will continue to do so."

https://ops-trust.net/

"OPSEC-Trust (or "ops-trust") is a highly vetted community of security professionals focusing on the operational robustness, integrity, and security of the Internet. The community promotes mindful action against malicious behavior vs observation/analysis/research. OPSEC Trust carefully expands membership pulling from talent in many other security forums looking for strong vetting with in three areas ; sphere of trust, sphere of action, and the ability to maintain a "need to know" confidentiality. OPSEC-Trust (or "ops-trust") members are in a position to directly affect Internet security operations in some meaningful way. The community's members span the breath of the industry including service providers, equipment vendors, financial institutions, mail admins, DNS admins, and DNS registrars, content hosting providers, law enforcement organizations/agencies, CSIRT Teams, and third party organizations that provide security-related services for public benefit (e.g. monitoring or filtering service providers). The breadth of membership, along with a an action/trust vetting approach provides creates a community which would be in a position to apply focused attention on the malfeasant behaviors which threaten the Internet."

http://www.infragard.net/

InfraGard is an information sharing and analysis effort serving the interests and combining the knowledge base of a wide range of members. At its most basic level, InfraGard is a partnership between the Federal Bureau of Investigation and the private sector. InfraGard is an association of businesses, academic institutions, state and local law enforcement agencies, and other participants dedicated to sharing information and intelligence to prevent hostile acts against the United States.

http://www.icasi.org/

The Industry Consortium for Advancement of Security on the Internet (ICASI) is a forum of trust through which IT industry leaders address multi-product security challenges to better protect the IT infrastructures that support the world’s enterprises, governments, and citizens.

A few articles about Government and private sector sharing wrt cybersecurity intel:

http://www.enisa.europa.eu/act/sr/reports/econ-sec
http://www.nationaljournal.com/njmagazine/id_20090502_5834.php

http://gcn.com/Articles/2006/08/16/Sharing-data-is-crucial-to-cyberdefense.aspx?Page=2

http://www.dailyherald.com/article/20101227/news/101229642/

http://www.ncs.gov/nstac/reports/2009/NSTAC%20CCTF%20Report.pdf

If you know of any other good sharing being done feel free to add comments to this diary to educate everyone.

We talked recently about rogue apps inside the Android Marketplace. About this malware, there is an excellent analysis posted by Jon Larimer. More information at http://blogs.iss.net/archive/Examining%20the%20recent.html 

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

In the last few weeks, maybe even months we've been seeing an increase in the number of Distributed Denial of Service (DDOS) attacks on different sites. Today, according to Ahnlabs in Korea, a number of government sites are under attack. Yesterday it was word press, and recently we also had sourceforge and no doubt a number of others that I've forgotten to mention. 

So is DDOS the new black?   We know that the majority of the malicious files and traffic we see are somehow related to making money, but realistically I can't quite see how this is doing the trick. How is money being made? Are the current attacks going to serve as examples? Give some money or else?  I don't know how effective that would be as most of the organisations seem to be dealing with the DDOS attacks relatively well.  

So why are we seeing these increases?  Are they being reported more?  Are they easier to do?  Are they test runs for something better later on, or maybe even nation states testing their processes.  Let us know if you've been under attack, recently.  I'd be interested to know how you dealt with it and if you have some packets you can share, even better.  If you know why you were targeted I'd be interested to know.  

Now for dealing with a DDOS attack. 

The best will be to stop the packets from reaching you in the first place.  To stop them as far away from your environment as possible, especially if link saturation is the problem.  This will likely need the cooperation of your ISP. You will find some are more willing to help you deal with an attack than others.  

If you manage to identify a particular characteristic of the packets being sent, then you might be able to get a firewall, router, IDS, or IPS to deal with the traffic.  These types of devices will be better at coping with this than your web or mail server.  Check you firewalls, many have the capability to drop traffic based on certain thresholds or characteristics and they may be enough to 

But lets put this in the context of an incident handling process. Hopefully you remember the six steps:

• Preparation
• Identification
• Containment
• Eradication
• Recovery 
• Lessons Learned

Preparation

This will be the most important step.  Firstly you will need to decide what you are going to do in the event of a DDOS attack on your infrastructure.  Will you pull the plug yourself and just ride it out? or will you take steps ab and c to deal with the attack. Best to sort this out before it happens rather than whilst it is happening. 

Make sure  you understand what your ISP will and won't do for you in the event of a DDOS attack on your sites.  

If you have an approach to deal with the DDOS, make sure it is documented.  Nothing worse than having to figure things out whilst the attack is underway. 

Have the capability to grab packets in place.  They will be invaluable.

Identification

How do you identify an attack?  Often it is because someone receives a phone call saying "xyz is very slow/unavailable".  You may have an IDS/IPS/Firewall throwing up alert. So that is how you notice. 

What to do next.  Well hopefully you have managed to capture some packets, or at a minimum log records. You will need to look at these and see if you can identify a common factor. 

Containment

Using the information discovered, you may be able to configure an upstream device to drop the malicious packets. Your ISP or a vendor may be able to help mitigate the attack and contain the damage done. 

You will likely also need to examine the targets to ensure they have not been compromised. l 

Eradication

If the targets have been compromised you will need to deal with those.  Your incident handling plan, developed in the preparation stage, should have enough information to allow you to deal with this new issue.

Often when the attack is not successful it will drop off, so I guess it is self eradicating. 

Recovery 

Once the attack is over, determine what else may need to cleaned, replaced, hardened.

Lessons Learned

Standard practice after any incident is the lessons learned.  Go through the attack, see where you went wrong and where you went right. Develop an approach to deal with 

I've made a start, if you can add to it let us know via the contact form or comments. 

Cheers 

Mark H.

Android Marketplace is a place where users that own devices using the Android operating system can download a large variety of apps for the device. There has been reports of applications that have gone into Android Marketplace DroidDream infected with malware, which was rooting phones and stealing the IMSI and IMEA codes.

One of the favorite targets of attackers are mobile devices. They can use them as bridges to gain access to corporate data network. To minimize risks, it is important to establish a security baseline and place antimalware protection inside them. We have the example of Trendmicro Mobile Security for Android, Mcafee Mobile Security and Symantec Mobile Internet Security.

More information at http://antivirus.about.com/b/2011/03/02/as-many-as-56-android-apps-contain-backdoor.htm and http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

Although I have been fortunate to work with a company that handles large amounts of money and time to implement the security solutions typically get the latest technology solution, we also have companies that do not handle the same amount of money due to profit margin business in which they are located and therefore there is a greater rationale for the investment of monetary resources in those projects that are vital to the operation of the company. 

A risk that materializes more frequently in companies is the leaking of information and one of the most common ways to steal over the Internet is through various forms such as emails and file transfers. That means we need to have a sensor that is responsible for monitoring the Internet traffic inbound and outbound. To determine your position, we will outline a two firewall DMZ and place a snort sensor in the middle using linux and configured in bridge mode.

Bridge configuration is pretty simple. Consider eth0 as the interface connected to vlan11 and eth1 the interface connected to vlan10:

ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr sensor
brctl addif sensor eth0
brctl addif sensor eth1
ifconfig sensor up 

Now it is time to configure the sensor. Many companies manage document templates, which contain default information that can be used to catalog the information contained therein. You can use words like secret, confidential, restricted, and many others. Based on this template, we proceed to create the appropriate alert to block the transit of information to the outside. For the following example, we will assume as the internal ip address range 192.168.1.0/24 and also that the template for confidential documents relating to the company X provides the following sentence: "Company X - Confidential":

alert ip 192.168.1.0/24 any -> any any (msg:”Data Loss from inside the network”; content:"Company X - Confidential"; rev:1)

Another interesting measure, depending on the environment and the risks of the company, is to disable the USB storage devices. To do this task in Windows environments, disable all permissions to the following files used each time you install a USB drive:

%SystemRoot%\Inf\Usbstor.pnf
%SystemRoot%\Inf\Usbstor.inf

If the USB storage device is already installed, change the following registry key value to 4: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UsbStor 

Do you have any other ideas? Use our contact form to share it with us.

-- Manuel Humberto Santander Peláez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org

Apple's Product Security have sent notification that a new version of iTunes is out and the security fixes in this update.

They list the security fixes here:

http://lists.apple.com/archives/security-announce/2011/Mar/msg00000.html

We'd recommend you update as soon as possible.

Today is a great day to check if all those other applications on your machine need an update.

Chris Mohan --- Internet Storm Center Handler on Duty

There are times as a security professional you have to roll up the sleeves and get your hands dirty to make sure some of the basics are applied to the environment we’re looking after. As a common example, most of us have had to patch the odd Windows machine, or three, to help out a friend to make sure they’re safe and up to date from the various nasties out there.
 

What happens when you’re presented with forty seven Windows XP computers: all networked, in a Windows workgroup, have varying levels of patches installed, hardly any internet connectivity and a limited time frame to get them to a current patch level? Now throw in every machine is infected and the infections is causing embarrassing and crippling problems to the users.

Here’s my solution; if you have a better one, or helpful pointers, feel free to comment.

- Assess the situation, explain the discovered risks to the business and come up with a plan of attack.

Uncovered background on the problem

• Tech support for the network is one poor soul that “is good with computers” but it’s not their primary job
• The same antivirus software (AV) was on all machines, but the definitions were totally out of date
• The admin password for all of the machines is the same
• Switched fast Ethernet network linked the machines
• The internet link was very expensive, very limited and only used for email
• The machines were riddled with malware -  Conficker being the most obvious
• The file server was another XP machine used to store all the data
• This is a favour to a friend so no budget and had to be done over an evening
• Business owner had signed off on the risk of patching everything in one go
• These machine were on four different floors (lots of running around), but only one network
• Random application software installed
• Did I mention no budget for anything IT, including support or training

Leaving aside the bigger picture of no security policies or procedures and a total lack of fundamental IT management, it was important to get to a measured and consistence baseline where the users could actually work.

The aim was to bring a standard, baseline patch level to the Windows machines, avoid full rebuilds and purge the main malware problems.

Here's my quick five steps :

1. Back up the file server, verifying data copy is malware-free and valid
2. Get the current service pack installed
3. Get all the current hotfixes installed
4. Check that all the machines are patched
5. Get all machines to the current AV definition level, scan and clean any malicious activity on the machines

Faced with a very hostile network, trusting one of the existing machines was not any option.

Thankfully virtualisation provides a great option to plug in a machine and dispose/revert it if this type of situation arises.  I also happen to have a Windows server virtual machine (VM) with Windows Server Update Service (WSUS) [5] installed on my laptop, that had been recently synced with the latest updates.*
 

Step 1: Backup the critical data off the XP file server is a copy an external USB drive

The drive was then plugged in to secured machine with a current AV. The autorun nasties were removed from the drive, the data was scanned and cleaned from all know problems. Then someone from the company confirmed the data was good.
 

Step 2: Create a share on the virtual machine for XP SP3 and deploy it to all machines

The wonderful PSEXEC [1] comes to the rescue as it can be used to deploy and execute the SP3 patch from the VM's share. Smarter scripting techniques [2] with PSEXEC mean you can automate this process for deployment.
As an example, this command copies SP3 to the target machine, then silently starts the installation and forces a reboot once the SP3 has been installed.
psexec computer  -c -f -s servershareWindowsXP-KB936929-SP3-x86-ENU.exe / quiet /forcerestart

Step 3: Deploy all current patches

Having a WSUS server as a virtual machine means fast, portable patch management with reporting. Using PSEXEC to deploy registry keys [3] to point all the XP machines to my WSUS VM, this forced all the machines to register and download the current updates. This proved a log of all the machines that connected, and what Windows patch level they were at.
 

Step 4: Check that all the machines are patched

Microsoft’s free tool Microsoft Baseline Security Analyzer (MBSA) [5] is a quick and effective way to verify that all the machines are up to the correct patch level, as it can reference the portable WSUS server at the patch baseline for each machine.
 

Step 5: Update AV and force a full scan

Copy the current AV definition to the same share as SP3. PSEXEC strikes again to copy to each machine and a simple batch script to kick of a full scan and confirm the scan has run successfully by dumping the results to the VM's share. This allows for a quick and easy way to check every machine has run AV, plus see what the AV detected on the machines.

End Result

This got the all the machines to the same consistent state and removed the problematic malware - all over one long evening.

Notes:

• If you do use the WSUS trick, remember to remove the registry keys afterward; using PSEXEC with a batch script will to do this nicely .
• WSUS could have been used to deploy SP3, but I find forcing patch deployment with PSEXEC is a lot faster. Had there only been a few patches missing, a WSUS server is somewhat over kill. A simple batch file utilizing hotfix chaining [4] and PSEXEC is a very fast way to deploy patches remotely.

[1] http://technet.microsoft.com/en-us/sysinternals/bb897553
[2] http://ss64.com/nt/psexec.html
[3] http://support.microsoft.com/kb/328010
[4] http://support.microsoft.com/default.aspx?scid=kb;en-us;296861
[5] http://technet.microsoft.com/en-us/security/cc184924
[6] http://technet.microsoft.com/en-us/windowsserver/bb332157
 

*Doesn’t everyone? Well if you’re building machines and travelling to places with poor internet access all the time, it makes patching a darn sight easier!
 

Chris Mohan --- Internet Storm Center Handler on Duty

Fresh from the Mozilla team Firefox 3.6.14/3.5.17 and Thunderbird 3.1.8 fixing a number of security issues:

http://www.mozilla.org/security/known-vulnerabilities/

Adobe have released Flash v10.2.152.32

And last, but not least, the Wireshark team have published 1.4.4

Get them while they're hot!

Thank you to a couple of readers for writing in with these updates

Chris Mohan --- Internet Storm Center Handler on Duty

Microsoft have moved their Windows Autorun V2.1 [1] (967940) update patch from optional updates to automatic updates.

This is the same patch that was released in last month’s patch Tuesday. When  Windows update is next run, this patch will automatically be selected to apply to your machine. This is more likely to affect home users, as companies should be using group policies to control how USB autorun settings operate.

[1] http://www.microsoft.com/technet/security/advisory/967940.mspx

Chris Mohan --- Internet Storm Center Handler on Duty

A good part of the fight against malware relies on "the good guys" sharing samples and intel. For some reason though, many anti-virus (AV) companies seem to make it exceedingly hard to "extract" usable samples from their tools and quarantines. They insist on a quarantine in proprietary format, and more often than not, the only option given in the GUI is "Send to Vendor" or "Delete".

Send to vendor? Well duh, how about sending to _more than one_ vendor? How about letting me extract the sample in an industry standard format, so that I can share it with the other AV vendors whose products I'm using to protect my corporation or university ?

Exasperated by a recent run-in with the quarantine mechanism of a particularly stubborn yellow product, I googled some, and found out that there's actually an IEEE Working Group looking into standardizing an open Malware Exchange format. Good news. Though even better news would be if the format chosen were simply an existing forensic file format, maybe with added encoding or encryption to turn the sample inert.

But, no matter which format gets selected eventually, I sure hope that (a) this happens soon and (b) that the AV vendors actually adopt the idea and make extracting and sharing samples and intel easier than they do today. Because most of their products today ... to me look a whole lot like the vendors don't care [beep] about their client's security and efficient malware defense. Not anywhere as much as they care about their own revenue.