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 ? Vielen Dank im Voraus. Gruss Soriano
> Penetration Test
Da misst man die Eindringtiefe. Also laesst das Teil von 100m oder so
fallen und schaut wie weit es in den Boden oder so eindringt.
Sowas misst man vieleicht mit Projektilen..
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?
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.
Soriano B. schrieb: > Hallo, > Hat Irgendjemand Erfahrungen mit Penetration Test an einem Embedded > System? Pentest bezieht sich auf Software bspw wie dringe ich über einen Webserver in das OS ein. Auf welcher Hardware die zu penetrierende Software läuft ist egal.
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?
Dann einfach alle Einfallpunkte durchgehen. Die Funkschnittstellen sind das hauptsächliche Einfalltor. USB&SD braucht physikalischen Zugriff, Funk nicht. Also testen ob man z.B. via Bruteforce mit einem Notebook oder Smartphone ins WLAN bzw. Bluetooth kommen kann. Wenn Dir das Protokoll bekannt ist kannst Du das als Einstiegspunkt nehmen. Wirklich sicher wird's nie ...
??? 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.
Arc N. schrieb: > 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." 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 Stichworte für die Suche nach Schutzmassnahmen für Embedded *Anti tamper *TEMPEST *side channel attacks *Van Eck phreaking Heinz L. schrieb: > Embedded PenTesting läuft teilweise ganz anders ab als herkömmliches. Eben, deshalb nennt man es auch nicht pentesting. MfG,
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.
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. http://www.infineon.com/dgdl/Visibility+Campaign+Augsburg.pdf?fileId=5546d46149a28bd10149a44fd3960009 Die werden dann vom BSI zertifiziert die wiederum den TÜV den Chip auf Verletzbarkeit testen: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte/Reporte08/0827a_pdf.pdf?__blob=publicationFile&v=1 Die halten auch ab und zu Vorträge an der FH Augsburg, vielleicht schicken dir die ein script zu. Auf die schnelle hab ich nur was zu mobilen Geräten gefunden, nicht embedded: https://www.unibw.de/code/ergebnisse/speeches/kickoff/workshop4/at_download/file MfG
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.
Arc N. schrieb: > "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. Nein das ist nicht das gleiche. In der definition steht deutlich "über das Internet ... zugreifen". Also ohne "körperlichen" Zugriff auf das Gerät. Wobei man elektromagnetische Ab/Einstrahlung auch zu den "körperlichen" Zugriffsmöglichkeiten zählt. Vielleicht kann man es auch so zusammenfassen: -Pentest -> Software hacking -embedded devices -> hardware Hacking Oder noch abstrakter so: beim Pentest "denkt" das System vor man wäre ein berechtigter User oder man benötigt für die Aktion keine besondere Rechte, während man bei embedded hacking das system mit physischer "Gewalt" seinen Willen aufzwingt. Im zwischenmenschlichen Bereich wäre das der Unterschied zwischen "Betrug/Aufschwatzen/social engineering" und "Gewaltsamer Raub". ;-) MfG PS: Auch timing seitenkanal benötigt direkten Zugriff (auf Ein- und Ausgangs-"port/kanal") um wirklich die Rechendauer zu messen und nicht Paketlaufzeiten. Und die Laufzeit der Software ist leicht fixierbar (intervall timer zur Audgangsausgabe). Um das auszuhebeln kann man die Stromaufnahme der CPU messen - und das geht nicht ohne physischen Zugang.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.