gallia: An Extendable Pentesting Framework
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
Titel |
| |
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 | 10.5446/61521 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
|
FOSDEM 202340 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
MaßerweiterungSoftwaretestDomain <Netzwerk>Multiplikationsoperator
00:19
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
09:39
SoftwaretestDatensatzKonfigurationsraumZeichenketteSynchronisierungSoftwareGruppenoperationMessage-PassingSchaltwerkDienst <Informatik>PROMIndexberechnungKugelkappeGeradeBitrateSoftwaretestBimodulKeller <Informatik>Coxeter-Gruppe
10:48
ATMNichtlinearer OperatorSechseckDienst <Informatik>BimodulEndliche Modelltheorie
11:13
Meta-TagMatrizenrechnungReverse EngineeringEndliche ModelltheoriePunktSoftwaretestMatrizenrechnungDifferentePortscannerDienst <Informatik>CodeGoogolBus <Informatik>RückkopplungKette <Mathematik>DatenbankSpeicheradresseSchnittmengeAggregatzustandReelle ZahlBefehlsprozessorFuzzy-LogikBimodulDatensatzVirtualisierungHalbleiterspeicherInformationsspeicherungBitComputeranimation
14:16
Verhandlungs-InformationssystemProgramm/QuellcodeComputeranimationFlussdiagramm
Transkript: Englisch(automatisch erzeugt)
00:05
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.
00:22
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,
00:41
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
01:02
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.
01:22
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
01:41
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.
02:01
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
02:22
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
02:41
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
03:00
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.
03:25
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
03:42
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.
04:02
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.
04:23
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.
04:41
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.
05:02
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
05:20
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.
05:41
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.
06:03
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.
06:22
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
06:41
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.
07:01
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
07:22
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.
07:40
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.
08:01
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,
08:20
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.
08:42
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.
09:03
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.
09:22
I will conclude with a short demo. It can be downloaded on this link. But I brought it here, and I will play it.
09:42
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.
10:03
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.
10:21
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,
10:43
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,
11:05
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.
11:21
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.
11:47
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.
12:01
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
12:23
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,
12:42
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
13:02
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,
13:23
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.
13:41
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.
14:03
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.
14:22
Thank you.