19 lines
4.8 KiB
Markdown
19 lines
4.8 KiB
Markdown
# 27 April 2020
|
|
Today I joined a discord voice chat with a group of people that I sometimes just play games with or discuss programming and nerd things with. I brought up some weird findings that I forgot to document in the past as they seemed very minor. It was how I found some hardcoded usb path for ttyUSB interaction. It seemed like the hardcoded path were going though a usb hub from my guess due to how the path looked like (`/sys/devices/platform/MtkUsbHcd.0/usb3/3-1/3-1.3/3-1.3:1.0/ttyUSB0/tty/ttyUSB0/dev`) compared to how it looked like when I plugged in something to my pi's usb.
|
|
|
|
## Node
|
|
I found some references to node.js in some files and given that there are multiple different custom browsers, chances for node access is high. If we had node access at all then accessing the filesystem would be quite easy. We are unsure if the browser console I have access to have any node functions exposed (if node is used). **Shaddy** gives a list of tests to try and figure any available node versions. He find that `deserialize` is a easily exploitable function that tends to be available ([docs](https://www.exploit-db.com/docs/english/41289-exploiting-node.js-deserialization-bug-for-remote-code-execution.pdf)). We were unable to find any available node functions.
|
|
|
|
## Ghidra x IDA
|
|
It is time for more research and discovery so we can get a better foothold. People agree that `tvapi_jsplugin.so` seem to be the most interesting binary and is most likely bound to have exploitable issues included (functions with typoes etc. is a good sign for bad code). I try some function signatures I found, but are still unsure of the arguments some functions require.
|
|
|
|
First function that seem interesting is `accessLocalStorage`. If we can get any write or elevated read permissions to the system, then that could help crack the box open. (UNKNOWN) pointed out that the binaries have a letter pattern of the required arguments for the functions. A pointer to the function called were also close by, so we could inspect what the function did in greater detail. We found the function does both read and write to the filesystem depending on the arguments. There seem to be a bug with the read functionality of the function where it does not clear the buffer from last time it read a file. This makes it annoying to understand at first when we read a file successfully. Some people (**HoLLy**) tries to push me into writing into the existing shell files to get our own commands to execute, but I decline as it seem very risky to overwrite script files that may be required to run to get the tv to fully boot up etc. At some point I try to write to a smaller script file that would be fine if it did not execute the current code, but we discovered that we did not have permissions to edit such file. It currently seem like we can only write to the `/tmp` directory. This does not leave us with much options but we will keep it in mind for future testing.
|
|
|
|
Meanwhile **Jan4V** also found 2 exploitable functions: `AmbiSet` & `AmbiGet`, that have stack overflow potential. They both use strcpy into a fixed buffer size which we can overflow. The fixed size of the buffer is 1048 bytes. We end up using `AmbiGet` as "get" sounds safer then "set", but it would work regardless of which one we used. `AmbiGet` takes 2 arguments; "ns" (number, string). The first argument is the length, where 2nd is the string data. We set the length to 0 as it does not matter to us. If we send 1047 "A"'s the system responds with `undefined` back to the chrome inspector. If we send 1048 "A"'s the instance crashes as we have overwritten part of the stack with one 0x00 byte (since the string is null-byte terminated; making it 1049 bytes long)
|
|
|
|
## Stack overflow exploiting
|
|
We spend the rest of the day trying to find a good candidate to jump to as the return pointer can be overwritten. The stack is executable but the issue is we do not know where the SP is so we can not just jump to our own string as code reliably. We can also not include any null bytes in our payload which adds another layer of difficulties. **Jan4V** discovers that `browser` (`/3rd/internet_browser/browser`) is fixed in memory and we can reliably jump to it. `browser` has system calls to do simple things like make directories, so that leaves us with an easy decision as to where to jump to. **Jan4V** spends a long time assembling payloads to do tests and check reliabilities. It is a slow process that we should have automated as we had to make crashdumps then transfer those crashdumps to our computers to unzip and go though when we wanted to check things.
|
|
|
|
Due to the stack only rolling back 8 bytes we are limited to 8 bytes for the system call and we are unable to do proper debugging for some time. **Jan4V** spends some time making a good script to more easily test payloads with the overflow exploit.
|
|
|
|
- touch /tmp/youtube_fore |