We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

gallia: An Extendable Pentesting Framework

00:00

Formale Metadaten

Titel
gallia: An Extendable Pentesting Framework
Serientitel
Anzahl der Teile
542
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Gallia is an extendable pentesting framework with the focus on the automotive domain. The scope of the toolchain is conducting penetration tests from a single ECU up to whole cars. Currently, the main focus lies on the UDS interface. Acting as a generic interface, the logging functionality implements reproducible tests and enables post-processing tasks. This work was partly funded by the German Federal Ministry of Education and Research (BMBF) as part of the SecForCARs project (grant no. 16KIS0790).
14
15
43
87
Vorschaubild
26:29
146
Vorschaubild
18:05
199
207
Vorschaubild
22:17
264
278
Vorschaubild
30:52
293
Vorschaubild
15:53
341
Vorschaubild
31:01
354
359
410
MaßerweiterungSoftwaretestDomain <Netzwerk>Multiplikationsoperator
Meta-TagDemo <Programm>SoftwarewartungMatrizenrechnungComputersicherheitFormale SpracheSoftwaretestModul <Datentyp>Physikalisches SystemSimulationComputerGewöhnliche DifferentialgleichungSoftwareProtokoll <Datenverarbeitungssystem>Keller <Informatik>Virtuelle MaschineWeb logVerzeichnisdienstDatenstrukturInterface <Schaltung>Architektur <Informatik>Dienst <Informatik>DateiformatVirtuelle RealitätCLIKontrollstrukturSchnittstelleComputervirusSkriptsprachePrimzahlzwillingeZufallszahlenDefaultSynchronisierungPunktRechnernetzDatenverwaltungPlug inEndliche ModelltheorieYouTubePhysikalisches SystemProgrammierungSoftwarewartungZweiComputerarchitekturBimodulsinc-FunktionCLISpeicherabzugComputersicherheitPunktProtokoll <Datenverarbeitungssystem>Projektive EbeneCybersexPlug inDemo <Programm>NeuroinformatikAutorisierungKreisprozessSoftwaretestInformationElektronische PublikationVirtualisierungService providerDatenverarbeitungssystemDifferenteDienst <Informatik>CAN-BusVerzeichnisdienstMereologieMetadatenMultiplikationSoftwareMultiplikationsoperatorParametersystemDatenstrukturDistributionenraumKeller <Informatik>ImplementierungOrdnung <Mathematik>TopologieCodeDatenverwaltungKartesische KoordinatenATMVerzweigendes ProgrammNichtlinearer OperatorURLModul <Datentyp>Interface <Schaltung>Kontrast <Statistik>AbstraktionsebeneKlasse <Mathematik>ComputersimulationFortsetzung <Mathematik>Leistung <Physik>Zentrische StreckungE-MailEndliche ModelltheorieSinusfunktionSatellitensystemDatenloggerAggregatzustandProdukt <Mathematik>VerschlingungVirtuelle MaschineSoftwareentwicklerKonfiguration <Informatik>Physikalischer EffektArithmetisches MittelIndexberechnungVersionsverwaltungGeradeZeichenketteTaylor-ReiheOffice-PaketProgrammierspracheFlussdiagramm
SoftwaretestDatensatzKonfigurationsraumZeichenketteSynchronisierungSoftwareGruppenoperationMessage-PassingSchaltwerkDienst <Informatik>PROMIndexberechnungKugelkappeGeradeBitrateSoftwaretestBimodulKeller <Informatik>Coxeter-Gruppe
ATMNichtlinearer OperatorSechseckDienst <Informatik>BimodulEndliche Modelltheorie
Meta-TagMatrizenrechnungReverse EngineeringEndliche ModelltheoriePunktSoftwaretestMatrizenrechnungDifferentePortscannerDienst <Informatik>CodeGoogolBus <Informatik>RückkopplungKette <Mathematik>DatenbankSpeicheradresseSchnittmengeAggregatzustandReelle ZahlBefehlsprozessorFuzzy-LogikBimodulDatensatzVirtualisierungHalbleiterspeicherInformationsspeicherungBitComputeranimation
Verhandlungs-InformationssystemProgramm/QuellcodeComputeranimationFlussdiagramm
Transkript: Englisch(automatisch erzeugt)
So hello, everybody. Today I'm going to talk about something I've been hacking on for quite some time now. It is called Galia, and it is an extendable pen testing framework, mainly in the automotive domain. My talk is structured like this.
It is divided into four parts. I will start with some metadata about me and the project. Then I will give you an overview of the status quo. I will conclude with an outlook, and I hope we have some time for a little short demo. So that's me. On the left-hand side, you see my avatar,
and you might have spotted me on GitHub. I'm Stefan, and I'm a security researcher, and I'm the maintainer of Galia. So what is Galia? Galia stems from the SecForCast project. It was a research project, and we received some funding. On the YouTube link, you can see a little demo
we prepared last year. Galia is implemented in the Python programming language, and we support the latest version, minus one, that is currently the 3.10 release. It is free software, and it is available on GitHub. It is licensed under Apache 2.0.
And we have two maintainers. The second maintainer hides in the audience. If you have questions, we have been around here for some time. And it aims to be a modular tool for automotive penetration tests. So what is this? According to Wikipedia, a penetration test
is an authorized simulated cyber attack on a computer system performed to evaluate the security of the system. And that basically means we connect our computer to a car or an automotive ECU, and we send some data. And we keep on sending data until it breaks.
And hopefully, it breaks. And then we try to figure out what we did in order to break it. And after such tests, the lab usually looks like this. What are the challenges to actually achieve this? The reason why Galia exists is
that we were doing some penetration testing, and we needed a protocol stack for this. And in the automotive domain, there's usually the UDS protocol that stands for Unified Diagnostic Services. And you can think of it as the HTTP of automotive
with the difference that UDS is stateful in contrast to a stateless protocol. Of course, we need post-processing, which means machine-readable locks. In order to analyze data, everything needs to be reproducible. We solve this by a defined directory structure
for artifacts. And of course, the automotive guys are very, very creative in implementing network protocols. That means if you do expect an answer, the ECU doesn't answer. If you expect no answer, the ECU does answer. And that's quite a challenge. And that's why we decided to write our own protocol stack.
Since the automotive industry loves proprietary software and we do want to release the core of Galia, we created a plug-in interface where we maintain our own proprietary plug-ins in our own infrastructure, which plugs nicely
into the GitHub code. And of course, we need the whole software stack to achieve these goals. So we did write a whole implementation of the UDS stack. And the status quo is like this.
Usually, you plug it in into the OBD port of your vehicle. OBD stands for onboard diagnosis. And several ECUs might be exposed on that port. And you can use Galia to discover this whole tree. For example, there might be three ECUs available. And each ECU has different modes of operation.
These are called UDS sessions. Galia can also discover these. And each session might also provide different UDS services. And what a UDS service does is up to the manufacturer of the ECU.
It can be getting parameters. It might be setting parameters. It might even be software updating. The UDS standard defines just some basic facts what this actually is. And it could be everything, basically.
Galia came as a CLI tool. And you can think of it as the nmap for cars. We provide some ready-to-use scanning modules. For example, the discovery I already showed. And there are also modules to investigate these modules
further. We have an UDS stack, including DoIP or IOTP. These are little transport protocols beneath UDS, since UDS is on the application layer. DoIP, for example, is on top of TCP. IOTP is on top of the CAN bus.
And you can use all these setups. The next one is that we are able to do some automation. If you're testing some ECU on its own, you can power cycle it during a scan. We power cycle the whole setup before each scan and so on.
And of course, we have machine-readable logging, which comes as JSON logging and SQL logging. The SQL module is quite interesting, since it can be used to query logging information across different or multiple ECUs.
And for development, we offer a virtual ECU module. The core concept of Galia is a test run. It is basically the invocation on the command line until it finishes. And it always creates a directory structure, which is always the same, and which
contains some artifacts which can be used for scripting or similar. And the artifact still always contains log files, always contains PCAP files, and it might contain something else. The software is basically structured like this.
There is a core module, which can be extended via plugins. And you can build standalone modules, or you can integrate into the CLI system. Basically, the architecture is like this. The main entry point is the scanner on top, which contains a module for optionally
controlling power supplies. And it contains a abstraction module for an ECU, which uses the whole UDS protocol stack. And the protocol stack also can be extended via plugins. And these plugins might look like this. This is a Hello World module.
Basically, you create a class in Python. You need to implement the main method, which could be basically anything. And then you plug it into an entry point, and that's basically it. Some random facts. We use poetry for dependency management.
And in order to maintain a modern Python code base, asyncio and async await is used everywhere. It is fully typed. It passes mypy strict. It is extendable, as mentioned, via the Python entry point API. And for configuring the protocol stack,
we use some URL strings, which are verified by the pydantic module. Yesterday, there was a great talk about the pydantic module if you're interested in this. So let's give some little outlook. Of course, we need more power supplies.
We need more transport modules. We need also more scanner modules. And also, we need extending the scope. We need more plugins, scanning techniques, and so on. And of course, more breakage, and more memes, and more testing. And we need more packages. Currently, there is a package for the Arch Linux distribution.
We have an AUR package. And it is included in the Nix OS distribution in the unstable branch. And if you're a package maintainer and if you're interested in this, just create a package, file a ticket on GitHub. And we will be glad to include this in the readme file.
I will conclude with a short demo. It can be downloaded on this link. But I brought it here, and I will play it.
Sorry. Okay. What we can see here is a tmux session with two tabs. On the first tab, we will start a virtual ECU, which is a testing device we will run Galio against. And on the second tab, we have the command line invocation.
Here we have the configuration of the network stack. We have a transport module called TCP lines, which basically sends ASCII strings as TCP, on top of TCP. We use this for debugging and testing. We have an artifacts here where all the logging is placed.
And we try to discover what actual UDS services this ECU exposes. When you start it, it starts dumpcap, which records all the network traffic. Then Galio synchronizes with the ECU, which means it sends a test the present packet,
that's something like a ping message. And when the pong arrives, the scanner starts, and it iterates over the ECU. And in this example, we have found a mode of operation. This session, hex 52. And several services are exposed in this session,
which can be exposed, which can be scanned further with other scanning modules. Now I have finished with my talk. Thank you very much for your attention.
And if there are any questions, I will be happy to ask, to answer them. Yes, thank you, Stefan. So we have sometimes four questions here.
Hi, thank you for your talk. Can you say anything about fuzzing or memory scan, what you did there? We have some very basic fuzzer. It is included in the GitHub code.
It is a PDU fuzzing, but it just generates random data, and you don't have any feedback loop for this, since this is quite complicated. To implement for a car in a generic manner. Internally, we have some more sophisticated fuzzing modules, but we are not allowed to publish them
because of the NDA stuff, unfortunately. For the memory scan, there are a few services, blah, blah, blah, by memory address. We have discovery modules for this published on GitHub, but they actually discover endpoints,
and that's basically it. So I've done a lot of testing and reverse engineering, and you need a matrix of tests of what you're testing against, and the thing. So I was just wondering, for fits and giggles, how have you, is this virtual CPU sufficient
to actually plug it into the bus and actually run the car? Maybe not. Because then it would be accurate enough to be able to be tested as a real world, as MCU. I hope I did understand the question correctly,
but our virtual ECU module offers a possibility to clone ECUs, so we can just record traffic and store this in the database, and it just answers what it has seen recently.
But it does not cover any state. The idea was that the virtual CPU is actually sufficient to replace the ECU in the car and drive the car, and that would give the enough accuracy of the ECU to be able to be tested.
Maybe it's a bit too much, but. Yeah, that's not in the scope of Gator IFU. Okay, thank you, Stefan. Thank you for listening, and feel free to ask questions outside. Full speaker there.
Thank you.