Packet Sniffing

Many of our readers routinely ask us what ways they can capture packets to send data to the Storm Center.  A couple of different things to consider:

What do you want to capture? 
    Specific ports or protocols? 
    Snapshot of traffic?

What line speed are you capturing at?

What device are you capturing on?

Two common tools to do the packet capturing with are: tcpdump, wireshark/tshark.  In this diary we will examine each of these briefly, along with their pros and cons.

tcpdump

The venerable tcpdump is a staple to many of us that analyze traffic for a living.  It is simple, powerful, and above all ported to many platforms.  Tcpdump uses the bpf (Berkeley Packet Filter) format for filtering packets out of your capture. 

An example tcpdump command:

tcpdump -nn -i eth0 -s 1514 -w file.cap 'tcp and port 5050'

This command will capture full ethernet packets (1500 MTU + 14 bytes for the frame header), binding to interface eth0 (-i switch), and write to a file called "file.cap".  The end of the command line is the bpf, filtering packets matching tcp port 5050 (both source and destination).  The -nn disables name and port resolution.


wireshark / tshark

Wireshark and tshark are the new names for the oldschool tools, ethereal and tetheral.  Wireshark is the graphic tool, and tshark is a commandline tool.

Given that most probably have experience with wireshark or ethereal, lets look more closely at tshark.

The biggest advantage for using tshark is that it includes a ring buffer for packet capturing.  If you find yourself dropping packets with tcpdump, try using tshark with the ring buffer.

The following command runs tshark binding to interface en0 (-i) , disabling name resolution (-n), and using a ring buffer rotating files after every 10000K (-b filesize:10000) and writing to a basename of "foo" (-w foo).

tshark -i en0 -b filesize:10000 -w foo -n

You end up with files named as follows:
foo_00001_20070831000015
foo_00002_20070831000039

Next time we will look at Marty (of Snort fame) Roesch's new tool: Daemonlogger.
 
Mike Poor
Intelguardians

We regularly have readers inquire about recommendations for filtering bad IPs, networks, or in the worst case regions or entire  countries. When used properly, blocklisting/watchlisting can provide enormous benefits, however using stale or inaccurate lists or employing heavy-handed tactics like filtering out continents can stifle communications and affect commerce in hard to foresee ways. Except for very specific cases like a parts distributor that only services customers in a region and therefore may not need to allow inbound access from across the globe, blocklists need to be approached with caution.

A good example of a blocklist gone bad is the still unresolved issues with APEWS and the senseless fallout their practices have caused:

http://isc.sans.org/diary.html?storyid=3189

There are a number of high-quality feeds out there providing granular (and fresh) blocking or alerting capability and there are times where such filters may prove to be highly appropriate and useful. We see IP addresses and entire netblocks never leaving the Top 10 offender lists for things like command and control, call-homes, and malware download sites.

We'd like to take this opportunity to point folks at a drop list they might not have seen before. The goal here is to highlight a few of these bad apple netblocks that many sites not already leveraging this list might find useful to use in systems which provide alerting or filtering capabilities as appropriate (your mileage may vary and the use of any "feed" should be evaluated first)

http://www.spamhaus.org/drop/drop.lasso

Now for a few gems from the list that some will recognize right away and others will see the light after a brief google or diary search:

Russian Business Network:

81.95.144.0/20  #SBL43489
(81.95.144.0 - 81.95.159.255)

Nevacon:

194.146.204.0/22  #SBL51152
(194.146.204.0 - 194.146.207.255)

Intercage:

85.255.112.0/20  #SBL36702
(85.255.112.0 - 85.255.127.255)

A good place to start is to search your proxy logs for IPs in these ranges for example and pay particular attention to query strings. Anything like a "port=12345" might be worth looking into port 12345 on that client machine for example.

[Note: There are many other dynamic blocklists out there from volunteers and companies which are excellent. The goal here was to highlight the list of fairly static bad apple netblocks and the possible benefits of not allowing traffic to or from them.]

The Handlers

Some of you will have noticed some vista patches coming through today.

It looks like there are 5 patches, 2 important, 2 recommended and one optional.

NOTE: The readers are reporting the AMD patch also applies to XP, likewise 933360.

Also a reboot required, but then it would be unusual if it didn't.

A reader (thanks Dan) also mentioned this link http://support.microsoft.com/kb/894199/en-us. which seems to be a good synopsis of the patches deployed.  Might be a good spot to check patch Tuesday stuff.

Cheers

Mark H - Shearwater

A number of readers wrote in this morning that they were experiencing issues when updating Fedora Linux. 

You may receive the following error on the elfutils-libelf package:

Unable to verify elfutils-libelf-0.129-1.fc7.x86_64

Details:
Public key for elfutils-libelf-0.129-1.fc7.x86_64.rpm is not installed

Apparently seven other packages are affected, which have not been publicly identified. These packages do have been signed, but when they were moved from testing to update, remained signed with the incorrect "test" key. It may be prudent to hold off on non-critical updates for a short bit of time while the Fedora developers work to resolve this issue.

Over the past few years, "identity theft" has come into common use among consumers and mainstream media.  The payment card industry has published data security requirements to help reduce the risk for merchants and the banks.   And many states such as California, Arkansas and others have even put together laws requiring notification should a data theft or other exposure occur while information security professionals (like you or me) have done what we can to limit the exposure for our respective organizations.

So a normal consumer might feel reasonably confident that their information is protected, especially when using point-of-sale (PoS) devices.  Think again!

These PoS systems have a number of security concerns that were brought to the public today by  Dr. Neal Krawetz in a white paper located at Hacker Factor. Though the payment card industry has published security standards, the white paper shows that the security of financial infrastructure continues to be reactive or almost a complete facade in some instances.

All of the vulnerabilities discussed in the white paper have been known by the industry for many years, however were not recognized as risks or have been slow in addressing these risks.  So will the industry learn how to best protect this type of information and not soften their stance on security?  Will the industry help small businesses update their equipment and procedures to reduce their risk, or will they continue to focus on larger organizations?

If you handle credit cards in your organization, especially using point-of-sale devices, you should read this white paper as it contains a number of valuable questions which should be asked of PoS terminal, and branch server vendors.

So the next time you visit that gas station, video store, fast food joint, or department store, you will be left wondering whether the retailer has the correct equipment to protect your card information, or the procedures to clear stored information regularly to limit the risk.

These types of concerns are not limited to PoS devices as there are some big risks that go along with ATMs (such as reprogramming them to give 20s for the cost of 5s, changing phone numbers, etc).  Throw in the continued growth of debit cards (which have direct access to your money), and I can see a lot of problems for the near future.   Hopefully the PCI rules will continue to get tighter and that more and more retailers and banks will either meet the standards or exceed the requirements.

In the meantime, I think I will be using cash for a long while to come.

So, on a sunday morning, I was watching some hacker activities.

These hackers were doing the following pattern:

- Using bots based on Perl
- Querying Google for parts of the urls that may identify some applications, using the "inurl:" parameter.
- Scanning the Google results sites for vulnerable applications
- Exploit those applications in a way to run remote commands on the machine, giving orders like download additional software to the machine, like the same perl bot.

As the "plat du jour" , the following services/applications were being scanned, using google:

- modules/tinycontent
- flashchat
- /xgallery/
- webcalendar

So, if you use any application that contains these strings in the url that makes easy for them to find your site, beware and check for additional updates on these applications!

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

Pedro Bueno < pbueno //&&// isc. sans. org >

The latest variation of the Storm worm claims to be a youtube video. The link looks like a link to youtube, but actually points to a "numeric" URL like old storm variants. The downloaded binary is called "video.exe". Malware researchers: This time, the web server will make sure that you are using the right referrer.

The source code for the URL:

<a href="http://10.99.65.224/">http://www.youtube.com/watch?v=Ga4y9EQMuDe</a>

of course, this is just a sample... I replaced the first byte in the IP with 10 to protect the innocent again.

And a quick update. i forgot to post this tip form Robert Reid last time around. Sorry for the delay. Its still a useful tip:

(this ISA signature will block access to web servers that identify themselves as "nginx/0.5.17". This is actually a valid web server, but used very little aside from "Storm". As always, watch for false positives)

We use ISA server and http filters to block access to various web apps and it occured to me today to do the same thing with Storm. These instructions will work for both ISA 2004 and 2006 and are completely effective.

1. Right click your default access rule and select "Configure http".
2. Click the "Signatures" tab then "Add"
3. Drop down the "search in" box and select "Response headers"
4. In the http headers field type "Server:"
5. In the "Signatures" field put "nginx/0.5.17" (the web server type and version used by Storm)
6. Give the signature a name, click ok, click, apply.

The http filter will now block the download of applet.exe on all web proxy clients. Clients will receive the message:

"502 Proxy Error. The request was rejected by the HTTP filter. Contact your ISA Server administrator. (12217)"

we got reports (thanks Mike, Matt...) that Microsoft is having issues with its WGA validation servers. This may affect downloading some software from Microsoft as well as new Vista installs. From posts to a Microsoft forum, it looks like this may persist for a few days. I am not sure if the phone-based activation still works, but its something you may want to try.

This should mostly effect Vista users.

For the Microsoft forum see:

forums.microsoft.com/Genuine/ShowForum.aspx

and a statement from MSFT: forums.microsoft.com/Genuine/ShowPost.aspx

The IRS wants to give you $80 dollars to participate in a survey, yup really.

Aw... alright, so it’s the IRS scam that is back again, this time with a twist.

<Phish>

Users will be receiving SPAM messages from the IRS along these lines:

From: Internal Revenue Service [mailto:security@IRS.gov]
Sent: Friday, August 24, 2007 5:23 AM
Subject: IRS Survey : $80.00 to your account - Just for your time!
Importance: High
Congratulations!
Dear Customer,
You’ve been selected to take part in our quick and easy 8 questions survey In return we will credit 80.00 to your account - Just for your time!
Please spare two minutes or your time and take part in our online survey so we can improve our services.
Don’t miss this chance to change something.
To continue click on the link below:
htm://www.irs.gov/login.asp=survey
© Copyright © 2007 Internal Revenue Service U.SA

 The link directs you to a survey page where the IRS’s satisfaction is measured, product knowledge, etc.   The only details requested on this page are your name, phone number and if you want to an email address.

On submission a results page is shown where the credit card details are entered to receive the $80.

Straight forward so far.

</Phish>

So why the phone number?

That’s where the Vish comes into play.  Using VoIP to call the person and social engineer information out of them.   For example:

<Vish>

“ Hello Mr I fell for-it, this is Tim from the IRS.  Thank you for filling out the survey, however you didn’t leave any details for us to deposit the $80.  If you provide me with some information now we can arrange payment.”

“uh, ok”

“Let’s start with verifying some details, starting with your social security number....”

.....

</Vish>

Now it might be that the phone number will be used in any case.  A credit card number and name is valuable, combined with other personal information it is much more valuable.

There will have been millions of emails sent, so we don’t really want any of those at this stage, but if you know of anyone who has been approached via voice after completing one of these surveys please let us know.

Mark H - Shearwater

Humour and politics don’t usually mix, but when you start getting closer to an election things just get a little bit more interesting.   In Australia we are getting closer to a federal election and as the day dawns things are heating up.  One of the topics that had some traction for a number of parties was protecting kids online, an admirable goal.  The current government is therefore now spending AUD189 million to help protect kids online.  AUD84 million was set aside for filtering products for the home computer, to be made available to all Australians for download (some of you are probably already seeing where this is heading). 

A few products were selected (but not endorsed by the government) and made available to the public for download on the 20^th of August.  The products are available for various flavours of Windows and Mac and perform the filtering and reporting functions you would expect of this kind of product.  Five days later, you guessed it.  A 15 year old has found a way around the filter (full story here), leaving enough in place for the parent to have a false sense of security and he is able to get to all those nasty little places on the internet.   The relevant vendors are no doubt working hard to fix the issue, but funny nonetheless.  As we all know it is not really a question of if the product can be circumvented, but how fast (something that is actually stated on the governments own site).  In this case my guess was closest with 4 days, so the pot is mine!

Now to be fair to the government the program they implemented was not just an attempt at retaining votes (although I’m sure that it was part of the idea).   When you look closer at it, it is actually a well thought out program.  There are sites for kids and parents to visit to learn about responsible internet use, things to look out for.  The main issue I have with schemes like this is that they are unlikely to reach the people that really need the information.

As for my kids, they know what they can and can’t do on the internet, they also know that dad watches everything, new sites are vetted before they can use them and they know that if they come across anything that makes them uncomfortable they are to let me know and teach them about security issues.  I asked my 8 year old the other day for her email password so I could check it (it’s easier to ask her, she uses a 8 character password with numbers and special characters, maybe I taught her too well....).  She said “I’m not supposed to tell you daddy”, luckily for me social engineering your own child still works, but she has the right idea.

In the real world it is easy to tell your kids don;t talk to strangers, don't walk down dark alleys, don't go to that part of the city.  On the internet it is not often clear where the dark alleys are and who the stranger is.

Cheers

Mark H - Shearwater

Its friday. So instead of scaring everybody with an emergency patch you need to apply, let me "editorialize" a bit so you have something to think about over the weekend.

I have long wondered where e-mail is going these days. For me personally, the business value of e-mail has certainly become small. I run various anti-spam techniques, and setup an "important" inbox with e-mail from people I regularly correspond with. But good luck to get my attention if your e-mail ends up in my generic "inbox".

So I just read about DynDNS dropping "Non Delivery Reports". In short, if you are using their service, and your e-mail bounces, you may not hear about it. This is actually something I started doing a long time ago, and it worked fine so far. I don't actually expect my e-mail to go anywhere in the first place. If I don't get a response, I will just try again in a could days, or well, by then another project came up and the original e-mail didn't matter that much anyway.

I am a bit mixed about if I should send NDRs from my mail server or not. The random spammers certainly create a lot of them. But then again, I may as well tell them that 'tom@example.org' doesn't exist. Maybe they will stop.

Of course, there are RFCs that regulate these things. But the SMTP RFCs are broken in the sense that they don't have a meaningful way to fight spam. Otherwise, we wouldn't have so much spam.

Other rules I considered or tried in the past:

- greylisting. Works ok, but still.. too much spam. And I lost some important e-mail that way. For example, one of the airlines I fly with wasn't able to send me a receipt.

- only accept PGP signed e-mail. That wouldn't actually do much for spam. They could sign it. But they don't. However, neither do valid e-mail sender.

- turn off my mail server. Wowo... a 90% accurate spam filter. But well, the other 10% is why I bother with e-mail in the first place.

I will setup a poll shortly to collect your opinion about this.

 Just a quick update: When I am talking about "turning off NDRs", I am not talking about turning off 550 errors on the SMTP level. That may still be a good idea if you don't mind people enumerating your accounts.

Indications are that the ServerProtect exploit is against an older vulnerability from earlier this year, February 2007.  This vulnerability was patched previously.  The vulnerability appears to be "vulnerabilty one" in this advisory:  http://dvlabs.tippingpoint.com/advisory/TPTI-07-02

But this does indeed appear to be a new exploit, thus machines are being actively compromised if they haven't been patched.

No sooner than I post a call for packets but I catch an event that surely looks suspect.  I'm unable to confirm the destination target was in fact running a Trend management service or if the result of the following attempt.  Let's see what our shellcode analysts can determine before we post complete packet payload. 

We are seeing some heavy scanning activity on TCP 5168.  Probably for Trend Micro ServerProtect.  There was vulnerabilities announced for this product yesterday.  http://secunia.com/advisories/26523/ and http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=588

It does indeed look like machines are getting owned with this vulnerability.  More info to come...

UPDATE: To expedite your patch finding needs, Trend Micro has made product patches available for download from:

http://www.trendmicro.com/download/product.asp?productid=17

OPEN CALL FOR Trend Micro management service "RELATED" PACKETS! 

I had just made a request for packets from one of our writers, and figured it a great opportunity to make it open season for packets.

If you *reading this* are witness to TCP port 5168 scanning activity, and feel you have a reasonably safe platform to perform additional data collection for us, we'd really appreciate it.

I am making blind assumptions that you have a linux host out there on publicly routable IP space of course:
1. We need some full packet capture for traffic inbound to your analysis host on TCP port 5168, and let it run...
2. Also, netcat listener enabled service port emulation to capture any possible initial payload beyond arbitrary scanning.
   For the netcat interaction, the GNU version of 'netcat' would be required ( http://netcat.sf.net) as the 'nc' binary commonly distributed by default does not have the features preferred for capturing service data.  Also, I do recommend running the never ending loop from within a screen session, and you can kill the screen to dump the infinite loop.


# tcpdump -i eth0 -s0 -nn -w trend-of-evil.pcap tcp port 5168  &

====================

$ screen -S trend
   # NOW YOU ARE IN SCREEN!  w00f-w00f!
$ while true
do
  netcat -x -o monitoring-the-trend-of-evil.hex.txt -vv -l -p 5168 >> monitoring-the-trend-of-evil.txt

  date +%Y%m%d-%H%M%S >> monitoring-the-trend-of-evil.txt
done

If you spot any unusual frequency of activity, *especially* if you have no particular idea of what might be in the *.hex.txt output file. Then ship us a copy, via our handy dandy file submission contact form at http://isc.sans.org/contact.html

W

We received several messages yesterday about the monster.com incident and personal information on 1.6 million users of monster.com stolen.  We actually reported on this two days ago here:  http://isc.sans.org/diary.html?storyid=3295.  At the time, SecureWorks had discovered a cache of only 46,000 users.  Funny how the number of users affected (large in either case) forced the press coverage to become way bigger.

The incident reminds me of the LexisNexis compromise where a police officer's computer was compromised and his LexisNexis account was used to lookup personal information on 310,000 people.  Wired has a good article on the entire story from May 2005: http://www.wired.com/techbiz/media/news/2005/05/67629?currentPage=all

Across the world, copper prices have increased substantially over the last couple years. As a result, theft of copper has been on the increase. In my area, multiple houses and business got stripped of their air conditioners, and in some cases (mostly construction sites), copper wire was stipped out of the building and large spools where removed from the properties.

Having your AC stolen can be a huge disaster for a data center. Most of the time, the copper (or even aluminium) heat exchanger is outside of the building and not well secured. The usual recommendation is to build a "cage" around the device which still allows for sufficient air circulation. Monitoring the temperature in your data center (or server closet) is a good idea as well. Many alarm systems and alarm companies will be able to monitor it for you and alert you if it exceeds a given range.

One reader (Scott)  noted that a number of transmission towers they owned got vandalized by copper thieves. In his case, old microwave guides got stolen from the towers. Needless to say, it is not easy to monitor remote locations like towers.

Michael wrote in to share a story about a major disruption of a german rail line a while ago due to stolen cable.

As hurricane Dean intensified, we did see a number of related domain registrations. At this point, we are not aware of any of them being used fraudulently. If you come across one, let us know. There is very little infrastructure in the affected area, so we expect minimal impact beyond the directly affected area.

See our prior "disaster preparedness" diaries on tips how to prepare for this kind of event.

Looks like Storm moved to a new mutation. The e-mails are now inviting users to become members in various "clubs". Here is a sample I just got:

Subject: Login Information

Dear Member,

Are you ready to have fun at CoolPics.

Account Number: 73422529174753
Your Temp. Login ID: user3559
Temorary Password: jz438

Please Change your login and change your Login Information.

This link will allow you to securely change your login info: http://a.b.c.d/

Thank You,
New Member Technical Support
CoolPics

I have seen about a dozen different once so far. They are all "confirmations" in this style to various web sites. The web page offers again an "applet.exe" for download.

In short: We don't need to enumerate variants of the e-mail message. If you are brave and know what you are doing, download the applet.exe and try to reverse it (not easy typically). Thunderbird warned me that the link is a scam. (I think it does so for all numeric IP links).

My copy of applet.exe was about 114 kB large. While many AV scanners detect it as "evil" based on heuristic signatures, some well known scanners don't (maybe Virustotal is running them without heuristic turned on, or they just don't do it)

 IMHO: this is a lost cause. People are either infected or they know how to protect themselves.

(From virustotal.com)

File applet.exe received on 08.21.2007 05:21:50 (CET)
Current status: Loading ... queued waiting scanning finished NOT FOUND STOPPED

(I replaced the numeric IP address with 'a.b.c.d')

It appears many, many accounts on monster.com were stolen and are now being used to send credible spear phishing job ads to users.  What makes this attack interesting is that the phishing organization behind it is very organized.  In short, monster.com registered recruiters have had their accounts compromised so phishers can use them to send credible job ads to perspective victims.  Normal phishing attacks (spam the world) can net up to 10% of recipients.  According to some studies (which I can't find at the moment) that number increase to 80% when the e-mail is credible such as coming from social networking sites (i.e. friends) or job ad sites like this attack.  To be fair, those are numbers of people who have ever clicked on a phishing email, but those are still big windows of compromise.

One of the trojans used in this case is Prg Trojan and the organization putting them out has staged variants and releases new ones as soon as the last one was detected.  The result is that AV doesn't do much for you because the second it is detected (and hopefully cleaned) a new, undetected version comes out.  Rinse, Repeat.

Brian Krebs at SecurityFix has a good article and analysis of the whole thing.

One could try to stop clicking on links even from job ad sites but that makes the service near unusable.  Recruiters would start having to send prospective employees job descriptions in text with the URL in text.  Yes, text-only e-mail readers are still better than HTML, for obvious reasons.  AV can't keep up.  I'm trying to get more details about the fake ads and the malware so I may have specific defenses shortly.

There are tactics to raise the bar here, perhaps monster and others can just force a system-wide password reset to lock out the attackers.  However, the core problem is simple and it's this: the PC is not a trustworthy device for sensitive information... period.  As long as people keep treating PCs as "safe", phishers, frauders, and herders will keep exploiting the vast majority of insecure desktops, installing backdoors, and stealing information.  As long as credit cards companies and banking companies rely on weak authentication (username and password), that information will keep getting stolen.  Social Security numbers don't require ANY authentication for us, and we're approaching a point were most to all of those numbers are essentially compromised and public.

--
John Bambenek / bambenek {at} gmail {dot} com
University of Illinois at Urbana-Champaign

The purchase of ClamAV by Snort will likely be a boost for both Snort and ClamAV.  In the next few weeks I was planning on rolling out a network-based virus-scanner here in the hopes of catching recalcitrant users machines that aren't keeping up on antivirus updates.  The purchase will hopefully lead to some better integration.  That said, it also exposes the signature-based security methodology as one that is ultimately destined for failure. IDS/IPS and signature based AV isn't dead, but it is paraplegic. And for the record, Snort isn't the worst out there, I use it because its one of the best as far as IDS goes.

There have been a few studies showing the performance issues of IDS/IPS which limit their applicability to security in real-time.  The problem stems from the stance pervasive in information security that I call the "principle of most privilege".  Namely, unless something is known to be hostile it is presumed safe.  The problem is that the number of packets, executables or emails that are safe is finite and small.  The number of hostile packets, executables or emails is infinite and our signature system is only limited by the fact that exploits only get discovered so fast.

In order for IDS/IPS systems to keep up with an every increasing network, the signature base needs to remain low.  To be fair, this also applies for virus-scanning on the desktop.  The big difference is that most PCs tend to not be fully-utilized so a 10-20% performance hit only really bugs the power users (you know the type… they are the ones that turn off their anti-virus applications because it slows them down and then complain to you when their credit report shows up on the internet… they, of course, blame you).  However, a network can't take such a performance hit.  In an era of online social networking, which is basically technology's version of a flash mob, network performance hits become less than acceptable. 

The solution is to either slow down the IDS/IPS or slow down the network and neither are good solutions.  Adding virus-scanning to an NIDS might sound like a good idea, but do you think it could keep up with a 10G network?  Me neither.  If they were into it, they could produce some good network statistics and that would be really useful.

As long as the security industry continues to operate under "most privilege", there is no way IDS/IPS solutions will keep up.  Not if they want to maintain real-time alerting.  They'll still have uses for forensics and after-the-fact incident handling, but they'll be dropping off as a front-line defense because the technology is unsustainable under the current paradigm.  For that matter, the time is coming for anti-virus software companies too, but because the performance hit is less of an issue on the desktop, they'll have more time.

It's far past the time to move to a system where packets (for an IDS/IPS) and binaries are disallowed until otherwise allowed.  That would be proactive security.

We have a new poll question up "Will IDS/IPS devices remain relevant?".  Let us know your thoughts.

--
John Bambenek / bambenek {at} gmail {dot} com
University of Illinois at Urbana-Champaign

Skype is apparently fully functional and has released an explanation of the problem that attributes the failure to Patch Tuesday.  Specifically, the peer-to-peer network failed because of the large number of simultaneous reboots and consequent relogins to Skype on boot.  There are some questions with this explanation, namely why did it take over 24 hours for the system to fail after a 3am reboot (the default) on Wednesday (failure was Thursday) and if Patch Tuesday is to blame, why didn't it happen last month?

The more interesting notes for me as a non-Skype user is that this shows several consumer behaviors and their ill-effects.  The automatic updates for Microsoft are 3am local time to the machine.  Very few people change this, even on the enterprise level.  For most places, it makes sense.  Most are in bed at 3am and nothing is going on.  A few 24x7 shops might want to rotate times a bit to prevent disruption of work.  But mostly, users (particularly consumer-grade users) aren't going to touch the defaults on their machines.  If only we had operating systems and software packages that shipped in a hardened-by-default way, many problems would be averted.

The second interesting note, is that if Skype's explanation is true, that means that vast majority of Skype users have machines that don't require a login on boot.  Those machines simply happily login as the default user (and I bet almost all have full admin rights) and the log on to Skype (and their other start-on-boot applications).

Neither of these two behaviors are particularly surprising.  Consumer-grade users will not have the time, inclination, and/or capability to harden their machines and you simply can't make them do it either.  Systems need to be shipped as hardened-by-default but be usable too.  So, dear reader, how would you fix it?

UPDATE (11:06 CDT 8/20/07)

According to ISC Reader Raul, the VOIPSA list has another theory that the crash was in fact a malicious DDoS.  There is a proof-of-concept code that will send malformed URIs to Skype Servers that will cripples them and allow them to transverse the entire server list.  The ultimate result, assuming enough malicious users do it, is a DoS against the entire balance of Skype servers.  I'll contact Skype to get their opinion on the PoC...

UPDATE (11:12 CDT 8/20/07)

And for some humor... (courtesy of ISC Reader roseman)

UPDATE (13:10 CDT 8/20/07)

After reviewing many reader comments, various mailing lists and other sources, I'm inclined to agree that Skype's line on blaming patch Tuesday is a line of bull.  The PoC out may or may not work (there is no safe way to test it because the code is proprietary) but there seems to be more than they are telling and many people (including myself) are less than convinced with the story line.  The patch Tuesday theory doesn't add up.  Why did it take "so long" to have the failure?  Why not last month?  What about this Proof-of-concept?  Skype just isn't answering the questions that matter.

Consumers can tolerate proprietary code (see Microsoft)... consumers don't tolerate being snow-jobbed by their vendors well.

UPDATE (17:00 8/20/07)

Robert McMillan over at CSO got a spokesman at Skype to answer some more questions.  Color me unimpressed.  Microsoft has also posted their comments... "it's not our fault".

--
John Bambenek / bambenek {at} gmail {dot} com

SANS started a YouTube chanels with short videos of our instructors introducing their courses or giving small security tips. So finally a reason to watch YouTube at work and not having to hide the screen :-).

Videos will be added in the short future (we just did a few more last week). So you may want to use the "Subscribe" feature in YouTube to be alerted of any additions.

URL: http://www.youtube.com/user/sansinstitute (Or just search "sansinstitute")

Nearing the end of a fairly uneventful day, we had one last submission about the Storm Worm changing tactics.  As the daily readers may recall, this first hit our radar last Saturday which, oddly enough happened to be my shift as well.  Now we are seeing new subject and phrases that are now adult oreinted.  We are not sure why the change of tactics yet, but will keep you posted.  The attached file is exactly the same, not even a name change on that one.  Odd.

Anyway, have a great week, we'll see you on the flip side.

Tony Carothers

Handler on Duty

As if we didn't have enough excitement already with the Gentoo servers being taken for a ride, now we have the Ubuntu Servers being hacked to attack others.  Interesting read, a quote from the article "More than half of Ubuntu’s production servers had to be pulled offline after a security breach caused those servers to actively attack other machines."  On a quiet Saturday we've had some other things pop up, but we are in the process of getting details before we release.

We don't have any reports of significant increases in malicious traffic (yet) but just as a reminder to sysadmins around the world many colleges and universities are welcoming back their students this weekend and next weekend.  Due to the world-wide spread of malware through the Storm Worm over the past several months we expect that all of those infected laptops will have a field day once they connect to the university networks.

Marcus H. Sachs
Director, SANS Internet Storm Center

Here are some links to odds and ends that came to us through the day today.  Thanks, readers, for your links and comments!

Sourcefire buys ClamAV

Updated TrendMicro Rogue DNS Servers

Apache HTTP Server Mod_Status Cross-Site Scripting Vulnerability

Multiple Vulnerabilities in IBM DB2 Universal Database:
IBM DB2 Universal Database Multiple Race Condition Vulnerabilities (root access)                                          
IBM DB2 Universal Database Directory Traversal Vulnerability (root access)
IBM DB2 Universal Database Multiple File Creation Vulnerabilities (privilege elevation)
IBM DB2 Universal Database Directory Creation Vulnerability (privilege elevation)
IBM DB2 Universal Database Multiple Untrusted Search Path Vulnerabilities (root access)
IBM DB2 Universal Database buildDasPaths Buffer Overflow Vulnerability (root access)
Vendor response:    V8    V9

Cisco IOS Vulnerability           Cisco's forum discussion

Problems at Gentoo

Storm Worm fights back

Marcus H. Sachs
Director, SANS Internet Storm Center

As reported in a diary yesterday, the Skype VoIP service has been down for well over a day.  Many of our readers report that they still can't get their clients to connect, while others say it's working fine.  According to Skype, all is well and everybody should be happy.

So what is really going on?  Was it just a "software problem" as Skype says?  Here are some ideas to consider:

• Was the Skype outage caused by the publication of a Skype DoS exploit?
• Was it caused by the mandatory reboot after Microsoft's Patch Tuesday?

Both theories are referenced at http://colsec.blogspot.com/2007/08/skype-outage-last-24-hours.html

Unless something "new" comes up, we ask that you keep an eye on Skype's heartbeat blog for further unfolding details.  (Thanks, Roland, for the links!)

Marcus H. Sachs
Director, SANS Internet Storm Center

We've had a few reports that Skype is inaccessible.

If you have any definitive information as to why, let us know.

- Christopher Carboni

An overheard snippet of conversation yesterday regarding tropical storm Erin seems like good reason to talk briefly about Disaster Recovery plans.  Do you have remote offices in severe weather or natural disaster prone areas of the country?  Do you have a procedure to follow when a predictable event (Hurricane, snowstorm ...) threatens to close down business?  The plan, can be as simple or as complicated as you want it to be.  Personally, I like simple.

Say you have an office in an area known to get frequent hurricanes.  A brief checklist detailing steps for an out of rotation full backup, shipping the tapes to the home office, and gracefully powering down systems (before the situation becomes so bad you get trapped, no heroes please) is a great way to make sure your data is protected in a worst case scenario.

One last piece of advice.  Don't wait until the last minute to ship your backup media.

If the event will happen on Friday afternoon, you may want to make your backups on Wednesday night and ship them on Thursday.

Mail service as well as package pickup and delivery from the big carriers are often suspended earlier than you might like, leaving your backup media in a drop box or local pickup facility during the incident.  Not that I would know anything about that ... ;)

- Christopher Carboni

http://www.theregister.com/2007/08/15/shark_trojan_creation_kit/ 
They claim it has vmware detection capabilities along with debugger detection. This is just yet another tool that makes malware creation simpler for the bad guys with money. I have not seen a copy of this tool kit yet but hope one of the “good guys” is analyzing it.

If you google for l61.3322.org you will find LOTS of “script” links to:

http://l61DOT3322DOTorg/eDOTjs. That first letter is an L not a 1.

Be careful that java script attempts to exploit vulnerabilities in some browsers.

Fellow Handler BojanZ stated this about that malicious piece of java:

“The attached JS file calls other JS files (from various servers). At
least one of them tries to exploit an old vulnerability (MS06-014 -
Microsoft Data Access Components (MDAC)). Other JS files redirect the
browser to different sites:
http://www.777seo.com/seo.php?username=happygold
http://www.ovosearch.com/advertising/?ref=happygold
http://kikclick.com/portal/?ref=happygold
(these are click through affiliate web sites)”

3322.org has hosted malware several times in the past including a element of the zero day word exploit that was reported in 05-2005
http://isc.sans.org/diary.html?storyid=1348

It was also used as the ftp download site for a SAV based worm 12-2005.
https://isc.sans.org/diary.html?storyid=1945

Thanks Bryan and Evan for bringing this to our attention.
I recommend you monitor your IDS, firewall and other logs for access to l61DOT3322DOTORG if you see any access you should check the systems that accessed it for malware. You may decide to block that site within your enterprise. Many enterprise and educational networks did block 3322.org during the word zero day exploit in 2005.

Winfried wrote in about a story in Dutch about a bank in the Netherlands. The announcement of the bank in English is here: https://www.abnamro.nl/nl/overabnamro/en_internet_crime.html

This bank has -like most European banks- an online banking application for their customers using strong authentication. A hardware based off-line token that requires a pin code and generates a one time password. The juicy part for attackers is however the ability to transfer money to other accounts (even accounts that are abroad).

Now most such banks out in Europe use strong authentication, signing of transactions etc. still it's not safe apparently. So what can go wrong ?

Man in the Middle

The traditional attack against well protected website is to install something in between the client and the server. It will let pass through the authentication, but might change transactions (before they are signed) or add transactions (if they can be done without signing or if they can be grouped and the group signed as one action).

Where can the user detect this?  The one warning about a bad SSL certificate. If the user accepts the certificate, all his chances of detecting it become very slim to nonexistent. But we all know at least a dozen websites that do not have proper SSL certificates and as such teach users to accept certificates.

The attacker might show his hand in the process of applying the signature to a transaction, but most people do not always know the string of digits and operators they press on their hardware token are in fact account numbers and amounts of money to be transfered that they are signing. They just see it as numbers to type and get the result back to the website to move on.

Most banking websites I've used (I'm not a customer of ABN AMRO) do not tell or emphasize the meaning and the need to verify what you are signing. And if they allow you to use a temporary storage of transactions that you can sign in one go, it's unlikely you'll have to sign all accounts and amounts individually, so you're signing something (with a non-repudiable signature!) that you cannot verify as you cannot trust what you see from the man in the middle is also what he gave to the real application.

The bottom line is to make sure:

• Have the right hostname (bookmark it)
• Have the https
• Have the little lock
• Have a valid certificate

If you miss any of them ... stop.

Now that man in the middle attack is hardly news, so what's new out there now?

Trojan

Apparently this bank had a targeted attack against it March and again today.  The Trojan was mailed to the victim with instructions to install the software. Obviously such a Trojan can make all the interaction between the user and the remote website unreliable. If the client machine is unreliable every measure described above is insufficient.

It's worse than the man in the middle attack as all the signs of the man in the middle attacker can be completely hidden from the user.

In theory, the Trojan can completely change what the browser shows the user, with whom the users talks, if the SSL certs are valid, what one sees on the screen while signing transactions, the works.

Now the actual Trojan was not yet this advanced it seems, but it's a small step in addition to take and it's not going to get easier for those defending against this type of attackers.

The ABN AMRO attack

Freely translated from the Dutch article for the benefit of a global audience: 

Kaspersky is referenced as the source of how the trojan worked (the method of distribution is unconfirmed).

• The malware tracks which websites are visited and passes it on to a hacked server.
• As a https-site is visited, a second stage is downloaded and activated that logs traffic. These logs are also transmitted to the hacked server.
• If the ABN AMRO-website is visited, a third piece of malware is downloaded and activated that specifically attacks their site.

ABN AMRO uses two factor authentication, but it apparently does not make a difference between the codes to log in and those to sign a transaction.

While this does make it easy for the attackers to do their thing, the Trojan could just as well work against much more robust implementations as well.

The third Trojan allows the user try to to log in, but tells the user the attempt failed, sets up a transaction in the real web application and asks the user to try to login again, confirming the transaction it set up behind the scenes.

Kaspersky also has a clean up page should anybody need it (in Dutch again):

https://www.kaspersky.nl/abnamro/uitleg.html 

Is this the end of strong authentication?

In my opinion absolutely not, but I hope all our readers will think twice before logging in on their online banking from e.g. a cybercafe while on holiday. The strong authentication alone will not defend you from everything.

Similarly I hope people signing transactions actually learn what they are signing and verify it before typing the numbers.

Banks should teach their users to verify what they sign and perhaps need to abandon systems where you can sign multiple transactions in one go or where you can transfer money without signing the transaction. Logging in once again isn't a non-repudiable signature.

Risk management could be used to determine maximum risks the bank is wiling to take in order to achieve ease of use for the customers, but care has to be taken on who takes the risk when technically non-reputable signatures have been used.

As Winfried put it: "nothing of an infected computer can be trusted".

A note to the US based readers and/or people working for US based banks: plain old passwords are much easier to attack than one time passwords and they can be attacked at any time. OTP (one time passwords) significantly raises the bar for an attacker, that it too can be overcome is no reason whatsoever not to make it harder on the attackers.

--
Swa Frantzen -- NET2S

Overview of the August 2007 Microsoft patches and their status.

--
Swa Frantzen -- NET2S

Some of our friends in Canada have been pounded, since yesterday AM, by a series of emails from a number of destinations.  It is quite clear these destinations are spoofed, this much we can be sure of.  The TO line presents a very interesting look into the misunderstanding, or misinterpretation of our language, by people not from North America.  One of our Handlers, Donald S., took a hard look at what is going on, and found some of the names being seen are...

MattiequartermasterSterling
LindseyswitzerlandRichie
AdamicrographyHelton
AdaanodicSorensen
OlgaprototypicHo
BethflubMccabe
LindseydiscoveryBurrell
BrandipreviousSutherland
MallorybrimstoneNava
sabrinaheadquartersingh
LetitiasorghumGold

So it is somewhat apparent that the level of understanding of the English language may not be quite where it needs to be.  Another Handler, Bojan Z., has this tip for protecting a mail server:

"E-mails for non-existent users should be rejected at your MX server. This rejection should happen during the SMTP session (in other words - don't put Exchange there), right after your server received the RCPT TO: command. If everything is configured properly you will not see the e-mail at all. Also, this is very "cheap" for your server - a decent server should be able to reject hundreds of these per *second*."

Add to this that another reader reported a major Spam outbreak about 9PM EST yesterday, this one also apparently from somewhere in Asia.  This one goes to great lengths to avoid the Spam filters, with wording that looks like

".... <h>[a][v][e] alread-y {s}<e>(e)[n] CYTV#'s m^arket i_mpact bef+ore c#limbin`g to  ...."

So we ask of you, our readers, to share any experiences you may be having, where similar events are occuring in your area, and we'll see what we can do to contact the right people and get this stopped at the source.

Microsoft has published their Patch Tuesday advanced notice:

 www.microsoft.com/technet/security/bulletin/ms07-aug.mspx 

and it looks like next Tuesday will be a busy day for many with 6 critical updates and 3 rated as important.
The affected software for the critical updates include:

•  XML core services
•  base OS (several versions)
•  Visual Basic
•  Office (Mac and Windows)
•  Internet Explorer

As always, we'll do our best to help prioritize the updates for our readers in a clear way and will keep an eye out for any issues or additional concerns that arise.

See you Tuesday.

p.s. All of the updates are listed as requiring a restart.

We've received a couple of reports from readers that name-services.com may be under a denial of service attack resulting in DNS being unavailable for a number of domains that host their DNS there.   More info as it becomes available.

Update: (2007-08-10 01:00 UTC) They seem to be back up now.

It has now been a week since I got home from SANSFIRE.  Since we here at the Internet Storm Center are the hosts of this conference, this is the one that usually has the largest contingent of handlers present.  After mostly getting caught up on work at the day job, on behalf of all the handers, I'd like to thank all of you who attended our panel discussion and the talks by Tom and Ed, William and Robert, Adrien, Lorna, Don, and Johannes.  Copies of the slides from some of the talks will be available here shortly, we'll put up another story with the links when they are ready to go.  As we stated during the panel discussion, we can't do what we do without all of you submitting your firewall logs to Dshield and sending us your questions, observations, malware, and most importantly packets.    We hope to see many of you again at future SANS conferences and, in particular, at next year's SANSFIRE.

No, I don't have a witty title in a dead language, but as many of you are aware, I'm constantly on the lookout for useful tools, so I was intrigued when I came across an announcement yesterday that Mandiant had released a free tool aimed at incident handlers, called Red Curtain.  The purpose of the tool is to highlight which files may be suspicious and require a closer look by investigators.  The tool scores files based on some interesting characteristics including entropy (how random the file is, which may be an indication of encryption), indications of packing, specific signatures of compilers and packers, digital signatures, etc.  It certainly isn't foolproof, but is aimed at narrowing the investigator's initial job and would correctly flag anything written by Tom "if Latin isn't your thing, next time I'll try Sanskrit (shouldn't that be the official language of SANS anyway)" Liston.   It sounds like a decent idea.  Has anyone out there tried it, yet?  If so, let us know what you think.

Here they are:

1: Cisco Security Advisory: Cisco IOS Secure Copy Authorization Bypass Vulnerability
2: Cisco Security Advisory: Cisco IOS Next Hop Resolution Protocol Vulnerability
3: Cisco Security Advisory: Cisco IOS Information Leakage Using IPv6 Routing Header
4: Cisco Security Advisory: Voice Vulnerabilities in Cisco IOS and Cisco Unified Communications Manager

Issue 1:
IOS has the capability to act as an SCP server (through the addition of the IOS Secure Copy Server service).  There is a flaw in this service that allows any valid user to access any file on the Cisco device (including device configuration files).

Issue 2:
There is an issue with Cisco's implementation of the Next Hop Resolution Protocol (NHRP) that could potentially cause a device restart or (possibly) code execution on the device.  The issue affects NHRP running at all layers (Layer 2, GRE / mGRE, or at the IP layer).

Issue 3:
Specially crafted IPv6 packets with a type 0 routing header can cause information leakage or a crash of the affected IOS or IOS XR devices. 

Issue 4:
There are issues with voice-related vulnerabilities in multiple protocols [Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), Signaling protocols H.323, H.254, Real-time Transport Protocol (RTP), and Facsimile reception]. These issues affect IOS (if voice services are enabled) and one (SIP related) is found in Cisco Unified Communications Manager.

Mitigating issues:

1: Not much... user needs a login, but after that, it's pretty much game-over.
2: Layer 2 only... attacker needs to be on the same link
3: Only the IPv6 subsystem crashes... IPv4 appears (from the advisory) to still function
4: Uh... not much... patch this 'un now.. The others can potentially wait for testing, this one can't.

If you're doing VoIP stuff w/Cisco hardware, then Issue #4 is a definite must-do... other than that, prioritizing these is difficult because they all are very "configuration-centric."  Sorry...

Ok... for a little fun, I used some pithy Latin sayings as titles for today's diaries...  my thought was that perhaps (perhaps!) it might be nice to... broaden some people's horizons.  I was obviously mistaken.

Bad handler...  baaaaaaaaaaaaaad handler.... no donut!

It appears that someone has kicked the big red Ethernet cable out of the wall over at Cisco.  Currently, attempts to reach their website fall a few hops short.  We'll update if we hear anything...

Rick wrote in with a log snippet showing someone out there actively scanning his webserver for an installation of horde:

2007-08-08 05:49:33 xxxxxx XXXXXXX 192.168.aaa.aaa GET /horde/README
2007-08-08 05:49:32 xxxxxx XXXXXXX 192.168.aaa.aaa GET /README
2007-08-08 05:49:32 xxxxxx XXXXXXX 192.168.aaa.aaa GET /Horde/README
2007-08-08 05:49:32 xxxxxx XXXXXXX 192.168.aaa.aaa GET /horde-3.0.9/README
2007-08-08 05:49:31 xxxxxx XXXXXXX 192.168.aaa.aaa GET /horde3/README
2007-08-08 05:49:31 xxxxxx XXXXXXX 192.168.aaa.aaa GET /horde2/README
2007-08-08 05:49:45 xxxxxx XXXXXXX 192.168.bbb.bbb GET /Horde/README
2007-08-08 05:49:45 xxxxxx XXXXXXX 192.168.bbb.bbb GET /horde-3.0.9/README
2007-08-08 05:49:45 xxxxxx XXXXXXX 192.168.bbb.bbb GET /horde3/README
2007-08-08 05:49:45 xxxxxx XXXXXXX 192.168.bbb.bbb GET /horde2/README

My guess: they're looking to find boxes to exploit with CVE-2006-1491

If you're using horde, make sure that the version you're running is up-to-date.  Not running horde?  Make sure: horde is one of those things that admins will often install to "try it out..."  You might want to take a quick look around, just to be sure.  Nothing worse than getting whacked by your own tools...

Anyone else seeing scanning like this?

(Also, if you haven't picked up on the diary title drift yet, your kindly narrator has decided to try to class the joint up a bit...  Anyone know the source of that quote?)

It appears that several forensics tools are seeing a some... ahem... "attention" of late.  Both the commercial tool "Encase" by Guidance Software and the Open Source tool "The Sleuth Kit" saw a slew of CVE's filed yesterday.

Encase:

CVE-2007-4194 (v 5.0)
CVE-2007-4201 (v 6.2 and 6.5)
CVE-2007-4202 (v EEE 6)

The Sleuth Kit (v <2.09):

CVE-2007-4195
CVE-2007-4196
CVE-2007-4197
CVE-2007-4198
CVE-2007-4199
CVE-2007-4200

Issues mainly seem to be in the parsing of various malformed or specially created files/filesystem images.

About ten years or so ago, I was very much into a BBC television series called 'Bugs' which sketched the lives of a couple of skilled high tech crime investigators. It always dealt with spectacular physical machines (think radio guided cars & airplanes) controlled by computers, because this obviously makes the dry subject a bit more vivid.

Recent history proved them right that there is something more physical out there than OSI layer 1. In many cases, the data we as security professionals need to protect has an impact on the physical lives of others. Nowhere is this division as thin as with SCADA and DCS equipment.

SCADA systems - Supervisory Control and Data Acquisition - control physical processes centrally by collecting data from measurement devices local or in remote locations. Decisionmaking is generally centralized. Distributed Control Systems (DCS) generally control more localized systems in which feedback loops are extensively used between monitoring equipment and actual physical control point.

These types of systems have always been built trying to solve a specific problem. In the case of SCADA, protocols needed to link in often remote power and utility stations to a central coördination point. Obviously, this would result in very different implementations based on geography - SCADA in densely populated Western Europe is something completely as opposed to the United States or Australia. Whereas European telcos can provide a phone link virtually everywhere, even in relatively urban areas Australia may need to resort to radio links.

Some of the many security issues with these systems include:
- Relatively obscure and less well understood protocols. We all speak FTP, SNMP and HTTP, but can we fluently chat Modbus, DNP3 or ICCP ?
- Problems fixed by SCADA don't necessarily change often and are critical and thus difficult to interrupt, resulting in very long patching delays;
- Managing remote sites over legacy links is much more expensive than doing the same over an easy to acquire internet link. Protocols are moving online.
 
During past weekend's Defcon conference, a researcher from TippingPoint discussed how fuzzing would contribute to building more secure protocols. While these research efforts are gradually helping to resolve the first of the above issues, many remain, and these are often rooted in basic security principles such as segregation and least privilege.

As SCADA/DCS security is not something that affects only the main utility providers,but also many industrial environments (ports, transport and factories), here's an overview of some great resources. Mail us if you have other ones to add to the list:

SANDIA Labs' Center for SCADA Security
US-CERT Control Systems Security Program
The NIST has a great draft 'Guide to Supervisory Control and Data Acquisition and Industrial Control Systems Security'
Digital Bond has a great SCADA security blog, publishes IDS signatures as well as a Scadapedia

Now that everyone in the US has had a weekend of fun in the blistering Mojave desert heat, it's time for the Europeans to tag along. Tomorrow will be the start of Europe's largest security conference.

Take some notes on Kyle's Con-fu guide, and perhaps just as important, safeguard the integrity of your hardware and bring umbrellas when you head over to Berlin. The weather report shows we might be in for a little bit of water fun. See you there!

If you're into INFOSEC in Europe, you may also be interested in knowing that the EC, as part of its evaluation of ENISA (the European Network and Information Security Agency) currently has a public consultation open.

There were a handful of new vulnerabilities and tricks announced at the latest cons.  For those who attended, what do you think of them?  What do you think the latest big thing will be?  (resonses to be in a later diary)

For those who didn't make it, remember if you try to masquerade as a normal attendee at DEFCON to play "undercover reporter" to tell the story of how things really are and bypass the media rules they set up, you're likely to torque off quite a few people.  Just ask Michelle Madigan.

--
John Bambenek, bambenek {at} gmail /dot/ com

Couple of days ago I wrote a diary about dynamic JavaScript obfuscation (http://isc.sans.org/diary.html?storyid=3219). The deobfuscation function in this case used the well known arguments.callee.toString() trick in order to prevent modification of the code.

During analysis I confirmed something that I saw previously as well (http://isc.sans.org/diary.html?storyid=1519) – Internet Explorer and Mozilla Firefox have different implementations of this method. The reader who initially submitted the link to the exploit web page, Daniel, did some initial investigation on the implementation of this function.

Yesterday another reader, Ant, sent us his analysis of how Internet Explorer and Mozilla handle this function. Ant did a great job and found out almost exactly what’s going on.

Basically, Internet Explorer always preserves the original text, no matter what’s inside. Mozilla Firefox (the Spidermonkey script engine), on the other side, does some simple optimizations before calling the arguments.callee.toString() method.

Here are Ant’s comments:

The following text is removed before calling the method:

// comment1
/* comment2 */

The following operators are applied before calling the method:

arithmetic (+, -, *, /, %)
bitwise NOT (~)
bitwise shift (<<, >>, >>>)

So, in other words, if you have a variable var test = 2+3; the test I put in the diary would show VARTEST23 in Internet Explorer and VARTEST5 in Firefox.

This, obviously, can cause problems when analyzing such scripts so analysts have to be careful about environments they are working in, as the bad guys can use this to create JavaScript code that will work only in certain browsers (not that we didn’t know that already…). Great job Ant!

--

Bojan

While at SANSFire this past week, I got the chance to chat with many of my colleagues.  One of things we discussed was tools we used to analyze malicious code.  Of particular interest to me is the topic of debuggers.    It appears that really two tools stand out as one of choice.

    1)  IDA Pro from DataRescue.  The offer a free version which has reduced functionality.  But most of those I chatted to recommend using the commercial one or #2.

    2) OllyDbg -  This is the tool that most of my colleagues are using.  It is shareware and seems to be easier to use to some analysts.  As such I would recommend this one.

    3) Immunity Debugger -  Released recently, some are trying this one out as it seems to take the best of command line interfaces as well as the GUI ones and combined it into one package.

So are there other debuggers that you, our readers, like to use when analyzing malicious software?  Let me know which ones and your reason why.  I will add them to this diary over the weekend. 

Thanks to David in the UK who pointed out that Apple has released a new version of  iTunes with Quicktime was released.  I do not see mention of this on the Apple Security Website presently, so this is probably a reliability update.  However, it would probably be best to  update this during your normal update cycle.  

We received one report of a Vonage customer who received an email saying their password was changed. They typed the correct url directly into their browser and attempted to login with their “very difficult to guess random key password” but that failed. He tried the password that was provided via the email he and was able to access his account. He discovered that his last name was changed to something rather derogatory and that his phone numbers had been detached from the system.

If anyone else is seeing similar issues please let us know.

UPDATE:

This came from Ben:
“Not even authorized users (account-holders) of the Vonage service can remove a line from the account without having to call into Vonage customer care.“

From: https://secure.commentworks.com/ftc-SSNPrivateSector/

“The Task Force recommended that these agencies gather information from stakeholders – including the financial services industry, law enforcement agencies, the consumer reporting agencies, academics and consumer advocates – in making this assessment.”

When commenting you should realize that they are planning to publish the comments and contact information associated with those comments. But the only required fields are last name, state and country.

We have information that executive staff at 3 corporations are still being targeted with emails with mailicious attachments that AV vendors are finding hard to identify. The best and ongoing analysis of this highly successful attack is the BBB Phishing Trojan analysis by Joe Stewart of SecureWorks.

The information tends to show the recent attacks started to be detected by AV vendors on 07/31. One of our reports indicates that after the initial malware detection, new and undetected attachment variants were emailed. Malware samples submitted show coverage for at least one sample is still spotty.

One submission email had the following information;

 "This is an automated email that confirms the registration of your complaint case number : CX784486090 filed by your company on 7/29/2007 concerning Online Identity Theft.
   While The Better Bussiness Bureau Online does not resolve individual consumer problems, your complaint helps us investigate fraud, and can lead to law enforcement action.

   ATTACHED you will find a copy of your complaint .Please print and keep this copy for your personal records.
   We use secure socket layer (SSL) encryption to protect the transmission of the information you submit to us when you use our secure online forms.
The information you provided to us is stored securely.

   The form you used to register this complaint is designed to improve public access to the Better Business Bureau of Consumer Protection Consumer Response Center, and is voluntary. Through this form, consumers may electronically register a complaint with the BBB.Under the Paperwork Reduction Act, as amended, an agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number. That number is 382-898.

   Our staff will keep you updated regarding the status of our investigation.

© 2003 Council of Better Business Bureaus, Inc. All Rights Reserved."

One report indicated that downloaded files included winupdate.exe, yhelp.exe
and other temp files McAfee flagged as PWS-FireMing.dll, McAfee's PWS-FireMing.dll write-up has no information.

File names are not reliable in many situations, but Sunbelt had a file named yhelp.dll in a description of recent malware, they listed some downloaded files;

File Traces
%WINDOWS%\ yhelp.dll
update1.exe
yhelp.dll

There was no other useful information on their site.
http://research.sunbelt-software.com/threatdisplay.aspx?name=Trojan-SpyLogsniff.aj&threatid=145086

One sample's analysis at Virustotal;
File Complaint_158684523.doc received on 08.02.2007 18:22:54 (CET)
Result: 10/32 (31.25%)

Antivirus Version Last Update Result
AhnLab-V3 2007.8.3.0 2007.08.02 -
AntiVir 7.4.0.57 2007.08.02 TR/Dldr.Agent.caa.2 Authentium 4.93.8
2007.08.02 W32/Dropper.GGD Avast 4.7.1029.0 2007.08.02 - AVG 7.5.0.476
2007.08.02 - BitDefender 7.2 2007.08.02
Dropped:Generic.Malware.dld!!.EC529233
CAT-QuickHeal 9.00 2007.08.01 -
ClamAV 0.91 2007.08.02 -
DrWeb 4.33 2007.08.02 -
eSafe 7.0.15.0 2007.07.31 -
eTrust-Vet 31.1.5026 2007.08.02 -
Ewido 4.0 2007.08.02 -
FileAdvisor 1 2007.08.02 -
Fortinet 2.91.0.0 2007.08.02 -
F-Prot 4.3.2.48 2007.08.02 W32/SecRisk-ProcessPatcher-Sml-based!Maximus
F-Secure 6.70.13030.0 2007.08.02 Trojan-Downloader.Win32.Agent.caa
Ikarus T3.1.1.8 2007.08.02 Trojan-Downloader.Win32.Agent.caa Kaspersky
4.0.2.24 2007.08.02 Trojan-Downloader.Win32.Agent.caa McAfee 5088
2007.08.01 - Microsoft 1.2704 2007.08.02 -
NOD32v2 2433 2007.08.02 -
Norman 5.80.02 2007.08.02 -
Panda 9.0.0.4 2007.08.02 Suspicious file
Prevx1 V2 2007.08.02 -
Rising 19.34.32.00 2007.08.02 -
Sophos 4.19.0 2007.08.01 -
Sunbelt 2.2.907.0 2007.08.02 -
Symantec 10 2007.08.02 Trojan.Dropper
TheHacker 6.1.7.160 2007.08.01 -
VBA32 3.12.2.2 2007.08.01 -
VirusBuster 4.3.26:9 2007.08.02 -
Webwasher-Gateway 6.0.1 2007.08.02 Trojan.Dldr.Agent.caa.2 Additional
information File size: 34863 bytes
MD5: 134e3045664357da281806fc053076ba
SHA1: 25cfc729de06c88cfcba9a8dfa63b84d6d0c92f1

Readers, SRI International and Georgia Tech have been working on a pretty cool new tool that will quickly locate bot traffic inside a network.  A government/military version of this software has been in use successfully for about a month, and a public version was made available this week.  BotHunter introduces a new kind of passive network perimeter monitoring scheme, designed to recognize the intrusion and coordination dialog that occurs during a successful malware infection.  It employs a novel dialog-based correlation engine (patent pending), which recognizes the  communication patterns of malware-infected computers within your network perimeter.  BotHunter is available for download at http://www.cyber-ta.org/BotHunter/ and runs under Linux Fedora, SuSE, and Debian distributions.

There is also a highly interactive honeynet using BotHunter run by SRI you should look at.  The URL is http://www.cyber-ta.org/releases/malware-analysis/public/.  They are detecting dozens of new infections each day and this site is very helpful in understanding the behavior of the received malware.  Also, it generates a nice list of potentially evil IP addresses and DNS queries.

For both the BotHunter software and the honeynet SRI would appreciate any feedback on ways to improve them.  Contact details are in the download package and on the website.  This is a publicly funded research project, so there is no charge for the software or the use of the honeynet output, however there is a license agreement you have to agree to.

Marcus H. Sachs
Director, SANS Internet Storm Center

Couple of days ago one of our readers, Daniel Kluge, pointed us to a web page with some heavily obfuscated JavaScript code. The operation was typical and consisted of a compromised site that had an obfuscated iframe which pointed to the final web site serving various exploits.

The obfuscation of the iframe was relatively simple but the second stage was more heavily obfuscated with some things we’ve never seen before.

After downloading the JavaScript file it was obvious that all function and variable names are complete random. Further to that, the deobfuscation function used the well known arguments.callee.toString() trick in order to prevent modification of the code (so you just can’t replace the final document.write() call to something else as this will break the deobfuscation function body – attempts such as this one typically throw the function into an endless loop).

The screenshot below shows how the function looked when I first retrieved it.

Now, what makes this new is that the hosting web site generates this code dynamically! Every time you request this web page it will use completely random names for all variables and functions. As the deobfuscation function uses itself to deobfuscate the input, changing variable and function names even causes the payload information to change. Below you can see the beginning of the JavaScript file for two other subsequent retrievals:

(2nd try)

(3rd try)

The reason for doing this is obvious, such heavy obfuscation makes signature based detection much more difficult, if not impossible and it wasn’t surprising to see that 0 anti-virus programs detected this when tested on VirusTotal.

After deobfuscating the payload I found out that it contains the typical set of exploits: the ADODB vulnerability exploit (MS06-014), the QuickTime and WinZIP exploits, AOL SB.SuperBuddy.1, WebViewFolderIcon and the VML Element Integer Overflow . Finally, one new addition is the exploit for the NCTAudioFile2 ActiveX vulnerability (http://secunia.com/secunia_research/2007-2/advisory). While this is an old vulnerability dating from January 2007, a fully working exploit was publicly released in April and what’s worse is that the affected ActiveX control is delivered with dozens(!!!) of popular audio/video applications. This is shifting the patching process from the base OS to client applications which is usually much more difficult for users, especially if those applications don’t support automatic updates so it’s left up to the user to first find out that he has a vulnerable application and then manually patch it.

Browser differences

Now back to the infamous arguments.callee.toString() function.  For those of you who regularly read our diaries, you probably remember that I analyzed a similar obfuscation method back July 2006 (http://isc.sans.org/diary.html?storyid=1519). The obfuscation function back there just used the length parameter to see if anything has been changed (obviously, changing the document.write() call to alert() or something similar will change the function body length as well). I found out that Internet Explorer and Mozilla treat white space differently and this caused the exploit to fail in Mozilla.

Daniel had problems deobfuscating this function initially and the reason why that happened wasn’t clear immediately because the deobfuscation function in this case does this:

var o3b522f35=arguments.callee.toString().replace(/\W/g,"").toUpperCase();

this call converts the function body to upper case and then strips all white space (\W matches all non-word characters) so the fact that Internet Explorer and Mozilla don’t calculate white space the same can’t matter here.

However, Daniel used Rhino while debugging it while I was playing with Windows debugging capabilities so we knew it had to be something related to the browser wars again.

After some investigation, Daniel found out that there are other inconsistencies between Internet Explorer and Mozilla when using the arguments.callee.toString() function. You can also test your browser with this bit of JavaScript code:

<script type="text/javascript">
<!--
function func(){
var l = arguments.callee.toString().replace(/\W/g,"").toUpperCase();
var failme = 00001;
alert(l.length.toString() + ' Func: ' +l );}
func(‘blah’);
//-->
</script>

This is a simple test – it calls the same function as the deobfuscation code and just declares one variable called failme with the value of 00001. If you want to test this, go to http://handlers.sans.org/bzdrnja/test.html.

Different browsers and different results:

• Safari: 93
• Firefox 2: 94
• Internet Explorer 6 and 7: 98

Daniel’s observations were:

• For some unknown reason Safari ignores “g” from the replace call. Why would they do that is not clear but it looks like a bug to me (“g” is definitely a word character).
• All browsers but Internet Explorer strip leading zeros on integers so they treat variable “failme” as 1 when counting the number of characters; Internet Explorer actually counts 5 characters there.

This was the main reason why the deobfuscation function failed in Rhino which uses Mozilla’s JavaScript engine (so it stripped leading zeros from variables). Browsers are certainly strange beasts …

--

Bojan

Several ISC readers told us about an article in the Wall Street Journal titled Ten Things Your IT Department Won't Tell You that seems to describe several ways of violating corporate IT policies.

The article points out that often "it's just easier to accomplish certain tasks using consumer technology than using the sometimes clunky office technology our company gives us. ... There's only one problem with what we're doing: Our employers sometimes don't like it. ... To find out whether it's possible to get around the IT departments, we asked Web experts for some advice."

I was troubled by the perspective this influential business publication is taking on IT policies. Surely, many employees know about services such as YouSendIt for transferring files to home systems, web versions of chat clients that don't require installation, web proxies for bypassing website filters and other handy tools that can often violate corporate IT policies. Unfortunately, the tone of the article almost encourages the employees to look for ways of bypassing such policies--an action that can be detrimental to their employers and their careers.

ISC reader Thomas Schmitzer told us he was "amazed at this article." He wrote, "We spend years training our users to follow good security practices and a 'trusted' source of information for executives and management writes this article. ... Yet it ultimately tries to convince our users that forwarding sensitive company information to free web based storage solutions, installing any application, surfing porn, or forwarding your email to a free third party service is perfectly acceptable."

ISC reader Jeff said he was "very surprised that this is published in such a mainstream news outlet.  What's next, an article on how to help terrorists launder money and not get caught?"

The article did list the risks associated with attempting to violate the policies. "To find out the risks, we talked to three experts who make a living helping IT departments make the rules and track down the rogue employees who break them."

ISC handler Swa Frantzen mentioned that the article left out one big risk: Violating the company's policy may be a reason for dismissal. He pointed out that IT staff can use the article as a way of raising awareness for the policies that exist at the companies, and the sanctions associated with violating the policies. He also emphasized the need to develop IT practices that support the mobile nature of the modern workforce. "We will need to evolve from the medieval walled city model we all build with our current security technology to a modern grid pattern city, where the people live in the suburbs and are mobile." (Swa offers a presentation about adapting the IT paradigm to embrace mobility instead of blindly banning it.)

Was the article a good way to cultivate such a discussion? Was the Wall Street Journal's perspective out of line? Take a look at the article and judge for yourself.

-- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

On Tuesday Apple released 3 major security update batches:

• APPLE-SA-2007-07-31 Security Update 2007-07 fixes 45 security vulnerabilities in Mac OS X (various applications and services are affected). If you run Mac OS X you definitely want to install this since a lot of common packages are affected. You can find more information at http://docs.info.apple.com/article.html?artnum=306172.

• APPLE-SA-2007-07-31 Safari 3 Beta Update 3.0.3 fixes 4 security vulnerabilities in Safari 3 Beta. All 4 vulnerabilities affect Safari on Windows XP or Vista and 3 of them also affect Mac OS X. More information at http://docs.info.apple.com/article.html?artnum=306174.

• And finally, APPLE-SA-2007-07-31 iPhone v1.0.1 Update fixes 5 security vulnerabilities in iPhone. As some of them are pretty bad (arbitrary code execution after viewing a maliciously crafted web page) you also definitely want to install them, if you’re using your iPhone for web browsing. More information at http://docs.info.apple.com/article.html?artnum=306173.

As an organization's IT security practices mature, it gets better at protecting its network perimeter systems: the patches get applied more regularly, the firewall rules become more restrictive, the OS gets locked-down more rigorously. Even at such companies, authentication systems often lag behind. If the employees, partners, customers, vendors need to remotely access an application with logon screen that requires a password, two things will often hold true:

1. The application will assist the user in remembering the password.

This may involve emailing the password to the user's email address. If you're an attacker, you will try gaining access to that inbox to retrieve the password.

The application may also present the user with a "secret question" picked by him or her in advance. Unfortunately, such questions often have easy-to-guess answers. Favorite color? Blue. Favorite month? March. It doesn't take many tries to go through likely answers to such questions. Even if it doesn't work for a particular user, it may work over a large population of targeted users. In many cases, answering such questions may not trigger the account lock-out mechanism.

Finally, the application may provide a different response to a valid username than to an invalid username. For instance, if the username and password are both incorrect, it might say "Access denied." But if the username is correct, it might say "Password incorrect."

Make sure your users recognize the importance of protecting access to their email boxes. Help them by protecting the email servers. Also, consider implementing complexity requirements for answers to secret questions or give users a few secret questions to chose from, but omit common questions such as those about color. Finally, don't provide too much information in response to a failure to logon successfully.

2. The user will select an easy to remember and easy-to-guess password.

There are too many passwords to remember. Of course, users will try to select those that are easy for them to remember. Much has been said about encouraging users to select hard-to-guess passwords, so I won't repeat the discussion here. Once concern to keep in mind is that if your selection requirements are too strict, or if the users need to change the password too often, they will still find a way to beat the system. They may write the passwords down or use the same password across multiple systems/sites/organizations.

Also, the use of default passwords plagues many environments. If possible, require that your users change the pre-assigned password after first logging on to the system, and make sure the default passwords you assign are difficult to guess.

Automatically locking an account after several failed logon attempts will address many of these concerns, but sometimes it's not a feasible option. We may be concerned about denying service to our customers or executives. Or we may not have the staff to deal with unlock-my-account requests. A nice compromise is often a mechanism that locks the account for a few minutes, then automatically unlocks it. This can slow down the attacker's guessing tactics, yet allow the legitimate user to login after a brief waiting period. Implementing CAPCHA to discern between human and non-human users of your site can be effective as well to discourage automated password guessing.

Include Remote Password Guessing in Your Assessments

If your security assessment procedures do not already include remote password guessing, consider adding this task. The steps that come to mind include:

• Identify publicly-accessible services/applications that request username/password credentials and attempt bypassing them via manual guessing. Keep an eye out for account lock-out mechanisms.
• Query Google and examine your public website to identify possible usernames. (The Backtrack CD has some nice tools for that.)
• Compile a list of possible passwords the users might use, accounting for your organization's location, name, and industry-specific terminology. Add common names and words like "passsword" to the list. I find that having a short, but intelligently-crafted list is more effective than using a 100KB dictionary file (the long file often takes too long to cycle through remotely).
• After trying the manual route, make use of an automated password guessing tool to see whether it can guess logon credentials using the short password list you put together. Hydra is an excellent tool for this task. It's free, fast, and effective, even though it's poorly documented. (Anyone feels like writing a comprehensive guide to using Hydra, or pointing us to one that already exists?) Hydra is included on the above-mentioned Backtrack CD, and supports most of the protocols you're likely to encounter in the field.

Do you know of any lists that include passwords that actual non-IT users have used? We know of lists that include common passwords of IT staff, but we're looking for one that would apply to non-IT users. Not a dictionary file of potential passwords, but the words real users have used as passwords. If you know of such a list, let us know.

Update: A follow-up to this diary is available here as a separate note.

 -- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

We received several responses to the earlier diary about remote password guessing.

Melvin Klassen highlighted an important technique for mitigating the risks of remote password guessing: monitoring the logs on servers that authenticate users, such as POP, FTP, IMAP, web mail, telnet, and SSH. Melvin suggested counting the number of failed logon attempts and the number of logon attempts per source IP address, so that you can look for spikes and trends that may signal an attack.

Gabriel Friedmann and Mark Senior reminded us of the large-scale phishing attack on MySpace, which allowed researchers to analyze password usage patterns. According to several reports (see 1, 2, 3), the most common passwords included:

password1, abc123, myspace1, password, blink182, qwerty1, fuckyou, 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1, monkey, cookie123, iloveyou, miss4you, password19, clumsy, sassy, pablobob, mobbie, fuckyou1, tink69, gospel, terrete, monster7, marlboro1, bitch1, flower

Daniel Cid told us about an SSH honeypot he set up to monitor SSH brute force attempts and record the passwords used by them. The passwords he observed included:

1qaz2wsx, 1q2w3e4r5t6y, 1qaz2wsx3edc4rfv, qazwsxedcrfv, michael, work, maggie, print, 123456, internet, mobile, windows, superman, 1q2w3e4r, network, system, 123qwe, manager, querty, www, coder, 123123, 1234567890, info, tony, bill, flowers

Nathaniel Hall described a system he uses to crack local password hashes using John the Ripper. The examples of common passwords that he encountered include:

Cobra1, Dragon1, Travis1, Ferry1, Password8, Ynattirb1, Iloveyou5

Thanks to everyone who wrote in.

-- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com