g/pax-pwn
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

better readme organization and some clarifications

Browse Source
This commit is contained in:
Giulio 2020-11-01 10:46:11 +01:00
parent 4e39ce2ae6
commit ee0f023df1
1 changed files with 14 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
Readme.md
View File

@ -24,10 +24,10 @@ Other models might be running ProlinOS too but their specification is not detail
For this research, I have bought a S900 from eBay and was lucky enough to find a used model targeted at developers. I will specify when something applies only to the developer model and not the production ones, although very little differs in terms of vulnerabilities. For this research, I have bought a S900 from eBay and was lucky enough to find a used model targeted at developers. I will specify when something applies only to the developer model and not the production ones, although very little differs in terms of vulnerabilities.
## Pictures ### Pictures
![PAX S900 from eBay](https://git.lsd.cat/g/pax-pwn/raw/master/images/s900.jpg) ![PAX S900 from eBay](https://git.lsd.cat/g/pax-pwn/raw/master/images/s900.jpg)
## Resources ### Resources
Before starting the analysis, I found the following resources very useful: Before starting the analysis, I found the following resources very useful:
PDF: PDF:
@ -48,13 +48,13 @@ FCC Documents:
It's possible to see clearly from the `Internal Photos` PDF that the device has an additional battery and multiple anti-tampering contacts; there's also a warranty sticker on the side. Hardware attacks are probably possible, but out of scope here as I lack both skills and equipment to work in that direction. Furthermore, a hardware attack would be more difficult to execute in real-life scenarios because of the circumstances in which a POS is used. It's possible to see clearly from the `Internal Photos` PDF that the device has an additional battery and multiple anti-tampering contacts; there's also a warranty sticker on the side. Hardware attacks are probably possible, but out of scope here as I lack both skills and equipment to work in that direction. Furthermore, a hardware attack would be more difficult to execute in real-life scenarios because of the circumstances in which a POS is used.
## Hardware Info ### Hardware Info
The device has a color display, WiFi, GSM, Bluetooth, an AC charging port, and two mini USB ports. From the specifications, one is used for serial communication and the other one for USB communication. It has a Broadcom BCM5892, 128MB of flash and 64MB of RAM. The device has a color display, WiFi, GSM, Bluetooth, an AC charging port, and two mini USB ports. From the specifications, one is used for serial communication and the other one for USB communication. It has a Broadcom BCM5892, 128MB of flash and 64MB of RAM.
## ProlinOS ### ProlinOS
ProlinOS is a minimal Linux distribution, probably derived from Android. ProlinOS is a minimal Linux distribution, probably derived from Android.
## Communication ### Communication
The device needs to be rebooted into the management interface (called `TM`). To do so on the S900 press the number `2` repeatedly during boot (even after the `SELF-TEST` screen). On the D200 do the same but with the key `F2`. Other devices have probably similar keys, and they can be guessed in a few attempts. The device needs to be rebooted into the management interface (called `TM`). To do so on the S900 press the number `2` repeatedly during boot (even after the `SELF-TEST` screen). On the D200 do the same but with the key `F2`. Other devices have probably similar keys, and they can be guessed in a few attempts.
From there go to `System Config`. enter the default pin which is `123456` and enable the XCB service. The XCB service can run both via the serial interface and network, depending on the model and the version of ProlinOS. For the serial interface, use the driver provided in the links in the Intro section, for the network interface, first connect the device to a WiFi network and the service will be on `<ip>:5555`. From there go to `System Config`. enter the default pin which is `123456` and enable the XCB service. The XCB service can run both via the serial interface and network, depending on the model and the version of ProlinOS. For the serial interface, use the driver provided in the links in the Intro section, for the network interface, first connect the device to a WiFi network and the service will be on `<ip>:5555`.
@ -70,16 +70,17 @@ Supposedly, `xcb` is intended only for adding applications to the device (which
There's also a `telnet` command which will port forward to the local machine a telnet daemon. This command will only work on development devices because the whole `telnet` binary is removed from busybox on production devices. There's also a `telnet` command which will port forward to the local machine a telnet daemon. This command will only work on development devices because the whole `telnet` binary is removed from busybox on production devices.
## Debug Level ### Debug Level
Devices have three debug levels: Devices have three debug levels:
* 0 -> Production devices, busybox has no `sh` nor telnet, `xcb` works * 0 -> Production devices, busybox has no `sh` nor telnet, `xcb` works
* 1 -> Application development devices, `busybox` has both `sh` and `telnet`. There's also a handy `gdbserver` in place. Root access is disabled, kernel, kernel modules, and some PAX configuration and binaries are not readable * 1 -> Application development devices, `busybox` has both `sh` and `telnet`. There's also a handy `gdbserver` in place. Root access is disabled, kernel, kernel modules, and some PAX configuration and binaries are not readable
* 2 -> Prolin development devices, `root` should be available with a hardcoded password * 2 -> Prolin development devices, `root` should be available with a hardcoded password
We'll see that from debug level `0` it is possible to escalate to root privileges. We'll see that from debug level `0` it is possible to escalate to root privileges.
The pos used for this article is in `debug` level `1`. A production device won't have a working telnet/shell by default. However that functionality can be restored by overwriting a shared library using the arbitrary read/write in XCB or by porting the already signed binaries from a debug device.
## Basic Linux info ### Basic Linux info
From the development S900: From the development S900:
``` ```
@ -172,15 +173,18 @@ devices_base 26185 7 pcd_base,msr,sci_bcm5892_tda8026,tty_host,tty_de
bcm5892_rtc 4938 0 bcm5892_rtc 4938 0
``` ```
## Vulnerabilities
### Arbitrary Read/Write
As described in the "Communication" section, it is possible to list, read and write file and folders with `MAINAPP` permissions via XCB.
## Signature Bypass and Code Execution ### Signature Bypass and Code Execution
Although ELF files need to be signed in order to be executed (later we'll see how), libraries apparently do not. This means that it is possible to run custom executables without issues, given that we have a working shell and `LD_PRELOAD` is working or that, even without a shell, we can overwrite a library in use by some application. Although ELF files need to be signed in order to be executed (later we'll see how), libraries apparently do not. This means that it is possible to run custom executables without issues, given that we have a working shell and `LD_PRELOAD` is working or that, even without a shell, we can overwrite a library in use by some application.
`installer`, which is the executable being called by `xcbd` (the `xcb` daemon server, like `adbd`) is responsible for verifying binary files before adding them. This does not mean that the kernel doesn't check again (it does) but means that ELF signature verification is available via userspace and is provided by a kernel module. `installer`, which is the executable being called by `xcbd` (the `xcb` daemon server, like `adbd`) is responsible for verifying binary files before adding them. This does not mean that the kernel doesn't check again (it does) but means that ELF signature verification is available via userspace and is provided by a kernel module.
It simply opens the device `/dev/verify`, uses some `ioctl` calls and send the executable file. Depending on the `ioctl` results it is possible to determine if a binary file has been correctly signed. As per the signature format, it's possible to guess that it is simply made by an RSA 2048 signature appended at the end of the file plus the string `SIGNED_VER:00001`. It simply opens the device `/dev/verify`, uses some `ioctl` calls and send the executable file. Depending on the `ioctl` results it is possible to determine if a binary file has been correctly signed. As per the signature format, it's possible to guess that it is simply made by an RSA 2048 signature appended at the end of the file plus the string `SIGNED_VER:00001`.
## Privilege Escalation ### Privilege Escalation
By looking into the device, there are mainly two possible vectors of privilege escalation which are: By looking into the device, there are mainly two possible vectors of privilege escalation which are:
* The outdated kernel is vulnerable to [dirtycow](https://dirtycow.ninja/) and many other kernel exploits * The outdated kernel is vulnerable to [dirtycow](https://dirtycow.ninja/) and many other kernel exploits