Category: Hacking

Posted on by — Leave a comment

A pizzás ügy margójára

Kedves Diákok!

Talán hozzátok is elért a veszprémi pizzéria weboldalát tároló szerver feltöréséről, az arról ellopott adatokról való hír. Erről több olvasható például itt a népszaván.

Nagyon fontos elmondanunk, hogy a támadó -még ha a jó szándék vezérelte is- borzasztóan etikátlanul, törvénytelenül és veszélyesen járt el, és nagyon szeretnénk, ha az adatbiztonsággal foglalkozó hallgatóink soha nem követnének el hasonló hibákat.

Internetes weboldalak biztonsági tesztelésére csakis felkérés alapján, megfelelő megállapodás szerint kerülhet sor- Egy ilyen megállapodás rögzítheti az alkalmazható eszközöket, az ellenőrizhető célpontok körét, az ellenőrzés időbeli korlátozását, és számos más dolgot. Ilyen megállapodás hiányában már a feltörési kísérletek is jogszabályokba ütköznek, de egy sikeres feltörés alapesetben is 3 évig terjedő szabadságvesztéssel járhat!

Az elkövető ráadásul adatokat lopott, ráadásul ezeket közre is adta. Újabb két dolog, ami miatt súlyosan megütheti a bokáját, és akkor még nem beszéltünk a webszolgáltatónak és a cégeknek okozott kárról!

Fontos megjegyezni: Ha igaz a hacker állítása, hogy a szerver katasztrofális biztonsági állapotban van, az szintén elfogadhatatlan, és veszélyezteti emberek személyes adatait, amivel a cég az új adatvédelmi rendelkezések bevezetésével komoly büntetést is kaphatna, és egyetértünk abban is, hogy az ilyen cégeket jó lenne kényszeríteni arra, hogy biztonságukat megfelelően valósítsák meg.

Ugyanakkor nem lehet önbíráskodó módon, törvénytelenül, kérés nélkül ilyen cselekedeteket elkövetni. Még akkor sem, ha valaki nem lop el adatot, és nem publikálja azokat.

Ha a diákjaink valamikor adatbiztonsági sérülékenység jeleit, nyomait látják, vagy esetleg bizonyítékot is szereznek erről (remélhetően véletlenül), úgy a helyes eljárás a szolgáltató, kiszolgáló tulajdonos stb. haladéktalan és teljes körű tájékoztatása. Ha ez nem tehető meg közvetlenül, akkor javasolt a megfelelő, kapcsolódó CERT, kormányzat esetén pl. a GovCERT, a Kormányzati Eseménykezelő Központ tájékoztatása, akik segíteni tudnak a komnmuniákcióban, és a problémák megfelelő kezelésében, jogszerűen, úgy, hogy az mindannyiunk javára váljon.
Kérjük a diákokat, hogy ne próbálják meg utánozni a támadót, nem éri meg a 2 perc hírnév!

Posted on by — 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 (https://hacktivity.com/en/archives/hacktivity-20151/). The slides are also available on Levente’s publication page (http://www.hit.bme.hu/~buttyan/publications.html#SzijjBSz15hacktivity). The direct link to the recorded talk is: https://www.youtube.com/watch?v=5UCsKQjB6ZE.  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: http://www.hwsw.hu/hirek/54692/crysys-auto-jarmu-biztonsag-man-in-the-middle.html

The Register article, which was published first:
http://www.theregister.co.uk/2015/10/23/hackers_pop_mechanics_laptops_to_silently_disable_car_airbags/

Others just copied from the above the Register article, and most of them do not describe our work accurately enough:
http://www.heise.de/security/meldung/Audi-TT-Airbag-heimlich-ueber-Diagnose-Software-deaktiviert-2858815.html
http://wccftech.com/cars-safety-bags-unsafe-hackers-find-disable/
http://news.softpedia.com/news/audi-cars-hacked-but-only-airbag-system-affected-495257.shtml
http://www.techworm.net/2015/10/hackers-find-a-way-to-disable-your-cars-airbag-system.html
http://www.scmagazine.com/researchers-control-features-in-vw-group-vehicles-through-a-zero-day-in-software-that-in-widely-used-mechanic-software/article/449161/
http://www.mirror.co.uk/news/technology-science/technology/car-airbags-disabled-hackers-cyber-6690661
http://news.sky.com/story/1575011/hackers-could-disable-car-airbags-report
http://www.cnnindonesia.com/teknologi/20151023171304-185-86938/hacker-mampu-meretas-airbag-mobil-vw/
http://www.techcult.ru/auto/2707-hakery-i-airbag

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.

 

Acknowledgements

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 by — Leave a comment

Anti-APT product test sample "BAB0" is shared for security experts

As we promised in our previous blog post, we release BAB0, the test sample that bypassed all 5 anti-APT products that we tested earlier in this year.

BAB0 is written in C++, and it has a server side written in PHP. BAB0 is downloaded by the victim as part of an HTML page, where it is actually hidden in an image with steganography. The downloaded page also contains scripts that extract an executable from the image when the user clicks on something that appears to be a download button. The image has already been uploaded to Virus Total with 0/54 hits. Once BAB0 is running, it can communicate with a remote C&C server. To hide the C&C network traffic, BAB0 simulates a user clicking on links in a web forum, and downloads full HTML pages with CSS style sheets and images. The real C&C traffic is hidden inside these HTTP requests and responses. BAB0 allows for file download to the victim and file upload to the server, as well as remote execution of commands on the infected computer.

We release the BAB0 sample because we believe this is the most effective way of pushing the vendors to address this and similar threats in future releases of their products and to raise awareness about the fact there are no silver-bullet products that protect against everything possible. The sample that we are releasing now consists of the PNG image that contains the BAB0 executable and the scripts that extract BAB0 from the image. We do not release the source code of BAB0, neither we release the server side of the sample. The sample tries to connect to our server, but no real attacking functionality is deployed on it. In order not to harm end-users, we shared the information being released now with anti-APT vendors (not just the ones that we have tested) almost three weeks ago, when we released the report on our test results. We also shared the BAB0 sample with other security companies who expressed their interest after reading our report. So vendors and security companies had sufficient time to prepare for the public release of BAB0 and protect their customers.

Download BAB0 sample
Disclaimer: This sample is not a malware, but it is a possibly unwanted program. Its functionality is similar to those found in real threats. If you run our sample, it will start communicating with our server, but our server does not send any command to the particular sample program and we do not conduct anything harmfuly for anybody who runs this sample. This sample is designed for security experts to be run in sandbox environment or to analyze its capabilities. We do not prohibit reverse engineering of the sample, and we give explicit permission to run it by security professionals. However, intellectual propery rights on the software and the incorporated ideas belong to CrySyS Lab, part of the Budapest University of Technology and Economics. The sample is provided in an AS-IS basis, as it is disclosed for free, we do not give any warranty, we do not guarantee it cannot cause harm in any IT system. This is a prototype work. If you are not confident how to work with it, please do not download. Authors and the institution take no responsibility on any damages related to the sample or any derivative work.
According to our understanding, this demonstrative work does not contain any exploit, it is not a weapon and not considered as dual-use product according to Hungarian and EU laws. If you have questions or problems, please contact us.

PS. Easter egg:
Babo means hobbit in Hungarian, and we named our sample so, because it was designed to stealthily bypass all state-of-the-art defenses, while actually being very simple, and this is similar to the way Frodo, the hobbit, managed to bypass all defenses of the fearsome Sauron in the Lord of the Rings.

ps2. before you ask. Password is “infected” as usual in the industry.

Posted on by — Leave a comment

New anti-APT tools are no silver bullets: An independent test of APT attack detection appliances

New anti-APT tools are no silver bullets:
An independent test of APT attack detection appliances

CrySyS Lab, BME http://www.crysys.hu/
MRG-Effitas https://www.mrg-effitas.com/

November 26, 2014.

The term Advanced Persistent Threat (APT) refers to a potential attacker that has the capability and the intent to carry out advanced attacks against specific high profile targets in order to compromise their systems and maintain permanent control over them in a stealthy manner. APT attacks often rely on new malware, which is not yet known to and recognized by traditional anti-virus products. Therefore, a range of new solutions, specifically designed to detect APT attacks, have appeared on the market in the recent past, including Cisco’s SourceFire, Checkpoint, Damballa, Fidelis XPS, FireEye, Fortinet, LastLine, Palo Alto’s WildFire, Trend Micro’s Deep Discovery and Websense.

While these tools are useful, determining their real effectiveness is challenging, because measuring their detection rate would require testing them with new, previously unseen malware samples with characteristics similar to those of advanced malware used by APT attackers. Developing such test samples require special expertise and experience obtained either through the development of advanced targeted malware or at least through extensive analysis of known samples.

We in the CrySyS Lab, together with our colleagues at MRG Effitas, decided to join our forces and perform a test of leading APT attack detection tools using custom developed samples. MRG Effitas has a lot of experience in testing anti-virus products, while the CrySyS Lab has a very good understanding of APT attacks gained through the analysis of many targeted malware campaigns. Therefore, collaborating and bringing together our complementary sets of expertise looked like a promising idea. Our goal was not to determine the detection rates of different APT attack detection products, because that would have required testing with a large set of custom developed malware samples, which was not feasible to obtain within the limited time frame and with the limited resources we had for the test. Instead, our goal was simply to implement some ideas we had for bypassing cutting-edge APT attack detection tools without actually being detected, and to test if our ideas really work in practice.

We developed 4 custom samples in 2 weeks and without access to any APT attack detection tools during the development, and then later tested with these samples 5 APT attack detection solutions in Q3 2014. All 5 tested products are well-established in the market; however, we cannot mention vendor names publicly. The result of the test was alarming:
– one of our 4 custom samples bypassed all 5 products,
– another sample of the remaining 3 samples bypassed 3 products,
– only the two simplest samples have been detected by the tested products, and even those triggered alarms with low severity in some cases.

We made the full report (https://blog.mrg-effitas.com/wp-content/uploads/2014/11/Crysys_MRG_APT_detection_test_2014.pdf) on our test available online. It contains our test methodology, including a brief description of each sample we developed for the purpose of the test, and we also present in it the test results in more details. We decided to publish this report for multiple reasons:
– First of all, we believe that our test was more appropriate for evaluating the detection capabilities of APT attack detection tools than some earlier, heavily criticized tests were, because unlike earlier tests, we used custom developed samples that resemble the malware used in APT attacks.
– Second, some of the products that we tested seem to be overestimated by the users who believe that those products are silver bullets. On the other hand, we have already emphasized at multiple occasions that these products can and will be bypassed by determined attackers. Our test is a clear proof of this, and if we could do that, then APT attackers will also be able to do that, if they have not done so yet.
– Third, we observed that some vendors of APT attack detection tools are often reluctant to participate in tests that try to evaluate the effectiveness of their products. On the one hand, we understand their caution, but on the other hand, we all know that the approach of security by obscurity has its own pitfalls. By publishing this report, we would like to encourage anti-APT tool vendors to participate in independent tests more readily and cooperatively, in order to have sufficient amount of convincing results about their products, based on which well-informed decisions can be made by the users.
– And last but not least, we believe that there are significant differences in the APT detection capabilities of the tested products, and users should be aware that not all vendors provide the same detection rate.

The test sample that bypassed all 5 tested products was developed by the CrySyS Lab. It is a custom designed sample written in C++ with a server side written in PHP. It was designed to be as stealthy as possible. It is downloaded by the victim as part of an HTML page, where it is actually hidden in an image with steganography. The downloaded page also contains scripts that extract an executable from the image when the user clicks on something that appears to be a download button. Once the sample is running, it can communicate with a remote C&C server. To hide the C&C network traffic, the sample simulates a user clicking on links in a web forum, and downloads full HTML pages with CSS style sheets and images. The real C&C traffic is hidden inside these HTTP requests. The sample allows for file download from and upload to the C&C server, as well as remote execution of commands on the victim computer.

We named this test sample BAB0, which (babo) means hobbit in Hungarian, as its objective was to stealthily bypass all state-of-the-art defenses, while actually being very simple, and this situation shows a parallel to the story of the Lord of the Rings, where Frodo, the small hobbit managed to bypass all defenses of the fearsome Sauron, the Lord of Mordor, and reached Amon Amarth, where the One Ring was finally destroyed.

We have a strong intention to publish BAB0 in the near future. This may seem to be controversial, as making the details of BAB0 publicly available can help attackers. We have a different opinion: Powerful attackers have probably been using already similar tricks, but apparently detection tools are not yet prepared to cope with them. By publishing BAB0, we push anti-APT vendors to strengthen their products, which will ultimately make the attackers’ job harder.

For further information, please contact either Zoltan Balázs (Zoltan.Balazs@mrg-effitas.com) or Levente Buttyán (buttyan@crysys.hu). Please note that we cannot provide any vendor specific information about the tests, but we can help organizations to test the products integrated in their environment.

Posted on by — Leave a comment

Hungarian passwords in the Adobe leaked password list

This article reflects results of joint work with Ukatemi guys.
(A magyar nyelvű változat az angol után található.)

Adobe was compromised this September. Stolen data was first found in September and disclosed in early October by Brian Krebs. Later on, some 10 days ago somebody has leaked a 9GB (uncompressed) authentication database stolen from Adobe.

The database was analyzed recently based on the properties of the encryption scheme.
http://stricture-group.com/files/adobe-top100.txt contains the results of the analysis: the top 100 frequently used encrypted passworts and the most probable guesses for the raw password.
Press write-up is also available on the research: http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

We were however curious about the passwords chosen by Hungarians. In the Adobe leak, there are 209 125 email addresses with .hu CCTLD domain name. By the same way how the previous research was carried out, we created a list of most frequent passwords among this 200 thousands of users and tried to pinpoint the most likely cleartext password based on the password hint information and email addresses.

Note, however, that due to the much smaller corpus (200k instead of 154M accounts), we had much lower number of password hints, and thus the confidence of our results is lower.
In the table below, we show the frequency, how many times a password was used in the .hu corpus, and for comparison, we also show the frequency in the full database. If a password is often used in the whole database, then it is most likely not a specific hungarian word, but some internationally known word,phrase or code. In addition to the most likely password, we give secondary ideas in cases where we are not confident enough, and some information about the meaning of the specific word, if it relates to Hungarian language or culture.

Ezév szeptemberében vették észre, hogy valamilyen ismeretlen csoport feltörte a világszerte ismert Adobe szoftvergyártót (többek között az Acrobat Reader, Photoshop és Flash Player gyártóját), és elloptak a cégtől forráskódokat valamint nagyméretű felhasználói adatokat tartalmazó adatbázisokat. Október elején került napvilágra az adatlopás ténye, és október végén hírek kaptak napvilágra arról, hogy a cég 154 millió felhasználójának adatai is napvilágra kerültek. Pár nappal később egyre több helyen volt elérhető ez az ellopott 9GB méretű információhalmaz. Az adatok tartalmazzák a felhasználók e-mail címeit, kódolt jelszavát és ún. jelszó-tanácsát is. A kódolt jelszó egy szimmetrikus rejtjelezővel, egy erősnek számító 3DES algoritmussal van rejtjelezve, a jelszó-tanács egy védelem nélküli szöveg.
A rejtjelezett jelszót kulcs nélkül nem lehet dekódolni, és a kulcs egyelőre nem szivárgott ki. Ezért a jelszavak elvileg nem feltörhetőek. Sajnos azonban az iparági gyakorlattól eltérően a tárolási mód sérülékenységeket rejt magában. A rejtjelezett kulcsok nem salt-oltak és ECB módban “IV” nélkül rejtejelezettek. Ezek a szakkifejezések azt mondják ki: ha két felhasználónak azonos a jelszava, akkor a rejtjelezett párjuk is azonos.

Ez pedig gond. Sok felhasználó esetén sokan használnak azonos jelszót. Ha két felhasználó azonos jelszót használ, akkor a kódolt jelszavuk is azonos lesz. Ha találunk két felhasználót, akiknek azonos a kódolt jelszavuk, és az egyik a jelszó-tanács mezőben az írja, hogy “A jelszó három a betű és az 12 számsor”, akkor nagy valószínűséggel tudjuk, hogy a másik felhasználónak is aaa12 a jelszava. Nincs lehetőségünk a teljes bizonyosság megszerzésére, tehát ez a trükk főleg olyan jelszavakra működik, ahol a jelszavakat sokan használják és sok a jelszó-tanács (password hint) is.

Ennek megfelelően külföldön már pár napja publikáltak egy listát a leggyakoribb 100 rejtelezett jelszóról és annak megfejtett párjairól. A .hu domain névvvel regisztrált email című felhasználók száma meghaladja a 200 000 elemet a listában, közösen az Ukatemi startup cégünk embereivel azt vizsgáltuk meg, hogy mik a magyar jelszóválasztási szokások, és hogyan illeszkednek a nemzetközi környezethez.

Az alábbi listában megtekinthető a magyarok (.hu email) által leggyakrabban használt jelszavak kódolt változata, a darabszám, ahányszor .hu domainről használták, a darabszám, ahányszor nemzetközileg használták (ez is érdekes lehet, hisz vannak magyarok .com cím alatt is, és vannak jelszavak, amik nemzetközi szinten is használatosak). Feltűntettük a legvalósznűbb becslésünket a jelszóra (ami nem biztos, mert nem ellenőrizhető jogszerűen), és a tippjeinket, ha a legbiztosabb ötlet nem igaz. A külföldiek számára kis értelmezést is elhelyeztünk a jelszó jelentéséről.
Összesen csak kb. 3 jelszó esetén nem volt elég adat a nagyjából biztonságos azonosításra, ezeknél valamilyen okból senki, vagy szinte senki nem jelölt meg jelszó-emlékeztetőt.

Érdekességek:

  • Sok citromail.hu felhasználó jelszava “citrom” – nem túl kreatív és veszélyes
  • Sok jelszó-tanács nagyon egyszerű ” a van ellentéte” “nem narancs” “A tudom ellentéte”
  • Sok tanács kiad plusz információt “Ugyanaz, mint az xy@z.hu címemen” – ez külön segítség, hogy mit támadhatunk meg még a jelszóval.
    “Mint mindenhol” – ez is egyértelműen gond, nemcsak, hogy ugyanazt a jelszót használja a felhasználó, de még segíti is a támadót, hogy továbbmenjen.

  • Sok felhasználó “nevem” “barátnő neve” “második nevem” szöveget írt, mondván, esetleg az email címéből ez nem következik. Ugyanakkor, a többi azonos jelszót
    használó felhasználónak elég egy szempillantást venni az email címeire, és triviális, hogy ha 20 emberből 10-nek csilla szerepel a címében, akkor a jelszó csilla, vagy annak becézése lesz. És innentől egy vadidegenről azt is tudhatjuk, hogy mi a neve, barátnője neve, második neve stb., ami segítség ún. social engineering támadásokhoz is.

FRISSÍTÉS: Találtunk pár apróbb hibát, ezeket “FIXED” felirattal javítjuk

Mintaként nézzük meg a következő rövidített listát (lecseréltük X-re a nem releváns részeket):

115103118-|--|-XXcsilla@XXX.hu-|-8Nd+cNdQ360=-|-nevem|--
62657676-|--|-nonXX@XXXXX.hu-|-8Nd+cNdQ360=-|-|--
100898317-|--|-Xcsilla2@XXXX.hu-|-8Nd+cNdQ360=-|-name|--
121149457-|--|-XXcsilla@XXXX.hu-|-8Nd+cNdQ360=-|-nevem|--
123756555-|--|-barXXXX@XXXX.hu-|-8Nd+cNdQ360=-|-kind|--
153339366-|--|-slXXX@XXX.hu-|-8Nd+cNdQ360=-|-Asszony|--
114565459-|--|-zsolt.XXXX@XXX.hu-|-8Nd+cNdQ360=-|-kislanyom|--
63691377-|--|-X_csilla@XXXX.hu-|-8Nd+cNdQ360=-|-|--
66609165-|--|-archer.XXX@XXX.hu-|-8Nd+cNdQ360=-|-|--
67272237-|--|-ylvXXX@XXXXX.hu-|-8Nd+cNdQ360=-|-|--
74715082-|--|-lindusXX@XXXXX.hu-|-8Nd+cNdQ360=-|-nevem|--
174992278-|--|-fXXXX.csilla@XXX.hu-|-8Nd+cNdQ360=-|-|--
177821115-|--|-putirXXXX@XXX.hu-|-8Nd+cNdQ360=-|-|--
183285417-|--|-kXXX.csilla@XXX.hu-|-8Nd+cNdQ360=-|-|--
96471297-|--|-csillapXXX@XXX.hu-|-8Nd+cNdQ360=-|-|--
69058043-|--|-csillalXXX@XXX.hu-|-8Nd+cNdQ360=-|-|--

A “nevem” “name” “Asszony” és “kislanyom” alapján egyértelmű, hogy egy női nevet keresünk. Ezután pedig elég ránézni az e-mail címek listájára, hogy észrevegyük mennyire sok “csilla” szerepel rajta. Persze tévedhetünk, hiszen van egy “lindus” email című is, de a “csilla” elsöprő többségben van.

A jelszavak listájából látszik, hogy nagy az átfedés a nemzetközileg is használt jelszavakkal pl. “123456”, de vannak lokálisak is “szerelem”. A legtöbb jelszó továbbra is név vagy becenév, alig van ettől eltérő az első százban. Tanács: Sose használjuk emberek neveit, beceneveit, vagy azok módosításait, mert ezek a leggyakoribbak. Legyünk kreatívabbak, még mindig igaz, hogy a cseresznye151pok sokkalta biztonságosabb, mint a kr1sztinaIloveyou. A legjobb, ha valami generátorral készítünk jelszavakat, ezek sem tudnak csodát tenni, de egy DooYee7goe5EeFa nagyon erős. Összehasonlíthatatlanul erősebb az eddigi vicces példáknál.

Összegezve:
A helyzet tehát az, hogy aki regisztrált az Adobe-nál bármilyen okból, és a jelszavát máshol is használta, azonnal jelszót kell változtatnia a többi helyen.

Rank No. in .hu No. in all Encrypted PW Most likely password Is it in top100/english? remarks, other guesses
1 3191 1911938 EQ7fIpT7i/Q= 123456 Y
2 525 932 pbn7wO3zb+8= jelszo password in hungarian
3 461 43497 4V+mGczxDEA= 12345 Y
4 394 446162 j9p+HwtWWT86aMjgZFLzYg== 123456789 Y
5 348 13401 uQM9dmQq8vE= qwertz hungarian keyboard layout has y=z
6 337 345834 L8qbAD3jl3jioxG6CatHBw== password Y
7 289 201580 j9p+HwtWWT/ioxG6CatHBw== 12345678 Y
8 273 31555 dA8D8OYD55E= asdfgh Y
9 248 113884 7LqYzKVeq8I= 111111 Y
10 214 76187 diQ+ie23vAA= 000000 Y
11 213 44282 xz6PIeGzr6g= aaaaaa Y
12 209 54651 WqflwJFYW3+PszVFZo1Ggg== macromedia Y
13 202 20961 WlMTLimQ5b4= asdasd Y
14 201 61453 ukxzEcXU6Pw= 1234 Y
15 189 320 q1A6iHNzTFg= valami something in hungarian
16 186 313 MWv89Ddd99M= piglet
17 176 1467 3zV1jrgwEro= attila hungarian male name
18 175 284 MiWs/2HM40w= lacika hungarian male name
19 173 124253 dQi0asWPYvQ= 1234567 Y
20 153 37407 yp2KLbBiQXs= 666666 Y
21 151 274 z5rLiwD12co= almafa appletree in hungarian
22 150 260 N4+iUEuZbPw= cica cat in hungarian
23 137 214 MAEvnIZOuSk= peti peter in short
24 135 6662 uIMAMQyXI/g= something international, 6600 hits
25 134 239 dvqulUaGiQg= zolika zoltan in short, male name
26 126 273 AhfBRgIzdos= tamas maybe tomi tomika, male name
27 125 294 W/jzwDNnaOw= lofasz should be censored
28 124 367 MSycWzt2SLPqvJr9l/X59g== szerelem love in hungarian
29 123 220 rA3xnflDDXI= esztike maybe eszter, hungarian female name
30 119 83411 PMDTbP0LZxu03SwrFUvYGA== photoshop Y
31 118 13044 upIXKNY/ZKY= xxxxxx
32 116 234 zjrHRH4etC0= macika maybe maci, stands for bear or teddy
33 107 234 m0/4nMkmJyM= gabi maybe gabika, female or male name in short
34 106 15910 e21tszGBy4k= matrix Y
35 104 187 P9f9Bgw46Hk= nincs means it does not exist
36 102 194 zwakdT5tFhk= titok secret in hungarian
37 100 192 /jNYdvynVr0= csillag star in hungarian
38 100 1162 +bZCz+Mm7WHioxG6CatHBw== budapest capital of Hungary
39 97 235 iqVZniq2Z6fioxG6CatHBw== cicamica like pussycat
40 97 443 bDjmWzVDGMo= dani male name in short
41 97 17989 NtCzq/i0Ffc= abc Y
42 95 9014 LEdwuvBMkVzioxG6CatHBw== garfield
43 92 16374 QSay9kzQVz8= samsung Y
44 92 155 FClbZZD1l1A= FIXED: nemtom I dunno in short
45 91 149 Xe2T3yCUsCc= balazs maybe balu, balika
46 90 155 lwXlGk4RTzc= mazsola kind name
47 89 247 D0B1TLHoZoTioxG6CatHBw== szeretet love (one version) in hungarian
48 88 197 Yg/0iyYFi+A= janika male name in short
49 86 12160 rkyaRFa+eak= qwe123
50 86 421 FvWPZ2OI8V0= tigris maybe tigris1
51 84 17176 oa/GBGqIApo= killer Y
52 84 4540 TYrTfuuBGm0= monika female name in short
53 83 142 p6kbkduAMhPioxG6CatHBw== FIXED: macilaci/TD>

 Yogi Bear
54 82 153 iolWV4U4baM= madar bird in hungarian
55 81 131 TiMyOmRnnYk= mokus second guess: manoka mokus is for squirrel
56 80 214 ugYjb/7SO9DioxG6CatHBw== FIXED: nemtudom “I don’t know”
57 79 11707 rNhveK0RH5Q= ferrari
58 79 1267 ghZhzPTEyrU= viktor
59 79 6920 QkLIDf6naxw= no hint, strange
60 78 27387 XpDlpOQzTSE= 121212 Y
61 78 4829 XWs+3joEULU= 0123456 maybe 012345
62 76 18049 b5LJqTmQmvQ= 555555 Y
63 74 377 syBP2PbOprLioxG6CatHBw== FIXED: freemail
64 73 9787 C6fdPcrsYlU= 123asd or asd123
65 72 20572 ueE89xIj8RTioxG6CatHBw== internet Y
66 72 17454 MEXwK6GOWHk= andrea Y
67 72 130832 5djv7ZCI2ws= qwerty Y
68 71 7991 E3P4TkKmrIE= no hint, strange
69 70 82694 e6MPXQ5G6a8= 123123 Y
70 70 43673 Ypsmk6AXQTk= 654321 Y
71 69 111 WHnoclxstks= some woman’s name, bea, betti, zsuzsa or monika are most likely
72 69 3246 SSCHXSLigpo= roland
73 69 2618 I+sy2I0+oHg= delfin
74 69 230 2e2bx0WPm8o= andi
75 68 10742 ewOK16tiXAs= enimem
76 68 22103 OrzNCxMfwrw= fdsa Y
77 68 139 8Nd+cNdQ360= csilla hungarian female name
78 66 959 remGyraE2+rioxG6CatHBw== viktoria hungarian female name
79 66 5213 SVXt5Rlot1U= clever or something related to iq, cleverness, and a brand of computer mouse
80 66 16177 F9nqBYx2LhA= asdfghj Y
81 66 13531 DuMurYI43dU= blabla blahblah in hungarian
82 65 737 vEldih7WrfY= vivien female name
83 65 129 o2D+z1QYuHo= FIXED: nyuszi bunny in hugarian
84 65 7070 U1yPApWcaOA= barbara female name
85 63 27856 pTkQrKZ/JYM= dragon Y
86 62 128 vQGGxx87Fyk= levente male name
87 62 95 7DOklOXTFPo= zsolesz or other forms of zsolt, like zsolti
88 61 70795 kCcUSCmonEA= abc123 Y
89 61 81 gkfBa7HrOnY= citrom funny, many “citromail.hu” users chose that, hungarian: lemon
90 61 15805 fbO2Wx232qY= secret Y
91 60 102 kiQXbvrKbiA= robi or robert, robby, roby, or similar
92 60 88 GsQ/41R7pXw= FIXED: kriszti female name
93 60 194 /EoAhM0rWA8= kata maybe katalin, kati, female name
94 59 179 mkRrr6/R2oE= richard
95 59 14159 PwB5ue3qkgs= oliver
96 59 181 Kt3DWt8h3tg= ildiko hungarian female name
97 57 6734 u57swGYZlf/ioxG6CatHBw== juventus
98 57 146 MoedSZDdCmk= zsuzsi or zsuzsanna, hungarian name like suzy
99 56 20022 ziypr2hyamc= 123qwe Y
100 56 97 pp3j26xZbvTioxG6CatHBw== kiskacsa stands for duck in hungarian. fix: kacsa->kiskacsa “small duck”
101 56 P2x/N9v5UaM= melinda female name in short

Edited by: Boldizsar Bencsath

Posted on by — 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: http://www.crysys.hu/~pek/pubs/Pek+14ACMAsiaCCS.pdf

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.

Description

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.

Mitigation
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.

References

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

Acknowledgement

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.