Penetration Test on Embedded Device

So pauschal kann man das glaube ich nicht sagen (jedenfalls wenn du 
Security meinst). Welche Schnittstellen und Protokolle hast du denn?

Gruß
Dennis

P.S.: es gibt einige "Standards" die sehr teuer sind.

Dennis S. schrieb:
> So pauschal kann man das glaube ich nicht sagen (jedenfalls wenn du
> Security meinst). Welche Schnittstellen und Protokolle hast du denn?
>
> Gruß
> Dennis
>
> P.S.: es gibt einige "Standards" die sehr teuer sind.

Welche Standards? Mir ist nur bekannt, dass solche Tests z.B. im Rahmen 
der ISO 27001 gemacht werden.

Ansonsten ist die Frage was der TO da genau testen will bzw. auf welcher 
Ebene: Passive oder aktive Angriffe. Reverse Engineering erlaubt (der 
Firmware oder sollen ICs abgeschliffen werden und deren Funktion 
rekonstruiert werden), Logikfehlertests (der Protokolle), 
Seitenkanalangriffe z.B. Differential Power Analysis oder kombinierte 
Angriffe wie Fault Injection zusammen mit DPA?

https://www.owasp.org/index.php/OWASP_Embedded_Application_Security

Soriano B. schrieb:
> Hallo,
> Hat Irgendjemand Erfahrungen mit Penetration Test an einem Embedded
> System?
> wie geht man da vor ? hat Irgendjemand einen Leitfaden oder so was
> ähnliches ? was muss man da beachten ?

Das dürfte entscheidend davon abhängen:

1.) welche Schnittstellen das System nach außen hin hat
2.) an welchem Ort es sich befindet

Ein System, das nicht an ein Netzwerk (z.B. Internet) angeschlossen ist, 
kann auch nicht über dieses Netzwerk gehackt werden.

Bei einem Geldautomaten zum Beispiel ist sicher auch interessant, ob man 
physikalisch vor Ort drankommt und etwas manipulieren kann. Bei einem 
Steuergerät auf einer Ölbohrinsel in der Arktis kann man einen 
Vor-Ort-Angriff wohl eher ausschließen.

Nö-Sager schrieb:
> Soriano B. schrieb:
>> Hallo,
>> Hat Irgendjemand Erfahrungen mit Penetration Test an einem Embedded
>> System?
>
> Pentest bezieht sich auf Software

Nein, da es je nach Anwendung schlicht nicht reicht nur die Software zu 
testen.
Ähnlich zu Metaploit und anderen Frameworks gibt es für Hardware z.B. 
http://hardsploit.io/the-project/

> bspw wie dringe ich über einen
> Webserver in das OS ein. Auf welcher Hardware die zu penetrierende
> Software läuft ist egal.

Nein. Beispiel: Software x nutzt die Hardware-Verschlüsselungsfunktionen 
eines Controllers. Test könnte z.B. eine Power Analysis sein, die 
aufdeckt, dass diese Hardware-Implementierung die Schlüssel leakt 
(Firmware könnte damit bspw. ausgetauscht und das Gerät übernommen und 
weiteres angestellt werden)

Schönes Beispiel:
http://www.cs.tau.ac.il/~tromer/acoustic/
"The attack can extract full 4096-bit RSA decryption keys from laptop 
computers (of various models), within an hour, using the *sound 
generated by the computer* during the decryption of some chosen 
ciphertexts."

Beliebt sind auch timing-leaks wo auf einigen Hardwareimplementierungen 
Schlüssel ermittelt werden können indem die Laufzeiten verschiedener 
Zweige nachverfolgt werden. Häufig ließen sich so auch lange und 
komplexe Keys in endlicher Zeit ermitteln.

Embedded PenTesting läuft teilweise ganz anders ab als herkömmliches. 
Auch weil man es selten mit general purpose hardware zu tun hat.

Mark B. schrieb:
> 1.) welche Schnittstellen das System nach außen hin hat
> 2.) an welchem Ort es sich befindet

Das System ist so ähnlich wie ein Bordcomputer in einem Bus mit 
Druckfunktion.
er besitzt folgende Schnittstellen: WLAN, Bluetooth, USB, SD-Karten 
Slot.

Wie wärs wenn du mal bei einschlägigen Instituten anfragst, z.B. das 
Fraunhofer?

??? schrieb:
> Dann einfach alle Einfallpunkte durchgehen.
> Die Funkschnittstellen sind das hauptsächliche Einfalltor.

Dies.

Also zum Beispiel mal mit einem Tool wie Wireshark den Datenverkehr 
mitschneiden zwischen dem Gerät und einer Gegenstellle, und nachschauen 
ob da irgendwas im Klartext übertragen wird was besser verschlüsselt 
sein sollte. Zum Beispiel Passwörter.

Wenn Dienste aktiv sind, die nicht aktiv sein sollten - zum Beispiel 
telnet - dann diese deaktivieren. Hierfür kann ein Portsniffer hilfreich 
sein.

Soriano B. schrieb:
> Hat Irgendjemand Erfahrungen mit Penetration Test an einem Embedded
> System?

Ich habe auf diesem Gebiet berufliche Erfahrung und Kontakte.


Einen Leitfaden oder Dinge die "zu beachten" sind gibt es so pauschal 
nicht. Das ist jedes mal ein individueller Vorgang, der mit dem Kunden 
abgestimmt werden muss. Vor dem Pentest sollte beispielsweise erstmal 
eine Bedrohungsanalyse erfolgen, damit festgehalten wird, WAS denn genau 
getestet werden soll. Insgesamt ist das ganze KEINE einfache Sache die 
man mal schnell selbst erledigt. Erfahrung auf dem Gebiet muss auf jeden 
Fall da sein, da gibt es unglaublich viele Fallstricke. Ganze Firmen und 
Institute leben davon.

Wenn du Interesse hast, einen PROFESSIONELLEN Pentest durchführen zu 
lassen, dann schreib mich bitte über das Forum an, dann kann ich einen 
Kontakt herstellen.

Johannes O. schrieb:
> Ich habe auf diesem Gebiet berufliche Erfahrung und Kontakte.
>
> Einen Leitfaden oder Dinge die "zu beachten" sind gibt es so pauschal
> nicht. Das ist jedes mal ein individueller Vorgang, der mit dem Kunden
> abgestimmt werden muss. Vor dem Pentest sollte beispielsweise erstmal
> eine Bedrohungsanalyse erfolgen, damit festgehalten wird, WAS denn genau
> getestet werden soll. Insgesamt ist das ganze KEINE einfache Sache die
> man mal schnell selbst erledigt. Erfahrung auf dem Gebiet muss auf jeden
> Fall da sein, da gibt es unglaublich viele Fallstricke. Ganze Firmen und
> Institute leben davon.
>
> Wenn du Interesse hast, einen PROFESSIONELLEN Pentest durchführen zu
> lassen, dann schreib mich bitte über das Forum an, dann kann ich einen
> Kontakt herstellen.

Danke für's Angebot, ist aber leider nicht möglich, da es nur um ein 
Master-thesis geht.
Wie ist es mit der Bedrohungsanalyse? wie geht mann hier vor?
ich hoffe, dass Sie mir trotzdem paar Tipps geben würden.

Was erst mal wichtig ist, ist zu wissen was überhaupt das Szenario ist. 
Es gibt zum Beispiel jede Menge Deppen die es für ein Problem halten, 
wenn jemand seine eigene Firmware auf ein Gerät spielen kann wenn man 
physikalischen Zugriff hat. Eigenen Code in das Gerät über die 
Webschnittstelle ausführen zu können kann aber ein großes Problem sein, 
oder es kann sogar relativ egal sein.

Also mach Dir erst mal Gedanken darüber, was du schützen willst, dann 
arbeite sich davon runter auf die Dinge die Du überprüfen willst.

Soriano B. schrieb:
> Wie ist es mit der Bedrohungsanalyse? wie geht mann hier vor?
> ich hoffe, dass Sie mir trotzdem paar Tipps geben würden.

Also kurz gesagt machst du folgendes:
Du betrachtest dein Gerät und dessen Einsatzgebiet. Dann stellst du dir 
die Frage, welche Gefahren (im weiteren Sinne) bestehen und wer 
Interesse an Manipulationen oder Informationen hätte. Da kannst du dann 
noch ein Angreifermodell aufstellen.

Ich mach mal ein paar kurze Beispiele für Bedrohungen:

- Ein Mitbewerber könnte versuchen, euer Gerät zu klonen oder 
irgendwelche Algorithmen zu extrahieren, die ihr zur Datenverarbeitung 
verwendet. D.h. es geht hier um den Schutz geistigen Eigentums.

- Ein Angreifer könnte versuchen, übers Internet Zugang zu deinem Gerät 
zu bekommen (beispielsweise über schlecht abgesicherte Schnittstellen / 
Fernwartung etc.) um Schaden zu verursachen. Der Angreifer könnte 
beispielsweise
 * das Gerät durch Fehlkonfiguration zerstören
 * irgendein Produktionssystem lahmlegen
 * die Qualität deiner Produkte verringern
 * das Gerät als Zwischenpunkt verwenden, um das Firmennetz weiter zu 
infiltrieren.
 * usw. usw.

- Ein Angreifer könnte versuchen, dein Gerät zu modifizieren um 
Erweiterungen ohne Bezahlung/Lizenz freizuschalten (sofern bei dir sowas 
angeboten wird).

Da ist noch viel mehr denkbar. Kommt ganz auf deine Anwendung drauf an. 
Da kann einiges wegfallen (beispielsweise Bedrohungen über das Internet, 
wenn du gar keinen Netzwerkanschluss hast), aber auch was dazukommen 
(beispielsweise Schutz der Daten verschiedener Benutzer untereinander, 
bei einem multi-user system).

Als nächstes kannst du noch ein Angreifermodell aufstellen:
Beispielsweise verfügt ein Mitbewerber üblicherweise über große 
finanzielle Möglichkeiten, technisches know-how, große finanzielle 
Motivation usw.
Ein Angreifer wie im letzten Fall ist ein Endanwender und versucht das 
beispielsweise nur mal kurz, gibt aber schnell auf, wenn es nicht 
klappt. Da ist die Motivation geringer und auch der Schaden bei euch 
nicht so groß (1 EVENTUELL verlorener Lizenzverkauf). Im ersten Fall, 
wenn das Gerät kopierbar ist, ist der potentielle Schaden viel größer.

Basierend darauf würde ich dann überlegen, was ich denn wirklich 
schützen will. Darf beispielsweise der Programmspeicher für einen 
Angreifer leicht erreichbar sein? Wie müssen Schnittstellen abgesichert 
sein? Dann würde man von einem weitgehend unabhängigen(!) Team die 
Sachen überprüfen lassen. Also keinesfalls von denen, die es schon 
implementiert haben.

Ansonsten würd ich aber mal sagen: Schreib doch mal, was du gemacht 
hast. Dann kann ich dir da eventuell ein paar Tipps geben.

Soriano B. schrieb:
> Danke für's Angebot, ist aber leider nicht möglich, da es nur um ein
> Master-thesis geht.

Welche Uni? Wenn es in NRW ist, mal an der RUB vorbeischauen. Die haben 
diverse Lehrstühle 
http://www.ei.ruhr-uni-bochum.de/fakultaet/professuren/, einen der 
wenigen IT-Sicherheitsstudiengänge in DE
und das Horst Görtz Institut für IT-Sicherheit
https://www.hgi.ruhr-uni-bochum.de/hgi/news/

Fpga K. schrieb:
>> Schönes Beispiel:
>> http://www.cs.tau.ac.il/~tromer/acoustic/
> Das ist aber kein Pentest sondern eine Side-channel attacke.
>
> Pentest sind hier gut definiert:
> 
https://www.internet-sicherheit.de/fileadmin/docs/downloads/andere_studien_dokumente/BSI/penetrationstest.pdf

"Ein Beispiel ist ein Penetrationstest bei dem gezielt geprüft werden 
soll, ob es unautorisierten Dritten möglich ist, über das Internet auf 
Systeme innerhalb des LANs des Unternehmens zuzugreifen."

Ob das jetzt auf "direktem" Weg bspw. mit einem Default-Passwort oder 
über einen Timing-Seitenkanal geht läuft aufs selbe hinaus: Zugriff ist 
möglich.

oder wie es das BSI formuliert "Technik
: Welche Techniken werden beim Testen eingesetzt?
Beim klassischen Penetrationstest werden die Systeme nur über das 
Netzwerk angegriffen.
Ergänzend können die Systeme auch mittels *sonstigen physischen 
Angriffen* ... attackiert werden"

und zu Seitenkanälen:

"--durch Umgehung dieser Systeme durch einen direkten physischen Zugriff
 zu erlangen. Hierzu zählt z. B. der direkte Datenzugriff an einer 
nicht-passwortgeschützten Arbeitsstation nach Erlangung von 
unberechtigtem Zugang in die Gebäude und/oder Serverräume."

Fpga K. schrieb:
> Kaj G. schrieb:
>> Wie wärs wenn du mal bei einschlägigen Instituten anfragst, z.B. das
>> Fraunhofer?
>
> Eher nicht. Kommerziel beackert (nur?) Infineon in Augsburg das Thema in
> bezug auf Chipkarten.
Nein.
Wir haben auch Geräte die vom BSI zertifiziert werden müssen 
(Verschlüsselung, Wie schützen wir bestimmte Hardwarebausteine, 
Sicherstellen der Funktionsuntauglichkeit nach Manipulation, usw.), und 
die Gutachten dazu, welche Anforderungen bestehen, Bedrohungs Szenarien 
etc. pp. stammen vom Fraunhofer SIT.
https://de.wikipedia.org/wiki/Fraunhofer-Institut_f%C3%BCr_Sichere_Informationstechnologie
https://www.sit.fraunhofer.de/

Alternativ würde ich noch die Ruhr Universität Bochum vorschlagen.