InfoSec News

Today the Dutch government released a letter signed by the minister of internal affairs and the minister of security and justice addressed to their house of representatives. The letter has as attachment an interim report by security company Fox-IT's CEO who has been heading an audit at DigiNotar.
The report itself is well worth a read [in English].
For those on limited time, some of the most interesting news and observations:

The defaced pages dating back to 2009 found by F-secure appear to have been copied during a re-installation of the web server in August.
The OCSP server's working at DigiNotar has been reversed since Sept 1st. Normally these servers respond with good to all certificates except those on the CRL (a blacklist). The OCSPnow operates in whitelist mode: it will call all unknown certificates signed by DigiNotar as revoked (a whitelist).

Hence we need to make sure to use the OCSP server to validate DigiNotar certificates -should we want/need to- and not rely on the published CRLs anymore.
DigiNotar operates multiple CA servers, all of them seem to have been compromised by the hackers and having had Administrator level access, including those used for Qualified certificates and PKIOverheid certificates.
Some of the CA servers have had parts of their logs deleted, leading to DigiNotar not knowing what certificates were issued.
Hacker tools including CainAbel as well as specialized dedicated scripts -written in a language specific to the PKI environment- were found. Intentional fingerprints left in one of the scripts links it back to the Comono breach.
There is a list of 6 CAs that have been found to have emitted rogue certificates
There is an incomplete list of 24 additional CAs that have had their security compromised but have not shown to have emitted rogue certificates
The rogue certificate for *.google.com detected in the wild was verified against the DigiNotar OCSP service from August 4th till it was revoked on August 29th. 300 000 different IP addresses verified that certificate. More than 99% of those addresses trace back to Iran.

The report notes that those who had their connections to gmail intercepted could have exposed their authentication cookies and that would expose their email itself, and through that also allow access to reset functionality of other services such as e.g. facebook. It is recommended that those in Iran logout and change passwords.
2 certificates were found on the PKIOverheid and Qualified environment that cannot be related to a valid certificate.Yet the logs appear to be intact and do not show rogue certificates created.
There is a list of failures of basic best security practices that have clearly not worked, implemented badly or were omitted. Yet the servers are housed in a tempest protected room.
The hackers breached the systems possible June 6th already, this got detected by DigiNotar on June 19th, The rogue certificates were created in July and the first time the *.google.com certificate that was detected in the wild was presented on July 27th to the OCSP server. Yet it took till DigiNotar was notified by govCERT.nl before they revoked the certificate.

The letter [in Dutch] summarizes the report itself, and contains some additional information not in the report that is of interest:

There is now an inquiry into DigiNotar for possible responsibility and negligence
The search for the hackers continues
DigiNotar filed an official reported the incident on September 5th
They suggest leniency and agreements for those cases where the revocation of trust in DigiNotar leads to problems such as with the timely filing of tax information in the Netherlands

--

Swa Frantzen -- Section 66 (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Microsoft said that a digital certificate stolen from a Dutch company could not be used to force-feed customers malware through its Windows Update service.
 
GTK+ Multiple DLL Loading Arbitrary Code Execution Vulnerabilities
 
Apache Tomcat 'MemoryUserDatabase' Information Disclosure Vulnerability
 
Elite Gaming Ladders 'ladders.php' SQL Injection Vulnerability
 
There has been quite some coverage about Bitcoin in last couple of months. For those that did not pay attention, Bitcoin is a crypto currency that is decentralized and works in a peer-to-peer network. It is a pretty fascinating project by a Japanese researcher (maybe his real identity has not been confirmed) and in case you are interested in it you can find some information at http://www.bitcoin.org/.
Some background
Couple of weeks ago I started doing some research on how Bitcoin works. I found it amazing that for a scheme so wide spread (there are probably tens of thousands, if not hundreds of thousands of active users) that not a lot of technical documentation is available, apart from Satoshis paper available on the main web site, which does not really go into implementation details.
One of the features of Bitcoin that gets mentioned quite often is its anonymity. Basically, Bitcoin has a digital wallet which allows you to process incoming and create new transactions. A user has one or more (preferably many) public/private key pairs which identify him. In the Bitcoin system, when you want to send Bitcoins to someone, you sign a transaction that is taking some of your Bitcoins (which you received through a transaction or mining more about this later) to the destination address. All addresses are unique 40 digit hexadecimal numbers (RIPEMD160(SHA256(public key)) with some extra conversion to Base-58.
You can have as many as you want of these and this is one of the ways for Bitcoin to allow anonymity. Since you can use a different public/private key pair for every transaction (and you can transfer Bitcoins to your other addresses) it can be difficult (but not impossible) to track the owner. One thing to keep in mind is that all Bitcoin transactions are public every node knows everything about every transaction.

There is some interesting research about tracking Bitcoin owners and Dan Kaminsky posted some good ideas at this years Black Hat.
How do you get new coins?
In order to confirm a transaction, it has to be included in a block. A block (https://en.bitcoin.it/wiki/Blocks) contains a hash pointing to a previous block (so the blocks are chained, this is what makes spoofing exponentially difficult with generation of more blocks), some other data and a Merkle root hash of all transactions validated by this block.
Now comes the best part all this data is hashed together (SHA256(SHA256(block)) and the resulting hash has to satisfy some requirements. The requirements state that the resulting hash has to start with a certain number of zeros. So, for example if the resulting hash has 7 leading zeros it is valid. How do we find a valid block? Besides the payload a nonce is embedded to which gets constantly changed.
Simply speaking, the node that is generating the block brute forces all possible values until it finds a valid hash that satisfies the previously mentioned requirement. As you can see, this is an extremely complex task that, with fastest gear (and Im talking about loads of GPU cards) can take days if not months.
So a logical question is: why would anyone do that? The node that finds a valid block (mines it, in Bitcoins terminology) gets awarded (currently) 50 Bitcoin. With 1 Bitcoin being around 7.3 USD currently, this means that for each solved block the node that found it gets ~350 USD. Sounds good?
Besides this, the solver also gets a certain fee for transactions that have been validated so in reality more than 50 Bitcoin will be awarded to the solver (this is the incentive to keep solving the tasks even after all Bitcoins have been awarded).
Finally, another important thing about blocks is that it should take approximately 10 minutes to solve a block. The network itself measures how long it took to solve 2016 blocks (it should be about two weeks) and modifies the difficultly accordingly (so if more people start solving this, the difficulty gets higher).
My CPU your CPU
There are legitimate groups of users that join so called mining pools in order to find new valid hashes. The pool owner runs a special algorithm that sends partial tasks to all nodes participating in mining. Different pools have different rules, but today it is common that they share received Bitcoin between participating nodes, depending on how much each node has participated.
There are many open source, free Bitcoin mining programs that are specially optimized for GPUs.

And imagine this who has the most CPU power in the world (except government agencies)? Bot owners of course.

In other words, it was to be expected that bot owners will start playing this game after theyve stolen all valuable data off a machine, why wouldnt they use its resources (CPU, GPU and power) to mine Bitcoins and make some extra cash (which even looks anonymous!).
Couple of months ago we started first seeing malware stealing Bitcoin wallets (basically doing transactions to their owners) and lately Bitcoin mining pools used by malware started being increasingly popular.

Modus operandi is typical here malware drops legitimate bitcoin mining executables which join a pool operated by the botnet owner. In most cases Ive seen so far they use standard protocols so be sure to check the 8333 TCP port. Bitcoin also uses IRC for initially finding other nodes so it might easily make your IDS/IPS shine like a Christmas tree (even if a legitimate user started it).
Perfect extortion weapon
Just about when I was to finish this diary (which will probably be only first in the series about Bitcoin), we received a very interesting e-mail from one of our readers who wanted to remain anonymous.
He received an e-mail from an attacker asking him to pay 100 Bitcoin to a certain address or his site will be a target of a DDoS attack. Weve seen such extortion e-mails many times in the past (as always do not pay) but using Bitcoin is a new twist.
As I previously wrote, while it is not 100% anonymous, it can be very close to this and, depending on how careful the attacker is, it can be very difficult to trace the transaction.
As Bitcoin is gaining more attention it will be interesting to see what future will bring. Rest assured that we will keep an eye on it.
--

Bojan

INFIGO IS
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

Infosec Technologies shortlisted for 2011 Computing Security Awards
Online PR News (press release)
Online PR News – 05-September-2011 –Infosec Technologies, a leading information security solutions and services reseller, has been shortlisted for this year's Computing Security Awards. Over 70 companies were entered for the IT Security Reseller of the ...

 
Pidgin Denial of Service and Security Bypass Vulnerabilities
 
libmodplug Multiple Buffer Overflow and Off-By-One Vulnerabilities
 
A Turkish hacking group managed to tamper with Internet addressing records over the weekend, redirecting dozens of websites belonging to companies including Microsoft, UPS and Vodafone to a different web pages controlled by the hackers.
 
Cerberus FTP Server Remote Buffer Overflow Vulnerability
 
BisonFTP Server Multiple Remote Buffer Overflow Vulnerabilities
 
Apple QuickTime PICT File CVE-2011-0257 Stack Buffer Overflow Vulnerability
 
Oracle officially released Java 7, including some security updates and several new features and enhancements. Thanks ISCreader Alex for notifying us about it.
The new Java 7 version coexists with the latest Java 6 Update 27 version and is available for download from the Oracle web site, http://www.oracle.com/technetwork/java/index.html, and still makes use of different installers for the 32 and 64-bit versions for all operating systems (Linux, Solaris Windows).
As you can see in the release notes, the main security enhancements affect the JSSE(Java Secure Socket Extension) and TLScommunications, including TLSIguess this is the intended behavior as this is a major release. From a security perspective, if Java 7 is installed (using Windows as the sample platform)on a system that already has Java 6 installed, both versions will remain, so if you only want to run the latest version, ensure you uninstall any previous versions (as we had to do in the past but with the same major release) and do not leave vulnerable Java 6 releases around.
Considering Java is one of the most targeted pieces of client software today, be ready for future updates on both, Java 6 and Java 7 in your ITenvironments (perhaps Java 6u28 and Java 7u1), and plan in advance how to manage them.
UPDATE 1: Let's clarify this diary post title a little bit based on txISOcomment (thanks!). If you consider Java to be officially released only when it is available at java.com, then Java has not been officially released yet (see quote on 3rd comment below). However, if you consider that Java 7 is available out there, not only in its JDK version (what Iconsider the version for developers), but the JRE(Java Runtime Environment)version too, then IMHO, it has been released - although only at oracle.com. Besides that, if you are old Java school and go to the old java.sun.com, you will be redirected to the oracle.com page where Java 7 is available to the public. For our ISCaudience, officially or not, get ready for Java 7 as soon as possible: it is out there :)
----

Raul Siles

Founder and Senior Security Analyst with Taddong

www.taddong.com (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Internet Storm Center Infocon Status