Last Updated: 2013-01-03 22:27:29 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
In december 24 2012, google detected a non-authorized certificate for the google.com domain. After investigations, it was confirmed that Turktrust Inc incorrectly created two subsidiary certificate authorities: *.EGO.GOV.TR and e-islam.kktcmerkezbankasi.org. The first one was used to create the fraudulent google.com domain certificate detected by Google Chrome. This is a big problem since intermediate CA certificates carry the full authority of the CA and therefore they can be used to create a certificate for any website the attacker wish to impersonate.
As a result of this problem, Mozilla is revoking starting January 8 the trust to both certificates, Microsoft issued the security advisory 2798897, publishing updates to revoke the fake google.com certificate and the two intermediate certification authorities and Google revoked same certs in Google Chrome in december 25 and 26 2012 updates.
SSL and X.509 has been proven weak as a standalone security control and definitely should be used with other strong authentication controls like One Time Password tokens. You can use other vendors like Vasco, Safenet and, of course, RSA. Despite all attacks and intrusions from previous years, they are still a very good reliable solution.
Last Updated: 2013-01-03 09:39:29 UTC
by Bojan Zdrnja (Version: 1)
Last week at the CCC conference in Hamburg, my colleague Luka Milkovic presented his work on memory acquisition tools. The presentation’s PPT is available at http://events.ccc.de/congress/2012/Fahrplan/events/5301.en.html
Since memory acquisition is becoming increasingly popular in any incident forensics, I think it is very important for every incident handler to be aware of deficiencies in this process.
So how does the memory acquisition process work? Once executed, all memory acquisition tools (see slide 17 on the presentation) install a driver to get kernel access through it and then start reading memory and either dumping it to a file or over the network.
Now, the above mentioned slide 17 shows another interesting thing – you can notice that all memory acquisition tools (except Win32DD) create buffers in user space. In other words, it is relatively simple for an attacker to inject into these tools and mess up with their output! Further, apart from Win32DD (which can also be attacked, but it is a bit more difficult) all other well known memory acquisition tools are doing it wrong.
There have already been other presentations about attacks on memory acquisition tools, so Luka created a PoC tool (should be released soon) called Dementia that allows one to hide any currently active process. The tool monitors buffers containing memory addresses to be written and if a memory address of a process that is to be hidden is detected, the tool simply overwrites that memory space with zeroes.
The Dementia tool runs completely from user mode and requires no kernel drivers – this allows it to subvert all those most popular memory acquisition tools that store buffers in user mode (FTK Imager, MDD, Memoryze, Winen ...) – the only requirement are admin rights since the tools need them as well. Keep in mind that Win32DD can be attacked as well, but it requires a kernel driver since the attacker needs to be able to modify kernel buffers.
So what can we do? Not much unfortunately. As the first step the tools mentioned above should be fixed to utilize drivers correctly (i.e. all buffers in kernel mode, and not user mode). We could also use other acquisition methods such as memory dumps over Firewire, but that might be difficult with servers since they normally do not have Firewire interfaces. As Luka also mentioned, we could rely on crash dumps since they are much more difficult to tamper with (but not impossible).
And of course – if nothing else, just be aware that we cannot (completely) trust acquired memory images.