 |
hacking for the fun of it |
|
hacking for the fun of it |
Scroll down or click here for the german
version
In September 2010 we were giving a talk on security concerns that come with SuisseID and the German electronic identity card (nPA). Since we didn’t want to torture the conference participants with boring talk no. 2000 on certificates and PKI, we decided not to focus on PKI but on applications and the environment (legal as well as technical aspects) of these smart card solutions.
Just after we've ordered the certificates and had a first look at hard and software we thought, gosh… that does not look like what we were promised in first place. We decided to realise all scenarios of possible attacks as simple as possible and to therewith scratch only at the surface of the problem. We were aware of the fact that false information and marketing promises made in this case had to be confronted with harsh reality to start a critical discussion and to impose some “positive pressure“ on the producers.
There are essential parallels between the German ePA (elektronischer Personalausweis, electronic identity card) – which is now called nPA, since the term ePA has already been worn out – and SuisseID. Both initiators of the products had for example decided to deliver the first generation with simple class 1 readers. The weak spots of these devices are well known and it should be common knowledge to every technical interested person that to enter a password on a computer is insecure. Any kinds of key loggers are part of every small-time criminal’s methods at hand to spread viruses and trojans; above all companies, which operate in the IT-security sector should be aware of these risks. Even more so does it seem inappropriate that these readers are still in use.
Official SuisseID sites as well as the SECO (Federal Department
of Economic Affairs DEA) communicate as follows(Translated from
German):
Gentlemen, if you will pardon my saying so, but to put it
straight, we decided to use a USB over network Software (a
commercial shareware), which allows access to all USB devices over
a local network. The bad hacker was supposed to take these over and
abuse somebody else’s identity together with the beforehand sniffed
PIN. We attached great importance to realising the scenario as
simple as possible. The result can be seen in the video
below.
|
SuisseID / Smartcard USB Takeover from Max Moser on Vimeo. A proof of concept video, which demonstrates a successful attack on SuisseID with simplest means. More details can be found on http://www.remote-exploit.org. |
We used the popular Metasploit framework (best wishes to H.D. Moore and his co-workers), as well as some Meterpreter scripts, which upload and install the software (shown in the video). This was about it and the attack was over since the key logger is a component of Metasploit, however… So c’mon, 6-7 lines, that’s it. By the way, if you feel like supporting the open source project usbip.sourceforge.net or even come up with a more elegant solution, go for it. Remote access to USB devices is not new, but always nice to have.
We had even more concerns about the signature software SwissSigner and E-gov Local Signer we touched upon. SuisseID is basically supposed to provide a legally valid electronic signature. We were very surprised when we realised that both Java applications allow the signing of Javascript in pdf documents even though the code had not been interpreted or rendered. A pdf was written and signed in no time.
The signed original is available for download on http://www.remote-exploit.org/content/sigdemo.pdf
Have a look at the effects by enabling or disabling Javascript in
the settings of the Acrobat reader.
The document looks different depending on the software in use (SwissSigner, Egov Signer or Acrobat). But the sad thing is, that the signature stays intact under certain circumstances. This means that you can see the document has been modified, but the problem here is not the signature but the rendering. Exactly… Electronic magic ink! It’s very sad to hear that even SwissSign asserts that their product meets all legal requirements. http://swisssign.com/en/produkte/swiss-signer
 |
 |
||
| Screenshots of a sales contract within the SwissSigner application. The picture shows a nice and sound motorcycle. | Here the same document shown in the Acrobat reader: The signed Javascript has been rendered, the document now shows a wreck instead of the nice motorcycle. Since the signed Javascript was rendered, the customer buys a wreck instead of the fantastic motorcycle. |
From our point of view, there is any kind of basic security measure missing that would prove the “immutability” of the document, since the documents look different depending on the software, even before the signature is applied. Soooo what??? We are not lawyers, but is this legal? And if we apply our concerns on the card reader, why do German nPAs not work with class 1 readers and here in Switzerland everything seems to be fine with these?
We posed some general questions:
More details and explanations can be found on the slides that came with our talk. We hope to have added some common sense to this discussion and helped to talk about the issues in a qualified way.
Oh, and to put it straight: The verification of the signature is only identical under certain circumstances. As mentioned in our talk, the verification of the signature can be repeated or displayed as "show signed version" in the Acrobat reader, which immediately shows you the real motorcycle. As described above, it is all about the difference in the rendering engine resp. if Javascript is rendered or not. But independently of the renderer, the signer should never ever sign dynamic data but convert them first into a static format, this is what we talk about here.
Im September 2010 hielten wir einen Talk über sicherheitsrelevante Bedenken rund um die SuisseID und den deutschen elektronischen Personalausweis (nPA). Damit die Teilnehmer der Konferenz nicht mit dem zweitausendsten langweilen Talk über Zertifikate und PKI gequält werden, hatten wir uns entschieden, uns nicht auf die PKI, sondern auf die Applikationen und die Umgebung (rechtlich wie auch technisch) der Smartcard-Lösungen zu fokussieren.
Bereits nachdem wir uns die Zertifikate bestellt hatten und einen ersten Blick auf die Hard- und Software werfen konnten, dachten wir:... uiuiuiuiui.... Das sieht nicht so aus wie ursprünglich angepriesen. Wir beschlossen aber, alle Angriffszenarien bewusst simpel zu realisieren und damit nur an der Oberfläche zu kratzen. Es war auch klar, dass wir den Fehlinformationen und Marketingversprechen mit purer Realität entgegentreten mussten, um eine kritische Diskussion auszulösen und idealerweise ein wenig positiven Druck auf die Hersteller auszuüben.
Grundsätzlich bestehen zwischen dem ePA (der ja jetzt eigentlich nPA heisst, da der Begriff ePA schon "verbrannt" wurde) und der SuisseID einige Parallellen: Zum Beispiel hatten sich beide Initiatoren der Produkte entschieden, die Erstauslieferung mit einfachen Klasse-1 Lesern auszurüsten. Die Schwächen dieser Geräte sind wohl hinreichend bekannt, und es sollte jedem technikinteressierten Menschen klar sein, dass ein Passwort auf dem PC eingeben zu müssen, unsicher ist. Keylogger jeglicher Colour gehören zum Viren- und Trojanerbaukasten eines jeden Kleinstkriminellen, das sollte insbesondere Firmen mit Schwerpunkt IT Security sehr wohl präsent sein. Um so unmöglicher erscheint also der Umstand, dass solche Lesegeräte primär zum Einsatz kommen sollen.
Auf den offiziellen Seiten der SuisseID sowie dem SECO fand sich
die folgende Aussage:
Gentlemen... mit Verlaub: Um damit ein für allemal aufzuräumen,
haben wir uns entschieden, eine USB over network Software (eine
kommerzielle Shareware) einzusetzen, die alle USB devices eines
Opfers per Netzwerk freigibt. Der böse Hacker soll die dann
übernehmen, und die zuvor gesnifften Infos zur PIN zum Missbrauch
der fremden Identität benutzen. Es war uns wichtig, das ganze so
simpel wie möglich zu realisieren. Das Resultat ist im Video
ersichtlich.
|
SuisseID / Smartcard USB Takeover from Max Moser on Vimeo. Ein Proof of Concept Video, welches einen erfolgreichen Angriff gegen die SuisseID mit dem Einsatz einfachster Mittel demonstriert. Mehr Details unter http://www.remote-exploit.org. |
Eingesetzt wurde das populäre Metasploit Framework (mit bestem Gruss an H.D. Moore und die Mitstreiter) sowie einige Meterpreter-Scripte welche die Software hochladen und installieren. (Im Video sind die auch ersichtlich). Danach war der "Angriff" eigentlich schon vorbei, denn der Keylogger ist ja schon fester Bestandteil von Metasploit und überhaupt ... c'mon 6-7 Zeilen thats all. Übrigens wenn jemand Zeit und Lust hat kann er gerne das Opensourceprojekt usbip.sourceforge.net unterstützen und eine schlankere Lösung bauen, denn remote zugriff auf USB Geräte ist zwar nichts neues aber dennoch nett.
Viel mehr Bedenken hatten wir als wir die Signiersoftware SwissSigner und E-gov Local Signer "Angeschupst" hatten. Die SuisseID soll die Grundlage für eine rechtsgültige elektronische Unterschrift darstellen. Wir waren überrascht als wir festgestellt hatten dass beide Java Applikationen das Signieren von Javascript in PDF Dokumenten ohne meckern zuliessen obwohl dieser Code nicht interpretiert oder gerendert wurde. Schnell was ein PDF geschrieben und Signiert.
Das original signierte Dokument ist unter http://www.remote-exploit.org/content/sigdemo.pdf
zum Download verfügbar. Der Effekt kann im Acrobat Reader
betrachtet werden indem man Javascript unter Einstellungen an oder
ausschaltet.
Abhängig von der verwendeten Software (SwissSigner, Egov Signer oder Acrobat) sieht das Dokument anders aus. Das traurige an der Geschichte ist, dass die Signatur unter gewissen Umständen sogar in Takt bleibt. Das heisst, ja mann kann es erkennen dass es modifiziert wurde aber das Problem ist doch gar nicht die Signatur an sich sondern, in diesem Fall das Rendering. Genau... Elektronische Zaubertinte! Traurig dabei ist, dass laut SwissSign selber das Produkt SwissSigner ALLE rechtlichen Anforderungen erfüllt. http://swisssign.com/en/produkte/swiss-signer.
|
|
|
||
| Screenshot eines Kaufvertrages innerhalb der SwissSigner Applikation. Ein schönes und intaktes Mofa ist auf dem Bild zu sehen. | Das selbe Dokument innerhalb des Acrobat readers. Da hier der signierte Javascript gerendert wird, ist nun ein Wrack gekauft statt des tollen Mofas. |
Aus unserer Sicht fehlt hier jegliche Grundlage um eine "Unveränderbarkeit" des Dokumentes zu belegen, weil schon vor der Unterschrift die Dokumente, abhängig von der Software anders aussehen??? ÄÄÄHHHH wir sind keine Rechtsanwälte aber ist denn sowas überhaupt erlaubt? Und wenn wir den Loop machen zum Leser: Warum ist es in Deutschland anscheinend so, dass der nPA mit dem Klasse1 Leser nicht für die Signatur gültig sein wird? Warum ist es aber anscheinend bei uns so ok?
Wir haben uns auch ganz generelle Fragen gestellt:
Weitere Details und Ausführungen findet man in unseren Slides des Talks. Wir hoffen damit wieder ein wenig Common-Sense in den Umlauf gebracht zu haben sodass man qualifizierter über grundlegende Themen sprechen kann.
Ohh und noch explizit für unseren Lieblings Troll, hier ganz deutlich: Die Signaturverifikation ist nur unter gewissen Umständen identisch. Es kann nämlich wie an unserem Talk erwähnt die Verifikation wiederholt werden oder explizit "Show signed version" im Acrobat angegeben werden und Zack sieht man das richtige Mofa... Jepp, wie oben schon beschrieben, es handelt sich um eine Differenz in der Renderengine bzw. ob Javascript gerendert wird oder nicht. Aber unabhängig vom renderer sollte der Signer NIE dynamische Dateien Signieren sondern erst in ein statisches Format umwandeln und das ist die Diskussion.