One of the most fun things of doing OT Security is being able to share strange things, just like todays Atlas Copco IPM IAM Process Control. What sounds fancy, well, lets just have a look.

Atlas Copco produces various different industrial components from generators to smart wrenches. As some of their components are digitally controlled, they also have control systems / industrial PCs running various software. Their main controller seems to be called the “ Power Focus ”. The heart of the Power Focus is a little black box, the “IPM - IAM Process Control”, which I have on my desk today. It was a lucky eBay find, lucky because it was cheap in comparison to all the others and because it was functioning!

Why?

A tiny “Process Control” component just sounds tempting and interesting and is a fun little thing to share and give an insight into the OT world. So, what is it?

Top	Bottom

The Power Focus is a controller for smart / digitally controlled (torque) wrenches, which, from the catalogues, are utilized in both the automotive and aviation sectors. Reading the descriptions, the approach quickly makes sense: The wrenches combine stable quality with integrated monitoring. The torque wrench will not only apply the configure force, but also document that the correct force was applied. Thus, we have integrated process monitoring and quality assurance, which is a basic requirement in regulated areas. That said, “outsourcing” responsibilities from a human to a machine implies notable integrity requirements which must be met!

Documentation on the device can be found here:

• Power Focus Offering
• POWER FOCUS 6000 POCKET GUIDE
• Power Focus 6000 LV

The Physical Internals

Opening the case shows us a small PCB with a central chip on it, an Apacer UCP333ILFG. While not being able to find a datasheet, googling Apacer directly shows various pictures of USB sticks. That in addition to the header on the PCB does give the impression of a typical USB memory device. So, soldering a fitting cable and connecting it to a PC…

Internal	With USB

I didn’t take a picture of the bottom side of the PCB as it’s glued in tightly. When comparing the two images you can actually see where I chiped the PCB coating on the right. As I’m expecting a simple flash chip and I was able to dump the memory, it didn’t feel worth the risk to get it out.

The Logical Internals

Connecting it to a Linux system, we see

[162969.701668] usb 1-4.4: New USB device found, idVendor=1005, idProduct=b155, bcdDevice= 1.00 
[162969.701675] usb 1-4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 
[162969.701676] usb 1-4.4: Product: USB DISK MODULE 
[162969.701678] usb 1-4.4: Manufacturer:          
[162969.701678] usb 1-4.4: SerialNumber: 19000391A7DC4993 
[162969.725740] usb-storage 1-4.4:1.0: USB Mass Storage device detected 
[162969.725918] scsi host7: usb-storage 1-4.4:1.0 
[162970.775831] scsi 7:0:0:0: Direct-Access              USB DISK MODULE  PMAP PQ: 0 ANSI: 0 CCS 
[162970.776074] sd 7:0:0:0: Attached scsi generic sg2 type 0 
[162972.934675] sd 7:0:0:0: [sdb] 8060928 512-byte logical blocks: (4.13 GB/3.84 GiB) 
[162972.937408] sd 7:0:0:0: [sdb] Write Protect is off 
[162972.937411] sd 7:0:0:0: [sdb] Mode Sense: 23 00 00 00 
[162972.940141] sd 7:0:0:0: [sdb] No Caching mode page found 
[162972.940143] sd 7:0:0:0: [sdb] Assuming drive cache: write through 
[162972.950647]  sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 > 
[162972.950857] sd 7:0:0:0: [sdb] Attached SCSI removable disk 
[162973.363881] EXT4-fs (sdb3): mounting ext2 file system using the ext4 subsystem 
[162973.439024] EXT4-fs (sdb3): mounted filesystem without journal. Quota mode: none. 
[162973.439979] EXT4-fs (sdb2): mounting ext2 file system using the ext4 subsystem 
[162973.443631] EXT4-fs (sdb5): mounting ext3 file system using the ext4 subsystem 
[162973.444822] EXT4-fs (sdb6): mounting ext3 file system using the ext4 subsystem 
[162973.643039] EXT4-fs (sdb2): mounted filesystem without journal. Quota mode: none. 
[162973.649325] EXT4-fs (sdb7): mounting ext3 file system using the ext4 subsystem 
[162973.650132] EXT4-fs (sdb8): mounting ext3 file system using the ext4 subsystem 
[162974.770499] EXT4-fs (sdb7): mounted filesystem with ordered data mode. Quota mode: none. 
[162975.959937] EXT4-fs (sdb8): mounted filesystem with ordered data mode. Quota mode: none. 
[162975.965025] EXT4-fs (sdb6): mounted filesystem with ordered data mode. Quota mode: none. 

8 partitions confirming our guess, that it’s a simple USB memory device.

As often done with embedded devices, sdb2 and sdb3 contain a redundant copy of the operating system, thus allow for memory corruption or potential faults during updates. The same applies to the persistent storage in sdb5 and sdb6.

sdb8 seems to contain a license key, both in yml and json format

{ 
    "Version": "1", 
    "IsUsbDongleInUse": "true", 
    "UsbDongleId": "DID_SENSEBA001000693\n", 
    "IsLicenseServerInUse": "false" 
} 

And additionally, a file called storage-0 containing a TSFS header.

sdb7, the largest partition, contains a few core dumps and protocols. The protocols seem interesting from a dumpster diving perspective, as they contain a folder called bmw.

All files look similar to the following

***KISSQM8S42P02*SOLLDAT1414ON010832501414*F70********23.10.202406:48:0501029900**************************************************00

The folder sdb7/persistentstorage/resultsdatastore/rns/ contains a load of .bin files with references to a M8S42P02-02 4 Wege-Sitz LL, which I guess might be the part that the wrench connected to the PC used to tighten bolts for. A randomly picked sample can be found here .

The Firmware or OS and Software

According to a sw_version file found on the storage PF6_R_3.0.9.85_2020-02-26, so a 5-year-old version. As I have no idea where the device comes from, well, except for eBay, this contains no criticism whatsoever. In return it gives me a baseline to compare the following list of vulnerabilities to:

• 325 critical vulnerabilities
• 1210 high vulnerabilities
• 2004 medium vulnerabilities
• 63 low vulnerabilities

The list was generated using Binarly where I simply uploaded a .tar.gz of a dd that I created from the memory card.

Looking a bit deeper we i.e. find

I also noticed that here were seemingly different vulnerabilities and dependencies identified for sdb2 and sdb3, thus I guess one partition was updated during an update cycle and the otherone was left behind on a last known good state. This is a fully valid approach for update cycles, which typically look as follows:

1. Update one partition
2. Boot from that partition
3. Test and use
4. If ok, update the second partition

Alternatively

1. Update primary partition
2. Test and use
3. New update: Update other partition
4. Test, if ok set to primary partition
5. Keep the old partition as backup

The downside of the alternate approach is that should the primary system fail due to a system error, the fallback might still work but will be unpatched and potentially lack certain features. Talking ransomware, this might even be a smart strategy: If you’re not able to infect the primary system, you make sure it crashes to force booting the secondary which can then be infected. I know this scenario might sound artificial, but attacks have become increasingly custom tailored over the last few years.
For the newer partition, the picture above looks like this:

So, running a kernel from 2018 and a busybox from 2015 in an image from 2020, well, it seems a set of vulnerabilities was known and accepted when the firmware image was built. For a critical device, probably not such a good idea!
That said, that’s OT for you. For many years, up to today, the core, most vital Security measure is isolation. Thus, having a device with a set of vulnerabilities can easily be compensated by reducing the exposure and pushing the probability of exploitation towards zero. The other way round, if devices are in state like the one covered here, everybody would want to isolate it, if forced to work with it.

Who Uses the Devices?

While maybe not a reliable reference, why else would these specific configs / processes be named like that, if the manufactures or potentially their suppliers be using these devices? Anyways, this is the perfect definition of an information disclosure, as it gives an attacker a black on white rating of the device’s criticality and potential reach for attacks against these devices.

And now?

Well, I hope you’ve learned and seen something new, I surely have and hope it gives you a little inspiration. Also, ask yourself whether this is the device, you want to be used to tighten the bolts on your car seats and, which requirements have to be met and applied so that you do :)
P.S.
Here I’m referring to the vulnerabilities, which were already included when the software was built! Of course, the device is affected by a lot of vulns which were found after 2020, but as we don’t know when the device was pulled from production, we don’t know how secure it was run while it was operated.