RD

R&D

After a good and long night s sleep, h3X walks back into her room where all of her computers (and often herself) can be found. The Nmap scans are not finished completely, but a lot of hosts are already covered and she can start to check the results in the log files. Most systems plain simply list all ports as closed or filtered. By far the most common open port is, of course, 80, the HTTP protocol hole, followed by port 443, the encrypted hole to the same effect. She scans the list of hosts, checking which potential ways there are into the networks. She s no longer concentrating on anything in particular like SAP, but rather just checks like a script kiddy for as many ways into the systems and networks as possible.

If I have to get the bank account information from a file server in the form of an Excel spreadsheet, so be it! she says to the log file. But the companies that she targeted are all protected like what could be described as more or less industry standard and it s probably not going to be easy to get into any of them. A few of the systems have high ports open, but those are either something totally unknown and/or unresponsive or the new Nmap service scanning engine she used has crashed them, which happens surprisingly often. This guy Fyodor must have an immense list of 0day , she thinks with a smile. After about twenty minutes of checking the log files, her eyes wander over an entry that says

 59595/tcp  open      unknown 

Something with this funny number rings a bell in h3Xes head. First, she figures out that 59595 is not a prime number, but then realizes that this is in no way related to port scanning and breaking into computer systems. It has something to do with the whole SAP mess , she thinks. And then the memory dawns back into her mind and she suddenly says, The installer! You usually don t remember how the setup program of a piece of software looked , but an installation program that is actually a client server application matched a ˜keep-in-mind filter flag in her head. SAP s setup GUI was the one that wanted a connection on this port.

Let s check if this thing is still there , she thinks, and telnets to the host and port in question, and viola, she gets a connection immediately. Checking back with the scan log, she sees that this port has been open for almost half a day now. Using her own copy that yesterday helped her to install ITS, she checks if one can have multiple connections to this thing. It turns out that this is not possible and the second connection actually times out because the operating system accepted it but the application itself didn t. Wouldn t make sense to control more than one installation the same time this way . Standing up from her computer and walking slowly in circles in the room, she talks to herself, reviewing the situation, but leaving out this annoying business about getting killed and such.

Now, what do we have here? She walks back to the computer and checks, standing, what company this computer belongs to. Okay, we have a machine within a big DMZ of a fairly large insurance company. This machine has an SAP installer sitting there in an unknown state. The installer accepts single connections and appears not to die instantly, but if we try to exploit it, it probably will. So far, it s the best option we have. So, let s get to work and see what we can do with it. Now, we need to find a bug in this software and write an exploit before she checks the clock and the time zone of the target company, those guys get back to work, which is probably in about 20 hours.

With that, she sits down purposefully and clicks on the black and white picture of Augusta Ada Byron, Lady Lovelace. This fires up the Interactive Disassembler, or IDA for short. It is the ultimate tool without any competition for bug finding work in closed source applications. Its power is so almighty that there isn t even full documentation for it. It s also the only piece of software that h3X ever paid for, since she could not stand the idea of stealing such a wonderful and liberally priced tool. Feeding the instgui.exe file into IDA, the tool starts to do its work and analyses the file in many different ways, determines in what programming language using which compiler the software was built and tracing calls back and forth. After a while, the tool announces the initial analysis as completed and h3X can go ahead and analyze the file by hand. What she s looking for are calls to the network functions in C, namely accept(), recv(), recvfrom(), and others related to receiving data via the network. From here on, she can check how the data is parsed and what requirements exist.

After a while, she notices that there are no such calls in the file. It must import the network functionality from some other file, probably a dynamic link library. So she instructs her Windows Explorer to find all files in the directory and below that contain the strings socket and recv and finds a DLL named instgui0.dll. Throwing this file into IDA takes again a few minutes before the disassembly engine chewed through the 430 kilobytes of code and data. Unfortunately, IDA finds the location where the C library function recv is included, but fails to identify which code actually calls it. This forces h3X to use another approach to find the right code. She starts the instgui.exe file inside of OllyDbg and sets a breakpoint at the location where recv is called. From here on, she can see which function it returns to and then get back into IDA and take it from there. This also gives her the chance to run the counterpart software setup.exe on a different machine and see the traffic fly by, hoping to get clues for potential vulnerabilities in the code.

When she starts Ethereal and setup.exe, packets scroll by her face, one per line. After the initial communication is finished and the instgui asks her for a path name again, she clicks on one packet of the communication and selects Follow TCP stream , a very useful feature of Ethereal when you don t care about which packets transport which information, but need a clean view on the communication itself.

The first set of data goes from setup.exe to instgui.exe:

 00000000  34 30 3a                                             40: 00000003  1d 00 00 00 12 1f 9d 02  9d 4f 59 40 51 7e 49 7e ........ .OY@Q~I~ 00000013  72 7e 4e 58 6a 51 71 66  7e 9e 82 a1 81 82 b9 99 r~NXjQqf ~....... 00000023  85 89 99 a1 05 17 00 00                          ........ 

Then, instgui.exe answers in the same language:

 00000000  32 31 3a                                             21: 00000003  0a 00 00 00 12 1f 9d 02  9d a1 81 82 b9 99 85 89 ........ ........ 00000013  99 a1 05 00 00                                   ..... 

When h3X sees the data go back and forth she realizes that she forgot to activate the breakpoint at the recv function call. But nevertheless, the sniffed data provides the first clues about how this software works. Two things jump into her eye almost instantly. The ASCII number before the scrambled data is always the amount of characters that follow. It s a bit odd, since the remaining content looks perfectly binary to her and not like an ASCII protocol, but than again, it s SAP software and is therefore known to be sometimes on the odd side of things. The second interesting item in the hex dump she looks at is the first four bytes after the ASCII length information, since those are length fields for themselves . It looks as if the first four bytes describe the length of the payload minus the length of the ASCII number, the colon and 11. How weird , she thinks while looking at it, Exploiting this could be easy or really hard. Let s see .

In the second try, she manages to set the breakpoint before actually starting the communication and is thrown back into the debugger as soon as setup.exe sent it s first packet. She hit s CTRL-F9 to let the recv function work it s magic and stops right before it would execute the final RET instruction, returning the control back to it s caller. She single-steps this instruction and instantly ends up in the code of instgui0.dll:

 .text:10045209      push 0 .text:1004520B      push ebp .text:1004520C      push ebx .text:1004520D      push edx .text:1004520E      call dword_10068764         ; recv .text:10045214      mov edx, [esi+10h] .text:10045217      mov edi, eax .text:10045219      and edx, 0FFFFFFFEh .text:1004521C      test edi, edi .text:1004521E      mov [esi+10h], edx .text:10045221      mov eax, edx .text:10045223      jz short loc_10045257 .text:10045225      cmp edi, 0FFFFFFFFh .text:10045228      jnz short loc_10045284 

Now, h3X can actually start the work and figure out what is done to the data received and hope to find a flaw in this handling so she can exploit it and use that to get into the system at this insurance company from which she hopes to get further into the network, all of it in a little less than 20 hours time. This whole thing is getting a little bit tight.

A few lines below the recv call, something else catches her eye:

 .text:1004526D loc_1004526D:                    ; CODE XREF: sub_100451A0+98 .text:1004526D                                ; sub_100451A0+9F .text:1004526D      push eax .text:1004526E      call TclWinConvertWSAError .text:10045273      add esp, 4 .text:10045276      call Tcl_GetErrno .text:1004527B      mov ecx, [esp+20h] .text:1004527F      mov [ecx], eax 

It s the code that is used when the condition at 0x10045223 is met, which would mean that the call failed or returned no data. What is causing her attention to shift to the error handling code, which she would normally ignore, are the names of the functions called. First of all, IDA only knows the names of functions that are standard in some well-known library or that are left in the file with debug information and other stuff. But this DLL came without debug information and therefore, this has to be a standard library. The prefix TCL on the calls is suspicious. h3X opens the Names window in IDA and looks at the other function names that are used in this file. A whole 559 calls have the prefix TCL.

I feel a little tickle going down my back! she says with a smile. Although h3X doesn t really know Tcl/Tk, she quickly recognizes the names as being part of a library or framework, just by the type of functions that exist there. A quick visit to www.tcl.tk, a fairly informative but somewhat badly organized site, verifies that those functions indeed are Tcl. So, you run in Tcl, hmm , she thinks. Although this is important information, she s not about to change her course of action so quickly. The use of Tcl functions can mean anything. Tcl/Tk is probably just used in the graphical user interface, which is provided by the instgui.exe as the name already suggests and the experiments involving double-clicking on the icon proved. Since the Tcl site does not show any Tcl-specific protocols, or h3X can t find them, and there is surely a protocol used since she actually saw it in action in the sniffer, Tcl itself is probably not related to the network communication.

She goes ahead and writes a little Perl program, which will produce messages that look almost like the ones she saw on the cable. First, she composes some random binary data in a variable and calculates the length of this data minus 11 to get the suspected inner length field. Then, she converts this into the little endian byte order that she suspects the length field to be in and adds the total length as ASCII value to it, including the colon. Sending this string to the instgui.exe application does exactly nothing, except for the little status below the percent bar that keeps saying r3setup connected or no r3setup connected .

She constructs a second Perl script, this time using the same data as the original setup.exe has sent over the wire before, hoping that this will actually work the same way for the first message:

 #!/usr/bin/perl -w use IO::Socket; $p1=    "40:".       "\x1D\x00\x00\x00".       "\x11".       "\x1F".       "\x9D\x02\x9D\x4F\x59\x40\x51\x7E".       "\x49\x7E\x72\x7E\x4E\x58\x6A\x51".       "\x71\x66\x7E\x9E\x82\xA1\x81\x82".       "\xB9\x99\x85\x89\x99\xA1\x05\x17".       "\x00\x00"; die "host\n" unless ($host=shift); die "socket\n" unless ($remote = IO::Socket::INET->new(PeerAddr => $host,                                   PeerPort => '59595',                                   Proto    => 'tcp')); $remote->autoflush(1); print $remote $p1; close $remote; 

Attaching OllyDbg at instgui.exe again, she can now trace what happens to the data and where might be flaws in the handling of it. This involves a number of attempts, since you have to make assumptions if a function call is going to handle some of your data or depends otherwise on input you provided or if it s just maintenance or something totally unrelated. She happens to analyze and trace a lot of functionality that only modifies some data in the data segment of the application and ends up checking and tracing the whole thing for several hours straight. Such type of work requires uninterrupted attention the whole time. It also burns the person performing it out real fast. Always throwing glances over to the clock on her desktop doesn t make it any easier. Although there are many different companies that she could try via many different ways to get into, she has the feeling that, in order to supply the information to this Knuth guy, she needs to get this box with the installer.

During the process, she slowly advances in the abstraction level upwards. While she was tracing and inspecting functions wrapped around the initial recv() call, she now tracks using memory break points where the data is handled. This is a fairly easy process commonly used when cracking programs that require some magic serial number to be entered. Right before the call to recv(), she looks up the memory address that recv() is going to write the data to. After the recv() call, she verifies that the data is in there and places a breakpoint upon memory access on a random byte of the packet. She doesn t select the first bytes, which one would do when cracking, because she s not interested in the handling of the length information supplied but in what the other data in the packet might be.

Every time a function touches the data, she s thrown back into the debugger screen and can inspect what is done here. At first, the data is copied several times. Every time this happens, she places a memory breakpoint on the destination of the copy operation once it s done. This way, she can always track the packet data through memory and doesn t get lost in the process so easily. Of course, this all takes a lot more time than h3X actually has on her hands.

The tedious work pays of after a while, because one rises from the low simple duty functions that are like workers at a construction site to the higher controlling functions, who only work with the abstract data, namely the information in the packet. At one point, she switches back into the IDA screen with the instgui.exe file still loaded and marks a particular function:

 .text:004018F4      push esi .text:004018F5      push ecx .text:004018F6      push eax .text:004018F7      push edx .text:004018F8      mov [esp+20h+arg_10], 0 .text:00401900      call sub_407169 ; important .text:00401905      add esp, 1Ch .text:00401908      test eax, eax .text:0040190A      jz short loc_401919 .text:0040190C      cmp eax, 1 .text:0040190F      jz short loc_401919 .text:00401911      pop esi .text:00401912      mov eax, offset aDecompressionF ; "decompression failed" .text:00401917      pop ebx .text:00401918      retn 

The data that used to be part of the packet is fed into the call at 0x00401900, which she therefore marked as really important. Inside the function, there is the usual check for basic stuff like supplied NULL pointers and then a decision is made based on one of the function call arguments. This decision leads to three possible outcomes , two of which are calls to other functions:

 .text:0040719A loc_40719A:     ; CODE XREF: sub_407169+2Bj .text:0040719A       push [ebp+arg_18] .text:0040719D       push [ebp+arg_14] .text:004071A0       push [ebp+arg_10] .text:004071A3       push [ebp+arg_C] .text:004071A6       push [ebp+arg_8] .text:004071A9       push [ebp+arg_4] .text:004071AC       push [ebp+arg_0] .text:004071AF       call sub_40984B  .text:004071B4       jmp short loc_4071D0  .text:004071B6 ; ----------------------------------------------------------- .text:004071B6  .text:004071B6 loc_4071B6:     ; CODE XREF: sub_407169+28j .text:004071B6       push [ebp+arg_18] .text:004071B9       push [ebp+arg_14] .text:004071BC       push [ebp+arg_10] .text:004071BF       push [ebp+arg_C] .text:004071C2       push [ebp+arg_8] .text:004071C5       push [ebp+arg_4] .text:004071C8       push [ebp+arg_0] .text:004071CB       call sub_4079CF 

The code in her case always flows through the upper function, but they are both identically called. Judging from the message at 0x00401912 that says decompression failed , she now assumes that whatever is transported over the wire is a compressed something. Checks on the actual parameters in the debugger show that the first is a pointer to her data, the second is the length of this data, the third points to apparently large but unused memory, and the fourth says how large this unused memory is. When she steps the function call, something materializes in the later memory area that looks a lot more like clear text. It reads:

 LvProtocolVersion 10 7684618 

That s a hell of a compression, transmitting 40 bytes compressed data to transport 28 bytes of clear text , she thinks and smiles. From here on, it only needs to be verified and all the work of several hours will pay off with a wonderful, simple 0day exploit. She now places a breakpoint only at the call of the general decompression function and can run the program normally, only interrupting it to read the clear text commands that come by. The next one is:

 4C 76 54 6F 74 61 6C 50 72 6F 67 72 65 73 73 20  LvTotalProgress 30 0A                                            0. 

She also duly notes that a linefeed character needs to be transmitted with the command. Now it s time to play with the data just a bit, before it s given back to the main functionality of instgui.exe. The purpose of this activity is to see if a certain theory she already has is correct. Right after the data is decompressed and placed in the corresponding output buffer, she stops the program and changes the clear text data to

 exec calc.exe 

and appends a linefeed character behind it. Hoping the best, she presses the F9 key slowly to instruct the debugger to continue. She s thrown back into Olly several times again as it decompresses other, more lengthy gibberish into plain text, but after a while, instgui.exe keeps running and then, the Windows desktop calculator appears on her screen. She s almost grinning in circles around her face now. It was a wild guess, but apparently she got it right. The setup.exe program sends pure Tcl commands through a compression algorithm, to pack it off to the instgui.exe program, which in turn decompresses and executes the script “ no authentication required.

What that means for h3X is a rapid improvement on her general situation and, consequently, her current mood. She doesn t need any shell code, return address, or other things that can go wrong every time she tries something. The only thing she needs is put a few Tcl instructions compressed on the network connection and shove it over to the waiting instgui.exe at the insurance company. That should be a piece of cake. The only thing she s lacking right now is the ability to compress arbitrary data with the algorithm, and that s because she doesn t know how the algorithm works. Normally, this would mean reverse engineering the complete algorithm based on the functions she already identified. But a quick look at the code and another at the clock rules this option out.

Instead, she loads the counterpart program setup.exe into another IDA instance and waits for the initial process to finish. If setup.exe is compressing the data, there has to be a comparable function call in setup.exe, performing the compression. All she has to do is break before that, change the data and point her setup.exe to the target system using the convenient “g command line switch. It doesn t take long for her to identify the correct function now that she knows what she s looking for. The string compression failed , which she correctly assumes exists, leads her right to the correct code location. Relaxing enormously, she goes ahead and compiles a list of things that she wants the remote instgui.exe to do. She also goes back into the Nmap log and looks for potential ways to get to the target system, once her little modified SAP setup commands are executed. The lower ports up to 2048 are filtered, but everything above that seems to be OK. Therefore, the list of commands she wants to execute looks like this:

 net start termservice net start telnet net user Administrator lala 

The purpose of these commands is to start the Terminal Service for administration, since this one is running on port 3389 and is therefore not filtered. She starts the Telnet service as well, although it s filtered, just for the heck of it. The last command assumes that the instgui.exe program was run by a user who is allowed to change the Administrator password, and will do so, without requiring the original password to be entered. The assumption about Administrator himself running instgui.exe is probably right, since who would run a setup routine as a unprivileged user account on a server in a major DMZ. But then again, who would leave a setup program sitting there for the weekend ?

Checking the Nmap file a last time, she almost falls over from her chair . How could she have overlooked that the Terminal service is already running. Right , she remembers, ˜ this thing can t be turned off usually “ at least not in the services tab, which probably explains why it s there . This, of course, reduces the number of commands she has to issue to exactly one. She loads setup.exe into OllyDbg and sets the breakpoint right before the compression algorithm is called. Then she runs setup.exe with the IP address of the target system behind the magic “g switch and fires it off.

Fully concentrating, she looks at the sniffer to see if it actually communicates with the target, which it does. When the debugger snaps into halt mode, she s so tense that she makes a tiny jump back from the keyboard and mouse. She opens the clear text memory and pastes her pre-crafted command in there. Carefully, so as not to alter the general size of the data, so that the compression result will be almost the same:

 01A7FBC8  4C 76 54 6F 74 61 6C 50 72 6F 67 72 65 73 73 20  LvTotalProgress 01A7FBD8  35 30 0A 65 78 65 63 20 63 6D 64 2E 65 78 65 20  50.exec cmd.exe 01A7FBE8  2F 63 20 6E 65 74 20 75 73 65 72 20 41 64 6D 69  /c net user Admi 01A7FBF8  6E 69 73 74 72 61 74 6F 72 20 6C 61 6C 61 0A 4C  nistrator lala.L 01A7FC08  76 54 6F 74 61 6C 50 72 6F 67 72 65 73 73 20 31  vTotalProgress 1 01A7FC18  30 30 0A 57 48 45 4E 5F 59 4F 55 5F 52 45 41 44  00.WHEN_YOU_READ 01A7FC28  5F 54 48 49 53 5F 59 4F 55 5F 52 5F 4F 57 4E 45  _THIS_YOU_R_OWNE 01A7FC38  44 20 41 72 65 61 3A 33 35 20 6D 73 67 49 64 3A  D Area:35 msgId: 01A7FC48  33 39 20 6D 73 67 54 79 70 65 3A 32 20 6D 73 67  39 msgType:2 msg 01A7FC58  53 65 76 65 72 69 74 79 3A 32 20 73 74 72 69 6E  Severity:2 strin 01A7FC68  67 50 61 72 61 6D 3A 30 3A 37 3A 35 32 33 33 35  gParam:0:7:52335 01A7FC78  33 34 35 35 34 35 35 35 30 20 73 74 72 69 6E 67  345545550 string 01A7FC88  50 61 72 61 6D 3A 31 3A 31 31 3A 34 34 36 35 36  Param:1:11:44656 01A7FC98  33 32 30 32 30 33 36 32 30 33 32 33 30 33 30 33  3202036203230303 01A7FCA8  31 20 74 79 70 65 6F 66 50 61 72 61 6D 3A 30 3A  1 typeofParam:0: 01A7FCB8  34 20 74 79 70 65 6F 66 50 61 72 61 6D 3A 31 3A  4 typeofParam:1: 01A7FCC8  34 20 74 79 70 65 6F 66 50 61 72 61 6D 3A 32 3A  4 typeofParam:2: 

The commands calling LvTotalProgress are not really needed, but despite the serious situation she s in, a little fun is in order. Those commands make actually sure, that the percent bar will travel to 50% before and to 100% after the Administrator password was reset. After all, it s an installer and those

are supposed to say 100% when they are done. She steps over the function call and verifies the outcome:

 00EFE8B0  82 01 00 00 12 1F 9D 02 E9 6A EE 56 13 86 A1 38  .........j.V...8 00EFE8C0  80 DF F7 29 CE 13 6C 49 4E 4E 9D E7 AE 60 41 41  ...)..lINN..`AA 00EFE8D0  54 66 87 EC AA 84 36 96 42 3F 46 12 45 DF 7E 91  Tf....6.B?F.E.~. 00EFE8E0  B1 8B 86 24 F0 FF 71 3E B2 BF 57 73 30 C3 C9 CD  ...$..q>..Ws0... 00EFE8F0  9D B3 DE 03 89 CC 3E 6C 03 CD D8 BE C5 00 EF 0D  ......>l........ 00EFE900  4C 36 C0 CD 5B 07 45 3B F6 53 EF 83 33 61 76 30  L6..[.E;.S..3av0 00EFE910  98 C1 64 FB 64 5C 0A 91 5D B6 E5 A1 FE 3E 7E D5  ..d.d\..]....>~. 00EFE920  9F 65 B1 A9 AB ED EE FC A7 FA 78 39 94 1B 28 9C  .e.......x9..(. 00EFE930  35 8C 04 A3 EF 76 2D E3 FA 15 AA E7 8F 65 F5 4A  5....v-......e.J 00EFE940  67 7B B7 AE 0F CF A8 F8 51 3F 75 27 E3 CC C8 82  g{.....Q?u'.... 00EFE950  57 4C 0A 91 50 13 C5 4B 62 51 96 2C 25 6B 9D 53  WL..P..KbQ.,%k.S 00EFE960  8E 4A 28 81 79 7C 0A 45 3C 12 42 DC 3D 5F FF D7  .J(.y.E<.B.=_.. 00EFE970  E8 85 65 62 C5 CB 7E 4C AC 13 53 E2 3C F1 2A F1  ..eb..~L..S.<.*. 00EFE980  47 E2 35 CB EC 17 00 00 08 00 00 00 08 00 00 00  G.5............. 

It s pure gibberish, but it sure looks like it should.

Holding her breath , she continues the execution of setup.exe and sees the packets travel to their destination in the sniffer. Setup loses the connection to instgui.exe almost instantly after her little trick, but that was expected. Instgui.exe will have noticed that WHEN_YOU_READ_THIS_ YOU_R_OWNED is not a command and told the user so, hereby closing the connection to free itself up for the next installation/attack that might come down the line. She switches to the Linux command line and starts rdesktop, a free implementation that can talk to Windows Terminal Services. When the blue-greenish screen of Windows comes up with the login box, she enters Administrator and what is now her password and clicks OK . The box instantly disappears and reveals a typical Windows desktop with a number of additional icons.

YES! she cries in the room, eases back into her seat, and starts to move the mouse over the very remote desktop of her new machine. To her absolute delight, she sees a little colorful icon on the desktop, which shows a yellow figure with a silver gray ball as head standing in front of a blue box and a blue prism, announcing the existence of an installed SAP GUI software, which is the presentation front end to and R/3 system.

She double-clicks on the icon and sees with pure joy that the expected dialog appears, asking her which SAP instance she wants to talk to. She can actually select several from the list, which speaks for the size of the installation she now has unlimited access to. The only thing between her and the information that could save her life is a username and a password. She enters:

 Username: SAP* Password: 07061992