The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1
Latest posting
By rating
By popularity

30 Dec ASP.NET Holiday Patches Kurt Baumgartner

24 Sep The SSL Sky is Falling? Kurt Baumgartner

05 Aug Blackhat USA 2011 Talks Kurt Baumgartner

20 May Hack in The Box Security Conference 2011 Amsterdam / NL Stefan

18 Apr Infiltrate 2011 and Offensive Security Kurt Baumgartner

22 Jul Different x86 Bytecode Interpretations Georg 'oxff' Wicherski

Join our blog

You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.


It's the end of 2011 as we know it, and Microsoft feels fine finishing out the year with a handful of out-of-band holiday patches. This round is important not because the vulnerabilities directly impact massive numbers of customers and their online behavior on Windows laptops, tablets, and workstations, but because ASP.NET maintains vulnerable code enabling easy DoS of hosting websites, authentication bypass techniques, and stealth redirections to other websites (most dangerously those sites hosting phish and hosting client side exploits and spyware). All of this could curdle your eggnog in the coldest of weather.


With headlines like "New cyber threat compromises financial information - Experts say new threat could affect millions of sites", you would think that the trust model of the internet is finally crumbled.

Following an hour long Friday evening wait for the demo, the Ekoparty demo for the SSL hack was staged. And it was interesting that the attack succeeded in cracking the SSL confidentiality model as implemented by the Mozilla Firefox browser when communicating with paypal.com web servers over https. At the same time, it seemed to be an impractical exploit targeting a weakness that was fixed three months ago in Chromium source code.

Also of note, is the fact that the attack has been well known for almost 10 years, it's just that there hasn't been a practical exploit implementing the attack. And that they refined their blockwise attack model far better than previous chosen-plaintext attack models, making it more effective than prior attacks.

So there seems to be another good security reason to use Google's Chrome browser, for those of you highly sensitive to security issues. Also interesting were some of the tricks they used to make it work. While they couldn't get it to work in pure javascript or flash, they implemented the exploit in a Java applet and attacked the stream between Firefox and https://paypal.com. The "tricks" they used to bypass "Same Origin Policy" with Java were surprising, and they came up with the entire stolen session cookie with which to log in to paypal.com as the victim over http in under three minutes. While I am sure that the other browser vendors will update their CBC encryption routines to better randomize their IV and overcome this attack as suggested almost ten years ago, one could use Chrome and maintain secure communications in regards to this exploit. To me, this exploit is a low risk one because of its impracticality. Whether they properly disclosed their work to all browser vendors, giving developers plenty of time prior to disclosure remains a question to me, but they did contact at least the Chrome team. Interesting research and impressive effort implementing a difficult to work concept certainly. These guys know crypto and communications technologies. But the sky has not fallen. Yet.

For related technical information, and thoughts from relevant developers and researchers, please check out my "Related Links" list to the right side of the post text. I try to be thorough in my selection.

UPDATE(9/26): Microsoft advises that they are investigating the matter for their Internet Explorer browser customers, stating that the issue is low risk anyways, "Considering the attack scenario, this vulnerability is not considered high risk to customers". Perhaps they were one of the browser vendors that were not contacted about the vulnerability.

Comment      Link

Blackhat USA 2011 wraps up and the Defcon conference starts today. There is a little something for everyone in security here. Aside from the contests, networking, meeting folks in the industry and putting faces to names, I thought that the briefings had two fantastic talks.

The first of the two focused on breaking out of the official virtualization platform for Ubuntu and Red Hat, Kernel Based Virtual Machine, or KVM. The second focused on the massive challenges that exist in the current SSL infrastructure, or PKI.

KVM is gaining traction in the virtualization and cloud space, but there hasn't been public security research efforts on this platform like there has been with VMWare and Xen. Nelson Elhage pointed out that the adoption of the platform will bring with it increased scrutiny, and that parts of the existing code is a "gold mine" for vulnerability hunters. He methodically reviewed CVE-2011-1751, and delivered the goods with an exploit demo implementing not ROP to evade DEP, but an in-memory timing chain fragment reuse technique. While the cloud has been under attack with multiple known exploits for Xen and VMWare from Invisible Things Lab and Immunity, Elhage pointed out that virtualization does not provide a reliable layer of security through isolation on its own.

Probably the best speaker at the conference this year was Moxie Marlinspike. His presentation was a talk about trust, and the massive breakdown of trust related to SSL this past year. He reviewed the ridiculous antics around the certificate authority Comodo hack, how cemented these organizations are in the infrastructure in the face of the repeated intrusions and mistaken certificate issuance, and what is missing from the infrastructure. To help overcome these challenges, he proposed adding "trust agility" to the infrastructure. He meant two enhancements need to be added to the trust model:

  1. a trust decision can be easily revised at any time
  2. individual users can decide where to anchor their trust

He reviewed why DNSSEC would continue to centralize trust in its model, and proposed a new implementation of certificate handling used in encrypted communications with web servers, where software clients contact "Notaries" for certificates to maintain encrypted communications, instead of letting web sites contact CAs to validate them. All of these ideas and the implementation of the concepts are available as a part of his Convergence project website. Details are provided there and Firefox users can download a plugin there.

Comment      Link

Since yesterday I've been attending the annual Hack-in-the-Box Quad-Track Security Conference in Amsterdam/NL. There's a very nice and open atmosphere here at the conference, besides the beautiful city of Amsterdam.

First, Joe Sullivan (CSO at facebook), held a very interesting keynote about the development of security innovations at facebook. For him innovation is „these hacking culture, we think about each day at facebook“. After explaining some of the newer security innovations (https-only, login notifications, login approvals [if e.g. geo-location of a user is suspicious], recognized devices, recent activity) he talked about the recent fb-scams with malicious scripts. „No one would do that, copying and pasting a script into the browser! - Yes, they do...“, he said.

Also a remarkable talk I attended was about binary planting, given by Mitja Kolsek (CTO at ACROS Security). In "Binary Planting: First Overlooked, Then Downplayed, Now Ignored" Mitja also showed a new method he called "advanced binary planting", which uses a feature from Windows' special folders (like control panel, printers, etc.) and clickjacking to make it possible to own the users' computer.

In the winter garden of the conference hotel there's a technology showcase area. Hackerspaces from all over Europe and the Netherlands are showcasing their projects here. There also is a capture-the-flag competition happening, a lock-picking and (sponsor) companies-showcase.

For more informations please see the conference website.

Comment      Link

Security researchers from around the world are digesting the weekend's fare at Infiltrate2011, organized by security outfit Immunity. "No policy or high-level presentations, just hardcore thought-provoking technical meat" was promised, and presenters served it up sizzling.

The sessions folded in a variety of topics slicing up current offensive security issues with some defensive interest mixed in. Discussions spread from technical wizardry attacking hardened linux kernels to general network exploration and reconnaisance. Infiltrate2011 itself follows somewhat on the Blackhat/Defcon conference model, but reduces the corporate marketing at those conferences. The peer reviewed set of presentations and research sponsored by one of the best known offensive security/penetration testing groups in the business sets the bar high and undistracted for the level of technical content. The final agenda is listed here.

Research|Different x86 Bytecode Interpretations

Georg 'oxff' Wicherski
Kaspersky Lab Expert
Posted July 22, 16:17  GMT
Tags: Proof-of-Concept, Linux, x64

Working on an efficient generic shellcode detection engine and verifying results with randomly generated input, I've effectively ended up fuzzing different open source disassembler libraries. The disassembler library of choice for my current project is libdasm because of its comparatively long history and public domain license. But writing a sound and complete x86 disassembler is obviously not a trivial task due to the complex nature of the x86 instruction set.

libdasm used to have issues correctly disassembling certain floating point instructions in the past, but this was simply caused by an off-by-three error in the opcode lookup tables (three NULL rows missing) and thus the fix was comparatively easy.


A user discovered potential malware on his computer the other day – the files “autorun.exe” and “autorun.inf” on the C: drive which, the user claims, reappear after being deleted.

After an initial analysis it was found that a number of files are downloaded, including .NET FrameWork, which is quietly installed in the background. That was quite a surprise – it’s been a while since I’ve seen malware cheeky enough to install .NET. So I decided to investigate this sample in full. It turned out to be very interesting both in terms of the malicious functionality and the method used to install its components.

The autorun.exe source file is an SFX archive created using WinRK, an archive utility that is not currently very widespread. After it is run a whole chain of various files are executed:

Autorun.exe -> .exe -> !.bat -> start.vbs -> .bat -> Hidden Start inst.bat -> evntstart.exe;

The interesting thing about this sequence is that it uses only standard, legitimate software:

  • “Autorun.exe” – WinRK SFX;
  • “.exe” – BatToExe;
  • “inst.bat” – launched using Hidden Start;
  • “evntstart.exe” – WinRK SFX;

Opinions|Secunia tests

Kaspersky Lab Expert
Posted October 17, 12:57  GMT
Tags: Secunia, Proof-of-Concept, Antivirus Testing

By now most people have seen the Secunia test results and all the ensuing discussions. Frankly, I was a bit surprised by the vehemently negative reaction from a number of AV vendors.

And it doesn't seem to be about the 20% difference between the 'winner' and the rest. Criticism has focused on the testing methodology, which many people thought was dubious. Some of the suggestions were useful - mostly those from Andreas Marx, the well-known AV solutions tester from Germany. The general tone, though, seems to be that many AV vendors thought their results would have been a lot better if the test methodology had been different. And maybe they're right.

But I think people are too focused on looking for mistakes in the tests and/or attempting to explain their poor PoC detection rates. Sure, criticizing Secunia's testing methods is justified, but only if we're discussing testing methodology, and nothing else.

As I see it, Secunia wasn't trying to highlight the weaknesses of AV solutions - I think they were trying to make a different point...

At Kaspersky, we've taken a decision not to detect PoC vulnerabilities - it's far more sensible to focus on protecting users from the real threats and exploits that are being used by malware authors in the real world. That's what our antivirus databases are for. The point isn't so much that detecting PoCs is a pretty difficult task (although the test results clearly show that even Microsoft and Symantec, with all of their resources, didn't fare all that well) but that detecting PoC s is a dead end, and doesn't address the fundamental problem.

So what is the problem?

Virus Watch|2+2=89?

Denis Nazarov
Kaspersky Lab Expert
Posted June 01, 09:33  GMT
Tags: Proof-of-Concept

This week we added another unusual detection – detection for a calculator virus.

Virus.TI.Tigraa.a is a memory resident virus, and in the best tradition of DOS viruses, it's a mere 492 bytes in size. It works on Texas Instruments TI-89 graphing calculators (the TI-89, TI-89 Titanium, and the Voyage 200 which will run most programs for the TI-89) with the Motorola 68000 processor. The virus is designed to clear the screen and then display a message saying 't89.GAARA'.

Of course, Tigraa.a is classic proof of concept code. It'll only work on individual calculators, and can't spread. But nevertheless, it's created another entry in the roll call of potentially infectable devices.

Comment      Link

Virus Watch|iNfector for iPod

Kaspersky Lab Expert
Posted April 05, 13:44  GMT
Tags: Mobile Malware, Proof-of-Concept

Do you think that installing Linux on an iPod is a waste of time? If you work in an anti-virus company it's not – you’re preparing the device to play with the first known virus for iPod.

It’s a typical proof of concept sample, showing that here’s another device that can be infected. It took us time to run the sample because the virus has bugs and sometimes crashes the system with Linux debug messages.

Overall, I don't think iViruses will cause serious problems in the future. The iPod world is very different from the PC and smartphone world. Users aren’t constantly installing new software and downloading a wide range of files, so that cuts down on the possible infection vectors. And what’s there to steal from an iPod? Multimedia files, and that's about all.

So – it was an interesting little puzzle, this proof of concept, but nothing more.

Comment      Link