Posted on Leave a comment

Együttműködési megállapodás a Microsec Zrt-vel

Örömmel jelentjük be, hogy a CrySyS labor együttműködési megállapodást kötött a PKI alkalmazásában és fejlesztésében úttörő szerepet betöltő Microsec Zrt-vel.

A két szervezet az elmúlt években is aktív kapcsolatot ápolt, mely keretében a Microsec anyagi és tárgyi eszközökkel támogatta laborunk kutatómunkáját, valamint a laborból indult etikus hackercsapat, a !SpamAndHex külföldi versenyeken való részvételét. Jelen megállapodással a Microsec célja a PKI-val kapcsolatos kutatás-fejlesztési és innovációs tevékenységek kiemelt támogatása, az egyetemi kapcsolatok erősítése, a kutatásokhoz első kézből információk szolgáltatása a gyakorlati problémákkal kapcsolatban. A labor számára az előnyt a tehetséggondozási programunk anyagi támogatása, valamint érdekes, az ipari gyakorlathoz kapcsolódó kutatási feladatok megfogalmazása, és a stabil ipari kapcsolat jelentik.

A PKI kutatások területén a jövőben a labor a Microsec kihelyezett kutató laboratóriumaként működik, és közös publikációk megjelentetésére törekszik.

Posted on Leave a comment

Oops!… We Did It Again

Yeah yeah yeah yeah yeah
Yeah yeah yeah yeah yeah yeah

We think we did it again
We made you believe it’s more than just luck

One year ago, we were proud to announce that the CTF team of the CrySyS Lab qualified for the DEFCON CTF Finals, which is among the most prestigious hacker competitions in the world. Now, we announce with the same pride that WE DID IT AGAIN: our !SpamAndHex team qualified for the 2016 DEFCON CTF Finals and it will travel to Las Vegas within two weeks to play against 14 other teams and a program (the winner of the DARPA Cyber Grand Challenge) between August 4 and 7. Congratulations to the team and looking forward to this extraordinary experience!

By the same token, we would like to express our immense gratitude to our sponsors who made it possible for the team to travel to the competition. They are: Tresorit, BalaBit, Dimension Data, ESET/Sicontact, SEARCH-LAB, MRG-Effitas, Microsec, Hunity Defense, Sophos, Symmetria, TMSI, and BME’s Faculty of Electrical Engineering and Informatics. Below is our team’s T-shirt design showing the sponsor logos. It is heartwarming to witness that our industry partners and our university appreciate our efforts and support the team when we need help.

Sponsors in 2016

You may ask how it is possible that students from a not-so-well-known university of a small country repeatedly achieve first class results at an international level and the 5th position in the world ranking of all hacker teams last year. We assure you that this is not pure luck! Rather, we believe it has something to do with our talent management program in the CrySyS Lab. If you are interested in what is that, then you can read our paper, which has just been accepted for presentation at the Usenix Workshop on Advances in Security Education (colocated with the 25th Usenix Security Symposium in Austin, TX, on August 9, 2016).

If you like what we do and want to help our work on growing talented IT security professionals, please, contact us (by writing to

Posted on Leave a comment

Hacking cars in the style of Stuxnet

Stuxnet is well-known in the IT security community. Its fame stems from the facts that it targeted a very specific industrial facility, it aimed at physical destruction, and it apparently accomplished its mission successfully. In addition to all these characteristics, IT security experts also appreciate its technical sophistication and the zero-day exploits that it used. Yet, we believe that the most important impact of Stuxnet in the long run is that it provides a blueprint for carrying out similar attacks in other embedded computing environments.

To demonstrate this, we started experimenting with attacking cars in the same style as Stuxnet attacked uranium centrifuges. Our experiments show that it is relatively easy to perform dangerous modifications to the settings of different car equipment (e.g., the airbag or the ABS in the car) by simply infecting the mechanic’s PC or laptop that runs the diagnostic software used to manage those equipment in the car, and replacing the DLL responsible for communications between the diagnostic software and the car with a malicious DLL that implements man-in-the-middle type attacks (e.g., replay or modification of commands). Indeed, PCs and laptops in mechanics’ workshops are not well maintained, often connected to the Internet, and used for various purposes, not only for diagnostics on cars. So, while remote attacks via the Internet or wireless interfaces seems to be more exciting than attacking cars via the mechanic’s PC or laptop, the latter can in fact be much easier to carry out and more effective in practice. Note the similarity to Stuxnet, which infected PCs that run the software used to manage the PLCs that controlled the uranium centrifuges, and replaced the DLL that was responsible for the communications between the management software and the PLCs.

More specifically, earlier this year, we carried out some research on an Audi TT at the Department of Automobiles and Vehicle Manufacturing of the Budapest University of Technology and Economics. We partially reverse engineered a widely used third-party car diagnostic software, and managed to identify and replace the DLL that it uses to communicate with a special diagnostic cable that attaches to the car’s OBD connector. Our replacement DLL implements man-in-the-middle attacks: we can log all communications between the diagnostic software and the car, as well as replay and modify messages. For this, we also had to partially reverse engineer the protocol used for communications, including figuring out how to decrypt encrypted messages and compute checksums. Finally, as a proof-of-concept, we managed to replay a message that switches off the airbag of the car without the diagnostic software noticing the misdeed.

We presented this work at the Hacktivity 2015 conference in October. The presentation and the recording of the talk is available on the web site of Hactivity ( The slides are also available on Levente’s publication page ( The direct link to the recorded talk is:  The work also generated some media attention:

The most accurate description (after our own slides and this blog post, of course) was published in Hungarian on the HWSW portal:

The Register article, which was published first:

Others just copied from the above the Register article, and most of them do not describe our work accurately enough:

Some frequently asked questions:

Can you reveal the name of the diagnostic software which you carried out the experiments with?

No, we do not reveal the name of the software. It is sufficient to know that it’s a pretty widely used diagnostic software that is compatible with cars in the VW group. Note, however, that this has nothing to do with VW itself, it’s not their fault, this is a 3rd party software. In addition, we also looked into two other similar diagnostic software from other vendors, and they seem to have the same problem. Essentially, they all use the FTDI DLL to communicate with the diagnostic cable, so the generic idea of our attack (replacing that DLL with a fake one) would work. Details may be different though, as those software may apply different protections against reversing (e.g., better encryption of messages between the application and the cable which would make understanding the protocol harder). We have not yet checked in details those other two software. Also important to point out, that it is not the specific software, which makes our work interesting, but the main message is that embedded devices are typically managed from PCs and they can be infected by using those PCs as stepping stones. This is what we mean by a Stuxnet-style attack in the title of our talk.

Would the attack work for anything other than Audi TTs?

Yes, it works with other cars in the VW group too without any modification. And as said before, it could work with other car brands that use vulnerable diagnostic applications from other vendors.

How challenging is this attack to a reasonably skilled hacker?

It is not something special, so for a reasonably skilled attacker it is completely doable. Important to note that the attacker does not really need to hack embedded ECUs, but the attack essentially requires reversing and attacking an application running on a PC.

Can you do other things than switching the airbag off?

Anything that can be switched on or off from the diagnostic application could have been switched on or off. Moreover, we can hide this from the operator, because our Man-in-the-middle fake DDL can falsify parameters read out from the car. E.g., after switching off the airbag, we can consistently report to the application that it is still switched on.

Is there any limitation of the attack?

One limitation of our attack is that we can only set parameters when the car is connected to the infected PC. In contrast to this, remote attacks that have been in the media recently can affect the car’s behavior in real-time. However, they are much more difficult to carry out, because the attacker needs to find and exploit some vulnerability in one of the ECU’s of the car, instead of infecting a potentially badly managed PC in a repair shop. Yet, our attack may be extensible to be more dangerous: e.g., it may be possible to update the software/firmware of some ECUs via the OBD2 port, in which case we could insert a hidden functionality that is triggered by some condition later on. This is still not completely interactive, but more than a static switch off of a component. However, we did not performed any experiment of this kind, because we didn’t want to potentially brick our university’s car.

Is this attack something really new?

Actually not. Prior work (e.g., Checkoway et al. Comprehensive Experimental Analyses of Automotive Attack Surfaces, Usenix Security 2011) already mentioned the possibility of infecting cars by first infecting diagnostic equipment. Our work was a proof of concept where we tried to study how easy such an attack would be.

Is this really an attack? I mean that if you are connected to the OBD port, you can do whatever you want with the car.

Sure. But let us emphasize again the importance of the generic model of the attack: attack a PC that manages an embedded device, and then attack the embedded device itself. This could be a nightmare in the future. Imagine that you manage all your smart devices in your home/office/factory from your PC. Once dozens of embedded devices are successfully infected, the malware can even disappear deliberately from the PC, so all those embedded devices remain infected and you may never detect that. Whether we call this an attack or not does not really matter. This is certainly an important problem and challenge that we have to address in the future.



This was joint work with Dr. Zsolt Szalay from the Department of Automobiles and Vehicle Manufacturing. We are thankful to him for letting us experiment with the department’s Audi TT. Indirectly, we are also thankful to Audi for supporting research at the Budapest University of Technology and Economics.

Posted on Leave a comment

Evading Intel VT-d protection by NMI interrupts – Security Advisory

UPDATE: A full research report on the NMI and other passthrough attacks is available online at:

Gábor Pék (CrySyS Lab)  started to explore possible vulnerabilities in the use of directly assigned (passthrough) devices in contemporary hypervisors (Xen and KVM). As a result of this research, he pointed out some misbehaviors in the interrupt handling method of current platforms. One of this issues is going to be presented in this article.  A paper is to be published about all the discovered issues in collaboration with other researchers from Eurecom, France.


Direct-device assignment is one of the most controversial issues in hardware virtualization, as it allows for using devices almost at native speed, however, raises many security problems.  As most of these issues can be evaded by properly configured system software and hardware, the security issues of that area seemed to be solved.  At the same time, virtual instances with direct-device assignment are publicly available  via various cloud providers, so the security issues have to be examined in more details. In this article,  an interesting vulnerability is going to be presented which is not a simple software bug, but an example for an issue on how to handle improperly a hardware-level mechanism: the interrupt generation.

More precisely, native host-side Non-Maskable Interrupts (NMI) can be generated on systems (e.g., Xen, KVM etc) with System Error Reporting (SERR) enabled via a passthrough device being attached to a fully virtualized  (HVM) guest even when all the available hardware  protection mechanisms are turned on (Intel VT-d DMA and Interrupt Remapping).

As a result of the NMI, the corresponding host-side NMI handler is executed which may cause Denial of Service (DoS).

To reproduce the issue, the attacker has to create a malformed MSI request by writing to the LAPIC MMIO space (0xFEExxxxx) in the guest physical address range. This can be accomplished by a modified DMA transaction. Examples for malformed MSI requests include Interrupt Vector numbers being set below 16 or MSI requests with invalid size (not DWORD).

Output of Xen 4.2 Dom0 after the attack (xl dmesg):

(XEN) NMI – PCI system error (SERR)

Output of KVM 3.4 host after the attack (/var/log/kern.log):

NMI: PCI system error (SERR) for reason a1 on CPU 0.
Dazed and confused, but trying to continue

The NMI is reported as a result of an ‘Unsupported Request’ PCI system error, and has nothing to do with compatibility format MSIs with delivery mode of NMI. Note that Interrupt Remapping disables the use of compatibility format MSIs by clearing the GCMD.CFI flag. By turning x2APIC mode on system software cannot even reconfigure that flag.

Later investigations showed that the host-side NMI was not generated by the PCI device being assigned to a fully virtualized (hardware-assisted) guest, but the Host Bridge(00:00.0). See the output of lspci.

Before the attack:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
Subsystem: …
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>

After the attack:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
Subsystem: …
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>

Vulnerable Systems

Affected platforms enable System Error Reporting, where the corresponding NMI handler is executed in the hypervisor/host OS that should have never happened in normal circumstances when Intel VT-d Interrupt Remapping is enabled. Note that only Xen and KVM were tested and verified, however, every other system software can be affected which runs above a platform with SERR and Intel VT-d enabled.

While Intel does not recommend to turn SERR reporting on by default, some platforms do enable it as it carries essential information about legal system errors.

SERR reporting can either be disabled for the Host Bridge, or system software can block SERR error signaling due to Unsupported Request error resulting from malformed MSI requests. The former advice is quite intrusive as it suppresses all the system errors coming from the Host Bridge. At the same time, this is supported by all the chipsets. The second option is a more fine-grained solution, however, there is no information whether it is applicable to all Intel chipsets.

As a consequence, there is no real solution available for the issue for now.


Corresponding CVE number: CVE-2013-3495
Corresponding Xen Security Advisory number: XSA-59


Many thanks go to Jan Beulich from the Xen security team, the Intel Product Security Incident Response Team and Rafal Wojtczuk from Bromium for the in-depth discussions, recommendations and advices.

More details about this issue is going to be published in our upcoming paper.

May you have any questions please let us know.