1024-bit RSA encryption is used around the world to protect web servers and other devices using OpenSSL.  In the past only the RSA 768-bit version has been crackable using brute force methods with 1,500 years of processing time.  Recently computer scientists from University of Michigan claim they are able to crack OpenSSL  using a full 1024-bit RSA encryption by fluctuating the voltage on the servers power supply.  Although the scientist say this type of attack can be easily prevented by changing the error-checking algorithm, they claim this type of attack is repeatable and consistent and able to be performed in just over 100 hours.  Exponentially quicker than previous successful attacks on weaker key lengths.

Because direct access to the servers power supply is required to perform this attack, it is unlikely this vulnerability will be exploited in the wild on most servers.   Many consumer devices like MP3 players, BluRay players, and mobile phones use RSA encryption to protect intellectual property.   Consumer devices on the other hand are easy to gain physical access to and manipulated to gain access to intellectual property or private data.

More information can be found in their white paper (PDF) that will be presented next week in Dresden at the Design Automation and Test in Europe conference.

OpenSSL has acknowledged this vulnerability and are currently working on a patch.

Author: Christopher

Many agree Adobe has never responded to security vulnerabilities in their popular products quickly. Known vulnerabilities would take weeks and in some cases months before being addressed. Most recently in February Adobe confirmed a known vulnerability in their Acrobat PDF software and admitted the vulnerability is actively being used by hackers. Brad Arkin, Adobe’s director for product security and privacy mentions this event is what prompted a new security practice.

Adobe has started reviewing the code in Adobe Reader and Adobe Acrobat products and is identifying “at-risk areas” that will be addressed and ultimately re-written. “We’re going to broadly look at the whole application, but focus on at-risk areas, where we’ll do threat modeling, static code analysis and look for potential vulnerabilities,” said Arkin. “We’re going to do a lot more pro-active work,” he promised. “We want to shake loose vulnerabilities.”

Arkin promises a regular patching cycle and in fact will deliver patches the same day as Microsoft. Although their patch cycle is quarterly, not monthly, the patches will be delivered the second Tuesday of the month. This schedule has not officially started.  Arkin also mentioned JavaScript will not be disabled by default in future builds of Adobe Acrobat products.

More information on Adobe Acrobat’s new security initiative can be found on Adobe’s Asset blog.

Author: Christopher

Another serious vulnerability in Adobe Acrobat is making its way around the Internet.  So far testing has confirmed  the vulnerability in Adobe Acrobat 8.1.0, 8.1.1, 8.1.2, 8.1.3, and 9.0.0.  This affects the latest version of both 8.x and 9.x versions of Adobe Acrobat.  Although the exploit is not JavaScript based, it is trigger via JavaScript, so for now disabling JavaScript will help mitigate this threat.  Adobe has acknowledge the vulnerability and has plans on releasing a patch around March 11th.

For now, if you want to disable JavaScript in Adobe Acrobat, you can go into the Edit menu and select preferences.   Under preferences you will see a JavaScript option group, from there you can un-check the box to disable JavaScript.

This can also be disabled via the registry or a GPO under HKEY_CURRENT_USER

Author: Christopher

As Dan Kaminsky recently demonstrated at the Black Hat conference in Las Vegas, the DNS security flaw presents a serious vulnerability.  In case there was previously any doubt, he showed just how dangerous to internal networks and the internet at large it is to run un-patched DNS servers.  Even with the patch, the exploit is still possible, just extremely difficult.

The vulnerabilities are not limited to the web, but affect every type of internet service and traffic, including IM, telnet, email, and usenet.  Every protocol uses DNS servers to locate and communicate with between servers and client computers.  Even HTTPS (web sites using SSL – Secure Sockets Layer) would be affected because the Certificate Authorities who authenticate the certificates rely on DNS.  Note that all major CAs have patched their DNS servers, but of course many sites use self-signed certificates.

Some services have already fallen prey to this exploit, with AT&T being the first publicized victim.  Actually, the victims were the people whose requests were directed to a bogus Google search site because of an un-patched AT&T DNS server.  Fortunately, the bogus site only hosted code to auto-click the adsense advertisements, creating extra revenue for the perpetrators.  It could have been worse, if for example the site had been created to infect visitors with drive-by infections or inducements to download crimeware.

The picture is not completely bleak.  Thanks in part to Kaminsky’s presentation, more organizations are taking the threat seriously and patching their servers.  Also, any SSH-based connections which had been made at least once prior to the exploit would warn users if new connection attempts were made to bogus sites, because of the way SSH keeps digital fingerprints of remote hosts.  So Secure Shell, sftp, scp, and SSH-based VPNs would at least warn users about the change in fingerprints, or deny the connection altogether, depending on the local configuration.

For anyone wishing to know whether or not the DNS server he or she is using has been patched, Dan has published an online DNS checker on his blog at http://www.doxpara.com/.

Author: Christopher

There are currently known vulnerabilities with DNS servers across all implementations.  These vulnerabilities are not vendor specific, in fact all DNS distributions are vulnerable.  I recommend all organizations develop an action plan immediately to identify and patch all DNS servers, applications, and clients on all networks in your control.

These vulnerabilities expose vulnerable DNS servers to DNS cache poisoning, this potentially can effect proper email delivery and what website you actually visit when entering a URL into a browser.

DNS specifically calls for 16 bit transaction ID field, which would require 32,768 “guesses” to predict the ID.  Many implementations use a smaller number of bits, and thus would require considerably fewer guesses.

US-CERT has an excellent write up on this vulnerability here.

You can find patch specifics for Microsoft here.

If you are running BIND 8, there is currently no solution and no plans to fix this problem for this platform, it is highly recommended to immediately look at upgrading to BIND 9.

If you only apply one patch in 2008, this should be it!

If you are using DNS from your ISP, you may still be vulnerable!

To assist organizations in containing this issue, I put together a few actions steps to get everyone on track.

1. Identify all DNS servers on your network and any networks you are responsible for.  To be sure, you may want to run a port scan for anything listening on UDP port 53.
2. Identify vendors responsible for each and every DNS server found from step 1.
3. Refer to US-Cert for links to each vendor to the appropriate patch documentation.
4. Patch all Servers.
5. Repeat for all DNS Clients, although these patches are more focused on DNS Servers.

It is highly recommended all servers be patched before the Black Hat convention on August 6th when more information will be disclosed.

UPDATE:

You can check your upstream DNS Servers here:
http://www.doxpara.com/

Author: Christopher

Almost 300,000 web sites hosted with Internet Information Services are infected with a new malicious malware according to PandaLabs. By injecting SQL code in all pages hosted on the same IIS server, this vulnerability allows hackers to inject SQL code and redirect the visitor to a malicious site. The malicious page scans the visitors machine to find ways to compromise the visitors machine. Exploits are then downloaded and used to infected the redirected visitor based on the information found on the scan.

If your site is hosted with Internet Information Services it is highly recommended you check to see if your site is compromised. To check if your site is compromised, search your source code for the following IFRAME reference: “<script src=http://www.nihaorr1.com/1.js>”. If this IFRAME reference is found, remove them immediately and notify your IIS admin right away.

Author: Christopher