[00:55.600 --> 01:01.420]  Hey guys, you guys all ready to talk about some ATMs?
[01:01.420 --> 01:03.560]  Great, awesome.
[01:03.560 --> 01:04.380]  Thank you.
[01:04.380 --> 01:07.200]  This is my talk, Where's the Money?
[01:07.200 --> 01:09.480]  Defeating ATM Disk Encryption.
[01:09.860 --> 01:16.180]  My name is Matt Birch, and I am a principal research consultant with Tradus Partners.
[01:16.200 --> 01:31.900]  I have about 20 years of experience in the InfoSec community, and I am best known for some of my adversarial tooling affecting various MFA bypasses and various MDM solutions.
[01:31.900 --> 01:39.180]  And during the course of performing this research, I've actually had the opportunity to engage in some interesting opportunities.
[01:39.220 --> 01:51.740]  I've done some expert testimony in regards to a lawsuit against an ATM manufacturer, and I've gotten to dive into cartel-designed ATM black box devices.
[01:52.560 --> 02:04.960]  For today's talk, uh, I plan to briefly introduce the ATM industry, and then introduce, uh, Diebold Nixdorf's dynamic security suite software.
[02:04.960 --> 02:15.760]  We'll then dive a little bit deeper into the pre-boot authorization process of dynamic security, and finally wrap up with a little bit of cat and mouse.
[02:15.880 --> 02:18.900]  So, let's start off with the industry.
[02:19.220 --> 02:24.480]  So, the ATM market is essentially divided into two classes of systems.
[02:24.480 --> 02:28.060]  There are consumer and financial-grade platforms.
[02:28.060 --> 02:34.800]  Uh, the consumer-grade platforms are the low-level ATMs you see at your grocery store, at your gas station.
[02:34.840 --> 02:42.360]  Typically, they run Windows CE and lack a lot of the enterprise security controls that we're all familiar with.
[02:42.460 --> 02:49.260]  However, the enterprise-class ATM is the financial ATM platform.
[02:49.260 --> 02:53.540]  These are the ones that are specifically used by the financial industry.
[02:53.760 --> 03:11.400]  These devices run all Windows embedded, uh, usually Windows 10, uh, newer models are coming out with Windows 11, and they have the enterprise security controls that we're all familiar with, which are part of the proprietary software stack that's usually presented through the ATM manufacturer.
[03:11.680 --> 03:21.060]  In the United States, there are only three manufacturers of the financial platform, uh, which is HiSung, NCR, and D-Bolt, of course.
[03:21.700 --> 03:32.520]  When you crack open an ATM, regardless it being consumer or financial-grade platform, uh, the devices are, the systems are divided into two hemispheres.
[03:32.520 --> 03:41.720]  You have the top portion, or the top hat, which carries all the PC peripherals and components, uh, that allow the ATM to work.
[03:41.720 --> 03:48.740]  The bottom portion, also known as the bolt, uh, that's where all the cash cassette and system currency is located.
[03:48.920 --> 03:59.620]  Now, these two compartments are physically isolated from each other, but the physical security controls regarding entry vary drastically between the top and the bottom portion of the ATM.
[03:59.700 --> 04:16.580]  So the bottom portion is about an inch thick steel, it has a very heavy bolt locking mechanism, uh, it has multi-factor authentication with a digital, uh, I-key, uh, it has tamper detection, seismic alarms, etc.
[04:16.680 --> 04:37.060]  But the top hat, uh, is about one-eighth inch thick simple sheet metal, uh, has numerous vent holes for PC ventilation, system speakers, and the front of the ATM, it usually carries a lot of plastic components, uh, providing a very easy entry for, uh,
[04:37.060 --> 04:38.600]  destructive attacks.
[04:38.620 --> 04:53.220]  Uh, in addition to that, the locking mechanism, uh, involves a simple cantilever type system, where there's a cable hooked up to a couple latches that are on either side of the front of the ATM, that's connected to the solenoid of the lock, you turn the lock,
[04:53.220 --> 04:58.700]  it lifts, uh, pulls the cable, uh, lifts the latch, and you're able to get access to the ATM.
[05:00.180 --> 05:09.300]  And when you look at the attack vectors, uh, mostly affecting these platforms, there are, they all require some level of physical access.
[05:09.580 --> 05:27.380]  Uh, some of the traditional attacks are black box devices, these are placed inside or outside the ATM, uh, the goal is to manipulate the communications between the ATM and the banking network, uh, and get the system to try and dispense funds it's not supposed to.
[05:27.720 --> 05:34.960]  Uh, there's card skimmers, these are all designed to attack your card data as you insert into the ATM.
[05:35.180 --> 05:43.320]  And then some of my favorite attacks are the physical attacks, with the goal of getting access to the funds as quickly as possible.
[05:43.460 --> 05:54.200]  So this involves ripping the ATMs out of the ground, trying to blow the platforms up, uh, various levels of success in those type of attacks.
[05:54.620 --> 06:05.580]  And when we look at the landscape, uh, the ATM market is thousands of devices and all of them hold very large sums of cash.
[06:05.900 --> 06:14.680]  And despite the need of physical access, uh, criminal activity against these platforms has seen exponential growth over the last few years.
[06:15.240 --> 06:22.180]  Which is no surprise when we take a deeper look into the logical infrastructure of the platforms themselves.
[06:22.280 --> 06:32.480]  So most the technology of the ATM revolves around an unauthenticated API known as XFS or extension for financial services.
[06:32.480 --> 06:44.440]  And this is an agnostic API that's designed to allow, uh, simple hardware replacement with cash cassettes, uh, so there isn't any linkage to, uh, direct vendors.
[06:44.980 --> 06:55.580]  But, uh, as a result that API usually doesn't have authentication, so all you need to do is hook it and tell the ATM to dispense funds and it will go ahead and do so.
[06:55.580 --> 07:02.260]  In addition to that, the ATM software is usually executed in the context of high privilege.
[07:02.260 --> 07:12.520]  So most of the software on the ATM is running in the context of administrator, which is very easy to do elevated attacks against the soft, uh, the XFS API.
[07:12.520 --> 07:22.680]  In addition to that, there are a number of applications on the ATM that have various levels of administrative access.
[07:22.680 --> 07:34.300]  So there's the operator mode to control various functionality of the ATM, uh, that allows you to change the menu on the screen.
[07:34.380 --> 07:48.840]  There's also applications to give you access into, uh, access into the Windows operating system, uh, to do maintenance against the platform.
[07:48.840 --> 08:01.040]  And then, of course, the Windows operating app itself, all of which, uh, is typically configured with default credentials or default credentials are represented in the production deployments.
[08:01.040 --> 08:07.040]  All of this has made these platforms, uh, very attractive target for organized crime.
[08:07.540 --> 08:21.340]  And when we take a look at the ATM network, the ATM network is essentially a private, uh, private network environment where access is provided from a gatekeeper or a hosting provider.
[08:21.340 --> 08:33.700]  And these hosting providers install a piece of software on the ATM that allows that system to communicate to the network so you can withdraw funds, uh, from your banking institution .
[08:34.040 --> 08:43.940]  But not all ATMs are treated the same and there's usually a certification process in order to do that infrastructure.
[08:43.940 --> 08:52.020]  So the third party gatekeeper will certify the software and the hardware running on the ATM to provide access.
[08:52.020 --> 09:04.280]  This makes it very difficult for banking institutions to have ATM solutions from different manufacturers because the software stack isn't managed all together in the same way.
[09:06.140 --> 09:13.480]  Which brings us to Diebold Nixdorf and their proprietary Dynamic Security Suite software.
[09:13.720 --> 09:19.960]  Unlike the other ATM solutions, Dynamic Security has multi-vendor certification.
[09:19.960 --> 09:30.740]  This allows their software to be installed on any hardware stack and get certified access into the ATM hosting network.
[09:30.920 --> 09:42.960]  This has enabled Diebold to actually reach far beyond their hardware footprint and in 2015 they were observed to represent about 35% of the ATM market.
[09:43.320 --> 09:50.960]  And in 2018 and 19 they partnered with two of the largest financial institutions representing the U.S.
[09:50.960 --> 09:52.360]  gaming industry.
[09:52.560 --> 10:09.360]  Which means Diebold Nixdorf is not only in a majority of the ATMs that we're all familiar with, the software is actually running in most of the casinos across the United States too in the ticketing and cash out platforms.
[10:09.440 --> 10:13.060]  This also includes most of the casinos on the Vegas Strip.
[10:13.560 --> 10:20.500]  So now that we kind of have a general idea of the industry, let's take a look at Dynamic Security.
[10:21.880 --> 10:28.880]  Like many of the ATM security stacks, Dynamic Security has a number of standard security protections.
[10:28.960 --> 10:36.900]  There's USB filtering, firewall policy, tamper detection, and disk encryption of course.
[10:37.240 --> 10:41.100]  But it's not actually full disk encryption.
[10:41.360 --> 10:44.280]  So there are two unencrypted partitions.
[10:44.280 --> 10:51.840]  The first partition is EFI and this is pretty common in most enterprise system designs.
[10:51.840 --> 10:58.920]  It carries the bootloader and is used to initialize the operating system from the hardware.
[10:58.960 --> 11:04.300]  But what is less common is an unencrypted Linux partition.
[11:04.300 --> 11:08.100]  And that's somewhat of a red herring in this architecture design.
[11:08.460 --> 11:15.180]  And taking a closer examination of that, that Linux partition self-identifies itself as supers chaff.
[11:15.180 --> 11:35.700]  Now the details in Etsy version don't really have a lot of indication that can actually be designed to represent whatever the manufacturer wants, but it's usually a pretty good point to figure out what an operating system is or to be able to go back and do some online reconnaissance.
[11:36.060 --> 11:42.560]  Unfortunately, online reconnaissance of supers chaff Linux didn't come up with anything.
[11:42.560 --> 11:46.940]  But it did lead to a pretty cool game, Worms Armageddon.
[11:47.620 --> 11:51.180]  So Worms Armageddon is a really fun 2D shooter.
[11:51.180 --> 11:55.660]  You launch crazy projectiles against your opponents.
[11:55.700 --> 11:58.360]  They probably have it over there in the arcade.
[11:59.040 --> 12:05.460]  The game is a lot of fun, but it has absolutely nothing to do with ATMs at all.
[12:05.800 --> 12:22.660]  But what was interesting is the video I stumbled across for Worms Armageddon was a German translated video, which identified supers chaff was actually German for super sheep.
[12:22.660 --> 12:35.380]  Which also happened to be the installation directory where most of the configuration files of the Linux software stack was underneath the user directory path.
[12:35.600 --> 12:39.820]  Online reconnaissance of super sheep was significantly more rewarding.
[12:40.100 --> 12:48.980]  So in 2016, there was a blog article released by a consulting firm known as SecConsult.
[12:48.980 --> 13:01.800]  And in this blog article, they detailed a code execution path against a piece of software known as CryptWare, CryptoPro, and the underlining super sheep Linux operating system.
[13:02.080 --> 13:11.320]  There were a lot of similarities in this article and the platform I was looking at, except for the fact that their execution path didn't work.
[13:12.100 --> 13:38.880]  But it was interesting because I needed to draw a linkage or was interested in a if the platform actually was running CryptoPro, which led me to go back to D-Build's online resources, review license agreements, et cetera, which actually I stumbled across the user license agreement for version 3.0 of the software stack.
[13:39.060 --> 13:49.880]  In that license agreement, they detail a number of SBOM details and specifically designates CryptWare, CryptoPro as being a third-party licensed integrator.
[13:50.020 --> 14:06.900]  However, the references for CryptWare were limited, where it was only represented in version 3.0 and other versions of dynamic security then didn't have any reference, which was interesting.
[14:07.180 --> 14:10.820]  But anyhow, who is CryptoPro or CryptoPro?
[14:11.320 --> 14:17.260]  Well, it's a company that was founded in 2002.
[14:17.480 --> 14:32.440]  The goal of the organization was to enhance Microsoft's BitLocker and introduce a pre-boot authorization process into the encryption strategy to validate the integrity of the system before decryption occurs.
[14:32.660 --> 14:44.040]  Today, the organization is represented in numerous countries and every representation of the organization has a completely different domain reference.
[14:44.040 --> 15:00.200]  There is different marketing materials, there's different names for the same product, but what links all these disparate resources together are the location addresses for where their offices are.
[15:00.200 --> 15:10.540]  So you can actually back-reference from these various websites and it all links back to the same centralized organization.
[15:10.980 --> 15:17.440]  However, despite their suspicious online presence, they boast a very large customer install base.
[15:17.440 --> 15:19.940]  Over half a million licenses sold.
[15:20.080 --> 15:26.160]  And then they also self-designate that their customers love their encryption strategy.
[15:26.800 --> 15:27.860]  Okay, fair enough.
[15:27.860 --> 15:32.840]  Let's dive a little bit deeper into how their integrity process works.
[15:33.740 --> 15:57.440]  So, in dynamic security, on the D-bolt ATM, when the system leverages a dual-boot initialization cycle between Linux and Windows, first powering on the platform from UEFI, it'll launch Linux or SuperSheep, which does some black magic integrity validation against the system.
[15:57.440 --> 16:05.440]  If everything's executed successfully, it will shut down, go back to UEFI, and then launch Windows.
[16:05.440 --> 16:13.820]  Windows will perform an auto-logon with administrator, launch the ATM software stack, and then become fully operational.
[16:14.500 --> 16:28.100]  If you attempt to make any modifications to the unencrypted Linux partition, you're presented with an integrity error, designating the system has been tampered with and it's unable to successfully boot.
[16:28.500 --> 16:46.960]  But if you modify other content, a slightly different error message is presented, which contains slightly more detailed information, and identifies there are 253 elements that are validated on the disk.
[16:47.440 --> 16:48.020]  Okay.
[16:48.020 --> 16:51.020]  Well, that is pretty interesting.
[16:51.300 --> 16:54.960]  So, I just need to figure out what those elements are.
[16:55.900 --> 17:06.600]  Going back to the Linux partition, there's a very easily referenceable directory called log, right in the rootfs, which has a couple of some index files in there.
[17:07.100 --> 17:21.520]  However, those index files have about 2,500 files listed, which is significantly more than 253, but that's the only content reference that's observable within the Linux partition.
[17:21.740 --> 17:27.340]  Ultimately, the full file index of Linux is about 11,000 files.
[17:27.340 --> 17:36.040]  This gives us a delta of 8,000 potential files that may not be checked, that could be used to do something malicious.
[17:36.100 --> 17:45.300]  That's a pretty broad attack surface, and since we're modifying content, shutting down and rebooting a system, it's not very effective either.
[17:45.440 --> 17:49.560]  And also, most that content is generally benign.
[17:50.280 --> 17:56.720]  However, what I like to do in these situations are background images, or images in general.
[17:56.980 --> 17:59.240]  Generally, those aren't checked.
[17:59.240 --> 18:01.800]  No one really cares about background images.
[18:02.120 --> 18:09.560]  And there's also a really good visual indication when something's been modified on the system.
[18:09.600 --> 18:15.760]  So, their default logo is located in a couple different directory paths.
[18:16.040 --> 18:19.740]  Randomly pick one, modify it, and reboot the system.
[18:20.460 --> 18:23.240]  Initially, the default background image comes up.
[18:23.240 --> 18:23.940]  Bummer.
[18:23.940 --> 18:24.840]  You know, no big deal.
[18:24.840 --> 18:30.580]  Wait a few seconds, and we have modified the background image.
[18:31.300 --> 18:45.700]  This isn't a huge success quite yet, but it is an indication that the PBA process is not infallible, and there is opportunities to work around their detection mechanism.
[18:45.860 --> 18:53.680]  In addition to that, the background image is really helpful in mapping out how PBA is actually executed.
[18:54.320 --> 19:04.680]  Changing files in the disk using the background image, we're able to identify the integrity validation process to be carried out in different phases.
[19:05.040 --> 19:12.740]  Phase one is executed from UEFI, before the Linux operating system is initialized.
[19:12.760 --> 19:19.480]  That is where the 253 elements are validated as part of the boot XSA or boot XSA2 binaries.
[19:19.640 --> 19:22.400]  Pretty easy to extract that index table.
[19:22.400 --> 19:25.220]  Simple strings will get you the information.
[19:25.940 --> 19:32.620]  From there, once the integrity check has completed, Linux is initialized.
[19:33.020 --> 19:42.680]  In the initialization process of Linux, phase two is then executed, which validates the remaining 2500 files on the Linux disk itself.
[19:42.880 --> 19:54.060]  Those files are used as a measurement against the TPM to unlock it, and then recover the BitLocker disk encryption key, decrypt Windows, and continue to boot cycle.
[19:54.520 --> 20:00.720]  The most obvious attack path, of course , is compromising the EFI binaries.
[20:00.820 --> 20:05.180]  Unfortunately, the ATM employees secure boot.
[20:05.180 --> 20:13.400]  So, all the EFI files and the system's firmware itself are digitally signed and validated.
[20:13.400 --> 20:16.520]  So, there isn't an attack path to modify that content.
[20:17.200 --> 20:37.720]  But what we can do, is now that we're able to extract the phase one integrity check, we can compare that against the Linux initialization process, and look to identify any gaps in that procedure that may allow us to avert or bypass their detection mechanisms.
[20:37.720 --> 20:45.160]  So, the attack surface is to compromise the ATM in between phase one and phase two.
[20:45.580 --> 20:47.440]  Challenge accepted.
[20:47.500 --> 20:49.680]  Let's play cat and mouse.
[20:50.360 --> 20:56.000]  So, starting off in version 18.X of the software stack.
[20:56.320 --> 21:01.840]  In version 18.X, boot XSA2 is in EFI.
[21:01.840 --> 21:05.460]  That validates 253 elements on the disk.
[21:05.560 --> 21:11.360]  Linux is then initialized through Etsy in a tab, through the system V architecture.
[21:11.900 --> 21:16.320]  Upon completing that, Root then performs an auto logon.
[21:16.360 --> 21:25.240]  In that auto logon process, out of Root's profile script, that's where the call to initialize phase two of the integrity check occurs.
[21:26.300 --> 21:33.440]  Looking at the run state of Linux, uh, it employs several temporary file system out points.
[21:33.640 --> 21:40.980]  And those are used to establish a somewhat read only architecture of the platform.
[21:40.980 --> 21:47.120]  Uh, the contents for those temporary file systems are then populated from several tar archives.
[21:47.180 --> 21:52.280]  And those tar archives are also validated during phase one.
[21:52.360 --> 21:54.980]  Uh, so, not much attack surface there.
[21:56.200 --> 22:17.520]  But, taking a closer look at the system V initialization process and comparing that against the index table, we're able to map out the full Etsy initialization process and look for any import scripts or other executable calls that might be called during that process which are not properly checked as part of phase one.
[22:17.520 --> 22:23.000]  Ultimately, the Etsy initialization process is all validated pretty well.
[22:23.000 --> 22:25.900]  There is not much of an attack surface there.
[22:25.900 --> 22:31.400]  But, one file in particular was overlooked, which happened to be Etsy in a tab.
[22:31.580 --> 22:39.260]  Which is funny because that's the full, uh, initializer to the system V initialization process altogether.
[22:39.580 --> 22:55.020]  However, uh, now that we have our foothold, the next thing that we need to do is identify a staging directory that allows us to move content around on the disk and have a good , uh, working directory path.
[22:55.780 --> 23:05.560]  Super Sheep, uh, helps us out there where, uh, their phase two integrity process is configured to avoid indexing of most their install files.
[23:05.880 --> 23:17.100]  So, um, since the goal is system compromise and, uh, code execution, I figured what better directory to use than Super Sheep of Europe.
[23:18.080 --> 23:36.180]  So, um, all we have to do is clone the Etsy initialization process over to our new staging directory, patch global variables, uh, inject a call to the initialization of X, and then call our modified, uh, Etsy in a tab.
[23:37.360 --> 23:43.760]  Uh, with that, I have a demo for CVE-2023-24064.
[23:44.200 --> 23:50.660]  Uh, so, as part of this demo, I've virtualized the ATM platform in Proxmox.
[23:50.740 --> 23:55.200]  And initially powering on, we get an integrity failure.
[23:55.660 --> 24:02.480]  Shut down the system, patch the offline disk, and relocate Etsy initialization over to our staging directory.
[24:02.900 --> 24:10.760]  Once it powers back on, uh, and root performs a startup logon, uh, we get code execution and a callback.
[24:14.590 --> 24:16.550]  Alright, ATM's compromised, right?
[24:16.550 --> 24:18.130]  We have full control of Linux.
[24:18.790 --> 24:23.410]  Um, however, that doesn't get us all the way, right?
[24:23.410 --> 24:32.570]  So, Windows is still encrypted, um, which is a good challenge or, uh, a difficult challenge to work around.
[24:33.070 --> 24:35.690]  But Super Sheep also has an app for that.
[24:35.690 --> 24:37.970]  Uh, specifically Mount Winpart.
[24:38.170 --> 24:59.510]  So, Mount Winpart is a command line argument which takes the BitLocker disk encryption key, uh, as an argument to the command and decrypts Windows and then does a third phase of the integrity check against the platform, uh, confirming Windows is in a proper state.
[25:00.070 --> 25:16.730]  Um, because it's taken as a command line argument, all we have to do is restore the system back to its expected integrity state, resume the execution of the initialization process and monitor PROC command line for our BitLocker disk encryption key.
[25:17.150 --> 25:26.470]  After just a few seconds, we're able to do just that, uh, recover the BitLocker disk encryption key and decrypt Windows.
[25:27.210 --> 25:44.630]  Having decrypted Windows, we now have an opportunity to install malware that will, uh, interact and hook the XFS API and from there we have the ability to then dispense funds from the ATM on demand, uh, full system compromise.
[25:45.770 --> 25:56.910]  So, originally reporting this vulnerability to DBOLD, uh, this issue was only observed to impact version 18.X of the software.
[25:56.910 --> 26:03.450]  Uh, and at the time of the research, uh, 18.X was also designated the end of life.
[26:04.170 --> 26:15.210]  And manually, uh, taking a look at the next supported release, uh, at this point in time was 330 service release 4, um, the attack surface was mitigated.
[26:16.710 --> 26:23.390]  And the way the attack surface was mitigated was etcnet tab is now part of the phase 1 integrity check.
[26:23.530 --> 26:28.830]  However, some other interesting changes were made to the disk as well.
[26:28.890 --> 26:34.630]  Uh, in version 330, the phase 1 integrity check was reduced by 20%.
[26:34.630 --> 26:39.470]  Going from 253 elements to just 56.
[26:40.550 --> 26:51.270]  Reporting this to DBOLD, uh, they designated this was not a vulnerability, it was intentional, uh, in favor to enhance security protections provided via IMA.
[26:52.110 --> 26:54.390]  Okay, so what is IMA?
[26:54.410 --> 26:57.210]  Well, IMA is very similar to secure boot.
[26:57.210 --> 27:05.230]  It's actually a kernel signature verification process where the Linux kernel and every executable on the system is digitally signed.
[27:05.230 --> 27:15.490]  The digital signatures and appended to each file is an extended attribute which carries, uh, file name, file path, and some other various I know details.
[27:15.710 --> 27:27.910]  During the execution call, in a parent or parent child relationship, those, uh, files are validated against the Linux kernel which asserts whether or not it's allowed to execute.
[27:28.230 --> 27:36.050]  Pretty solid security control, honestly, but, uh, IMA is not without its own limitations.
[27:36.050 --> 27:42.470]  Uh, specifically, IMA does not validate, uh, interpreted scripts.
[27:42.490 --> 27:52.790]  So, since we're running in a Linux architecture, right, the entire process is essentially executed off of a system shell.
[27:52.790 --> 27:59.610]  And the system set shell is, uh, is a certified, uh, executable, so it's allowed to run.
[27:59.610 --> 28:14.450]  But then when it goes to read interpreted files, for example, a user's profile script or bash RC, those are then, uh, executed within the context of the authorized shell regardless of what they're instructed to do.
[28:15.130 --> 28:20.230]  So, having that attack surface, let's, uh, carry on into service release 9.
[28:20.270 --> 28:26.330]  So, in service release 9, the Linux architecture is relatively unchanged.
[28:26.330 --> 28:48.450]  However, taking a closer look into, uh, the system v initialization process, uh, uh, initialization script known as mountfs carries a delete procedure, uh, which is executed before, uh, the temporary file systems are mounted within, uh, the runtime environment.
[28:48.990 --> 29:01.170]  What is interesting about this is one of the, uh, security architecture designs of the platform are, relies on the use of the temporary file systems.
[29:01.510 --> 29:09.590]  And if we're able to disable those file systems from being mounted, we're then able to regain persistence to the disk.
[29:09.630 --> 29:13.770]  And those mount points are all mounted based on fstab.
[29:14.690 --> 29:29.650]  So, if we just replace fstab with mtab and link it back to fstab, uh, fstab is deleted before the mount command is called, disabling the temporary file system and then giving us persistence back to the disk.
[29:29.670 --> 29:34.710]  From here, we patch root's profile scripts and, uh, get code execution.
[29:35.270 --> 29:39.310]  So, here's CVE 2023-24063.
[29:40.610 --> 29:48.110]  So, in this demo, uh, patch the offline disk, relocate fstab, and, uh, patch root's profile script.
[29:48.530 --> 29:56.430]  Powering back on the virtualized system, when root performs it's auto log on, we get code execution and receive a callback shell.
[30:00.770 --> 30:03.810]  Linux, uh, totally compromised again.
[30:05.310 --> 30:10.150]  So, this time, um, the vulnerability has slightly more impact, right?
[30:10.150 --> 30:16.770]  Uh, all prior versions of 330 up to service release 9 are known to be vulnerable to this attack surface.
[30:16.770 --> 30:28.930]  Uh, the vulnerability was identified in June of 2022 and then confirm remediated just a few days later, looking at the next major release or next patch release of dynamic security.
[30:29.450 --> 30:37.310]  In that patch release, the delete call for etsy mtab is no longer present within mountfs.
[30:37.310 --> 30:44.170]  Okay, that successfully removes that attack surface to delete fstab.
[30:45.130 --> 30:48.550]  So, let's dive a little bit deeper into service release 10.
[30:49.630 --> 30:56.230]  So, in service release 10, init tab is validated, mtab does nothing.
[30:56.230 --> 31:08.670]  But there is still the dependency of the tempfs and there is some logic, uh, within how mount is executed.
[31:08.670 --> 31:17.870]  One interesting feature of mount is if you call mount against a directory path that's currently mounted, uh, the call to mount will fail.
[31:18.010 --> 31:22.850]  Since it's Linux, uh, what's the default, uh, mount point?
[31:22.950 --> 31:24.190]  The rootfs.
[31:24.490 --> 31:38.630]  So, if we just flatten the file system and, uh, link root var and temp to the root, uh, rootfs itself, when fstab is read, uh, those mount points are already mounted.
[31:38.630 --> 31:46.890]  So, the mount command will fail, uh, which then gives us persistence to root's home directory and the ability to patch the profile script.
[31:47.570 --> 31:52.910]  So, again, CVE, uh, 2023-24062.
[31:55.510 --> 32:04.450]  So, in this demo we can take the offline disk, uh, flatten the file system and, uh, patch root's profile scripts.
[32:04.450 --> 32:11.070]  Uh, powering back on the system, uh, once root logs in, we get, uh, code execution and receive our callback.
[32:19.740 --> 32:25.760]  So, this time, uh, the attack surface has slightly more impact.
[32:25.760 --> 32:38.600]  Uh, all prior versions of 3.3.0, 4.0, 4.1, and 4.2 now representing the entire software solution of dynamic security at this point in time.
[32:38.780 --> 32:48.000]  The vulnerability was identified in June of 2022 and confirmed remediated in December as part of service release 12.
[32:48.480 --> 32:53.980]  In service release 12, uh, mountfs was further updated.
[32:53.980 --> 32:59.720]  Now introducing a delete call to delete root, var, temp, and mount.
[32:59.720 --> 33:02.240]  Then recreate those directories.
[33:02.240 --> 33:13.440]  This essentially removes any offline modification or persistence that have been, uh, employed against those directory paths on the offline disk.
[33:13.580 --> 33:14.420]  Okay.
[33:15.240 --> 33:18.120]  Let's dive a little bit deeper into service release 12.
[33:19.520 --> 33:22.200]  So, service release 12.
[33:22.500 --> 33:25.920]  How do you work around a delete call?
[33:25.920 --> 33:28.920]  There's still some black magic amount.
[33:29.780 --> 33:42.280]  So, specifically, early, earlier in the initialization process, internal runtime memory is mounted to user space via, uh, specialized mount directives.
[33:42.580 --> 33:47.660]  And these mount directives are associated to a directory path, of course.
[33:48.040 --> 33:59.040]  And, uh, the cool thing about mount is when you stuff files into those directory paths and then those mount points become active, access to that file content is no longer accessible.
[33:59.220 --> 34:03.760]  So, since all the mitigations were done in mountfs, let's just throw that away into proc.
[34:04.040 --> 34:11.740]  Um, and then, we're able to get persistence back to root's home directory, patch profile script, and, again, obtain code execution.
[34:12.440 --> 34:16.880]  So, uh, here's cve-2023-28865.
[34:18.780 --> 34:32.000]  So, in this demo, again, patch the offline disk, uh, relocate mountfs to proc, power back on the virtualized system, root performs this auto-logon, and, uh, code execution and callback.
[34:39.440 --> 34:40.400]  Cool.
[34:40.400 --> 34:43.000]  System, uh, uh, again, compromised.
[34:44.120 --> 34:54.720]  So, uh, this vulnerability was also, uh, observed to now impact all versions of 3.3.0, 4.0, 4.1, and 4.2.
[34:54.720 --> 35:02.560]  Again, uh, representing an attack surface affecting the entire software solution of dynamic security.
[35:02.560 --> 35:13.380]  The vulnerability was identified in December of 2022, and then confirmed remediated in February of 23, uh, as part of service release 15.
[35:14.260 --> 35:22.940]  So, in service release 15, uh, this time the phase one integrity process was updated.
[35:23.120 --> 35:30.040]  Now, introducing, uh, a number of null hash sum validations against several critical mount points.
[35:30.040 --> 35:41.000]  Uh, this essentially asserts those directories to be empty or not carry any modified content, uh, before the system is allowed to initialize.
[35:41.680 --> 35:46.920]  Okay, let's see if there's maybe any opportunities to work around that.
[35:48.400 --> 36:04.400]  So, in service release 15, um, one of the things that are, uh, interesting is that the mitigation strategy is now becoming larger than , uh , originally more complexed than, uh, what it probably should be.
[36:04.520 --> 36:16.240]  And in that observation, the more complex, uh, security architecture control typically is, the more likely something is going to be overlooked in the logic of how that's implemented.
[36:16.320 --> 36:26.780]  But in order to kind of figure out those outlier boundaries, we need to have a better understanding of how the control's implemented and, um, how far it goes.
[36:26.780 --> 36:35.440]  So, if we create a directory that's So, if we have an empty directory, or a tree of empty directories, those all calculate a null sum index.
[36:35.660 --> 36:45.120]  But if we create a file, or link to a known valid file, those create sums in the systems not allowed to boot.
[36:45.980 --> 36:51.420]  What also creates a null sum is a broken symlink.
[36:52.640 --> 36:59.260]  So, which brings up an interesting point, because symlinks are somewhat unique.
[36:59.500 --> 37:10.020]  It doesn't actually matter whether or not they're linked to a proper path, or a broken path, and they're only validated at the point where they're called or read.
[37:10.600 --> 37:17.640]  So, in order to take advantage of this attack surface, we return to the previous attack.
[37:17.640 --> 37:19.560]  We need a new staging directory.
[37:19.800 --> 37:31.160]  And the goal is to identify a staging directory which does not exist in the offline desk, but one that's created once the Linux kernel is initialized.
[37:32.880 --> 37:50.780]  Ultimately, after just a few seconds, it doesn't take very long to review the system disk from the perspective of the previous attack surface, and we stumble across dev block, to be one directory path in particular.
[37:50.780 --> 38:01.360]  Dev block is also an interesting mount point that's used in the software, which is associated to the block device of the system disk itself.
[38:01.560 --> 38:11.220]  And it's also present in all versions of dynamic security, which makes it a very persistent attack surface against the software solution.
[38:12.520 --> 38:22.100]  So, now that we have a directory path, all we need to do is then establish a transversal link to that.
[38:22.260 --> 38:33.000]  So, we rename our critical mount points, and then link those via the transversal path of dev block.
[38:33.300 --> 38:40.800]  On the offline desk, or during EFI initialization, that directory path is broken.
[38:40.800 --> 38:42.980]  So, those files don't exist.
[38:42.980 --> 38:46.880]  No hash sum validation of the content.
[38:46.880 --> 39:02.460]  But then once the Linux kernel is initialized, that directory path becomes active, and links to our new home directory, again giving us persistence to root's profile script.
[39:03.020 --> 39:07.960]  So, here's CVE 202333206.
[39:08.960 --> 39:19.120]  So, in this demo, take the offline disk, relocate our mount points to our transversal of dev block, power back on the system.
[39:19.120 --> 39:24.140]  When root performs its logon, we get code execution and receive a callback.
[39:31.900 --> 39:32.300]  All right.
[39:32.300 --> 39:35.040]  Again, ATM totally compromised.
[39:37.000 --> 39:39.720]  So, now it's starting to become a little bit redundant, right?
[39:40.100 --> 39:50.720]  So, this vulnerability was observed to impact all prior versions of 3.3.0, 4.0, 4.1, 4.2, and now 4.3.
[39:50.720 --> 39:56.100]  Again, the entire software solution of dynamic security.
[39:56.100 --> 40:06.200]  The vulnerability was identified in April of 23, and then confirm remediated in July, as part of service release 16.
[40:07.940 --> 40:19.340]  So, taking a little bit deeper, a closer look, service release 16 mitigates the attack surface by now further updating the phase one integrity process.
[40:19.380 --> 40:23.440]  So, phase one now validates the integrity of symlinks.
[40:23.440 --> 40:30.220]  Broken symlinks produce an integrity failure and the system is no longer allowed to boot.
[40:30.440 --> 40:45.420]  Another interesting observation, though, is the previous mitigation checks performed within mountfs, which delete rootvar and temp and then recreate those directories, is now commented out.
[40:46.080 --> 40:54.900]  It doesn't necessarily reintroduce any of the previous attack surface because of the additional protections provided via the phase one integrity check.
[40:54.900 --> 41:00.480]  Now validating symlinks and having no sum validation, it's somewhat redundant.
[41:00.480 --> 41:08.360]  However, it is an interesting approach to defense in depth, removing those controls.
[41:09.880 --> 41:15.920]  In conclusion, this kind of brings us into service release 16.
[41:17.500 --> 41:30.620]  In service release 16, we have symlink validation, there's null sum checks, the disk is generalized, generally pretty hardened.
[41:30.620 --> 41:33.800]  There's not much of an attack surface there.
[41:34.600 --> 41:46.260]  However, what is really interesting about their integrity validation process is it's all based around the concept of performing sum indexes against the content on the disk.
[41:46.620 --> 41:52.220]  And the one thing that doesn't change a file's sum index is its attributes.
[41:52.620 --> 42:03.880]  So, if you remove the execute permissions from a file, it calculates the exact same sum index, and no change is presumed.
[42:03.960 --> 42:17.460]  So, if we just remove the execute permissions of IMA, we're able to disable kernel signature verification altogether, and then gain the ability to execute any unsigned binary we wish.
[42:18.360 --> 42:24.160]  So, here's CVE 2023-40261.
[42:24.160 --> 42:40.220]  In this demo, power back on the system, take the offline disk, disable execute permissions for IMA, and once root logs in, we can execute anything we want.
[42:46.310 --> 42:49.510]  Again, system totally compromised.
[42:52.130 --> 43:05.370]  Going back to the scope of the timeline, once again, this attack surface impacts all prior versions of 330, 4.0, 4.1, 4.2, and 4.3.
[43:05.410 --> 43:12.950]  Again, representing an attack surface against the entire software solution of dynamic security.
[43:12.950 --> 43:25.850]  The vulnerability was identified in July of 23, and then I've been informed it has been remediated as part of service release 17, released in November of that year.
[43:26.050 --> 43:39.330]  In addition, D-bolt has also moved version 3.3 into end of life, and now has moved up the chain supporting 4.0, 4.1, 4.2, and 4.3.
[43:42.230 --> 43:45.430]  So, this kind of brings me sort of to the end, right?
[43:45.950 --> 43:54.730]  Seeing the system compromise several times over brings you into the perspective of, yeah, probably need defense against these platforms.
[43:55.370 --> 44:09.450]  It's important because I've been able to demonstrate there is an attack surface not representing single versions of dynamic security, but that can affect the entire software stack against the solution.
[44:09.910 --> 44:24.410]  Not only that, but the attack surface is generally recursive, where even though systems are patched, new vulnerabilities can be identified, which are likely going to have a reciprocal impact to all prior versions.
[44:24.830 --> 44:38.250]  And although the systems are patched, there's still a significant risk because the Linux partition is unencrypted, so it's generally a cat and mouse game of where you want to move files and how you want to execute stuff.
[44:39.330 --> 44:44.290]  Despite all this, there are a couple of mitigating strategies that can be done.
[44:45.090 --> 44:55.690]  First and foremost, it's important, just like with anything, is to patch the software solution and ensure you're running the most recent release.
[44:55.690 --> 44:57.470]  Okay, that's fair enough.
[44:57.910 --> 45:17.670]  In addition to that, as directly a result of this research, in April of 2024, dbold released version 4.4 of dynamic security, now providing full encryption via locks for the super sheep disk.
[45:17.690 --> 45:23.810]  So, which drastically reduces the attack surface against the platform.
[45:23.810 --> 45:36.030]  In addition to that, there's an additional configuration check, known as enable signature check, which can be disabled within the dynamic security configuration settings.
[45:36.030 --> 45:54.350]  Disabling this security check disables the disk encryption key from being issued as a command line argument to mount winpart, which makes it significantly more difficult to compromise the TPM and get access to that content.
[45:54.890 --> 46:04.990]  As a fourth option, there's always a possibility to just replace dynamic security with another industry recognized full disk encryption solution.
[46:05.530 --> 46:10.730]  In addition to that, there's several ancillary controls that can be done as well.
[46:11.030 --> 46:15.130]  Monitor the system for malicious top hat entry.
[46:15.390 --> 46:21.630]  Ensure unused USB ports are disabled and don't provide a vantage point to access the system.
[46:21.930 --> 46:28.550]  And a lot of times, some of the ATMs, the hard drive's really easy to move.
[46:28.550 --> 46:31.170]  It's affixed with thumb screws.
[46:31.170 --> 46:34.850]  So if you open the top hat, very easy to pull out the hard drive.
[46:35.090 --> 46:39.670]  There's no reason why a hard drive should be easily removable from an ATM.
[46:40.150 --> 46:51.770]  So ensure those screws are locked and or the PC's installed within a case that doesn't allow easy access to the hard drive itself.
[46:53.710 --> 46:56.890]  Again, I'd like to thank you guys for your time.
[46:56.890 --> 46:58.950]  It's been an honor of presenting here.
[46:59.230 --> 47:05.730]  My name is Matt Birch and if there's any questions or comments, please feel free to hit me up via social.
[47:05.790 --> 47:07.150]  Or, yeah?
[47:25.710 --> 47:41.750]  Okay, so the question was, in reporting the vulnerabilities with eBold, how well were they able to respond or what was my experience with their response into patching the issues?
[47:42.390 --> 47:46.570]  Well, at first there was some cynicism, right?
[47:46.570 --> 47:52.910]  They weren't necessarily interested or didn't see much impact to some of the first issues.
[47:53.030 --> 48:04.190]  But then when I started representing attacks that had a larger impact where it was more drastically affecting the software stack, there was much more attention.
[48:04.290 --> 48:18.510]  And they were fairly easy to work with and did validate the issues within just a few weeks time and were able to get patches out within a few months.
[48:18.870 --> 48:22.610]  In some of the timeline I had, it did take a little bit longer.
[48:22.730 --> 48:31.270]  And then those patches were also released out of sync in some of the different versions of their software stack.
[48:32.690 --> 48:34.130]  Yeah?
[48:50.150 --> 49:04.470]  So the question was whether or not there was a big initiative to patch the systems when the vulnerabilities became available and what the attack surface still looks like.
[49:05.670 --> 49:22.530]  So, um, D-Bull did release notifications, uh, to their customers that the vulnerabilities, uh, vulnerabilities were identified and suggesting, uh, updates to those issues.
[49:22.530 --> 49:26.750]  Uh, I had the opportunity of looking at some of those service release notes.
[49:26.790 --> 49:40.110]  Um, they were generally very vague in context and had, uh, simple, simple indications of, um, improvements to PBA integrity.
[49:40.250 --> 49:52.790]  Uh, so I have been told that there were several communications, uh, especially when I started releasing this content, they reached out to customers and suggesting that they, that they would update.
[49:52.910 --> 50:11.830]  Um, I think there is room for improvement in how those communications were initialized and, uh, also to, there should be severity put on, uh, issues that are known to be high impact or high impactful against the platform.
[50:11.830 --> 50:14.730]  So, um, yeah, there were notifications.
[50:14.730 --> 50:17.810]  I think there, there could have been a better job.
[50:17.810 --> 50:29.250]  Uh, some of the context around that is they didn't necessarily want to give information to the criminal element of attack surfaces against the platform.
[50:29.250 --> 50:33.250]  I, I think it's more important to, to notify people of, of issues.
[50:37.760 --> 50:38.880]  Yup?
[50:49.610 --> 50:55.270]  Yeah, so the, uh, the question was what does the, uh, physical attack avenue actually look like?
[50:55.270 --> 51:00.370]  So, it varies from ATM manufacturer to ATM manufacturer.
[51:00.370 --> 51:05.450]  But, like I said, is in the architectural design of the ATMs themselves.
[51:05.550 --> 51:15.510]  Uh, the top portion of the ATM, which carries all the PC logical peripherals, is not generally considered a security risk against the system itself.
[51:15.510 --> 51:19.030]  Which is funny because that's what dispenses the funds.
[51:19.030 --> 51:25.270]  It's fairly obvious when you take a look at the security controls and how that's implemented.
[51:25.570 --> 51:41.390]  In order to get access to the ATM, you need to, I mean, like you said, uh, physically break into it or, um, there are ways via vent holes to interact with the system locking mechanism.
[51:41.410 --> 51:44.110]  Cause that's essentially controlled by a cable .
[51:44.110 --> 51:51.450]  So if you can pull the cable, it'll lift the latch, the front of the ATM will open up and, uh, you can get access to the hard drive.
[51:51.490 --> 52:05.870]  Uh, I've seen, uh, police surveillance videos and it's, it's possible to get in, get into the ATM, pull out the hard drive and catch it within a surprisingly short period of time.
[52:07.710 --> 52:09.030]  Yeah.
[52:23.650 --> 52:37.110]  So, uh, the question is related to, uh, timeline in regards to how, like what the delta was between them patching an old issue and me coming up with a new one.
[52:37.350 --> 52:43.310]  Um, that was generally, uh, pretty quick.
[52:43.310 --> 52:54.430]  So the, the validation, uh, that I was doing to confirm remediation of the issues was also out of sync of stuff being released.
[52:54.610 --> 53:03.770]  So they may release a patch , but then I didn't get access to, uh, installed representation of that till like maybe a few months after.
[53:04.010 --> 53:11.750]  But generally within like a week, couple weeks time, I, I was able to , to find a new attack path around it.
[53:14.410 --> 53:15.290]  Cool.
[53:15.290 --> 53:16.250]  Anything else?
[53:17.410 --> 53:18.890]  Oh, yep.
[53:28.230 --> 53:44.690]  You know, uh, so this is actually a very interesting conversation and I'm sorry, the, the question was, um, having known vulnerabilities, how does this impact, uh, potential PCI certification of the platform?
[53:45.030 --> 53:53.410]  Um, I had conversations with dbold around that, around PCI, uh, because all the ATMs are actually advertised, right?
[53:53.410 --> 53:57.010]  We're PCI DSS compliant, blah, blah, blah.
[53:57.010 --> 54:09.170]  That certification is actually only linked to the pen pad of the ATM and the software on the ATM itself is not generally part of the PCI DSS certification.
[54:10.110 --> 54:11.210]  Yeah.
[54:13.990 --> 54:16.050]  It's, yeah, it is.
[54:22.390 --> 54:22.830]  Cool.
[54:22.830 --> 54:23.670]  Anything else?
[54:25.410 --> 54:25.950]  All right, great.
[54:25.950 --> 54:26.930]  Hey, thanks guys.
[54:26.930 --> 54:28.270]  It's, uh, it's been a pleasure.