wow. ich bin baff.
man stelle sich vor: da bauen die beim amerikanischen voting-equipment hersteller sequoia ein e-voting-gerät, das keinen code aus dem RAM laufen kann, um zu verhindern, dass die maschine gepwnd [1] wird. das klingt nach einer ausgezeichneten sicherheitsmaßnahme, oder?
im sequoia AVC advantage, einem kleinen, feinen, rund 10 jahre alten e-voting-gerät, ist dafür extra hardware eingebaut, die verhindert, dass code aus dem RAM ausgeführt werden kann. das sollte reichen, oder? wie in aller welt kann man da noch manipulieren?
doch wieder einmal zeigt sich, dass mit ausreichend kreativer intelligenz jede noch so sicher scheinende maßnahme geknackt werden kann:
schritt 1: analysiere den code im ROM, und finde alle “return”-statements am ende von subroutines. diese springen bekanntlich an die adresse, die im stack ganz obenauf liegt.
schritt 2: schau dir an, was die letzten paar instruktionen vor den “return”-statements machen.
schritt 3: konstruiere die malware, indem du sie aus kombiniationen von kleinen codeblöcken aus diesen letzten paar instruktionen vor dem return zusammenbaust.
schritt 4: konstruiere einen stack mit return-adressen, die dafür sorgen, dass der prozessor der reihe nach die blöcke von instruktionen vor dem return abarbeitet. mit jedem erreichen eines “return”-statements wird der nächste code-block angesprungen.
schritt 5: finde eine buffer-overflow-vulnerability und nutze sie, um den stack mit diesem satz an adressen zu füllen.
im konkreten fall ist es gelungen, eine vote stealing software zu konstruieren, die die maschine ganz normal erscheinen lässt, die wahl jedoch entsprechend eines voreingestellten ergebnisses fäscht.
die ironie der sache: einige amerikanische bundesstaaten haben ihre sequoia AVC advantage verkauft (die dinger sind 10 jahre alt) – was auch die basis zur entwicklung dieses hacks war – anderer bundesstaaten verwenden das gerät nach wie vor…
.
Verfasst von marc 
46halbe
electrobabe
LX_T
marc
sailormeni
scolytus
