Security.my

Our finding here is collaboration with @rempah. Long short story, we run a fuzzer (AFL) targeting the ngiflib version 0.4. 

Here is how I dissassembled the payload.bin for SX OS

Vulnerability: NULL Pointer Dereference Product: SlimPDF Reader - (SlimPDF Reader.exe) Tested on: Windows 10 Reference: https://cwe.mitre.org/data/definitions/476.html Impact: Denial of Service (can be achieved via Remote) Reported: https://support.investintech.com/hc/en-us/requests/14369

Summary A vulnerability in SlimPDF Reader could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition.

The vulnerability is due to improper processing of certain PDF documents by the affected system. An attacker could exploit this vulnerability by persuading a trusted user to open a malicious PDF document using the affected application. When the application processes the malicious document, it may dereference a NULL pointer. The error could cause the application to crash, resulting in a DoS condition.

Vulnerability Title: Sharutils (unshar) Buffer Overflow

CVE: CVE-2018-1000097

Date (reported): Feb 21, 2018

Vendor: https://www.gnu.org/software/sharutils/

Software Link: https://ftp.gnu.org/gnu/sharutils/sharutils-4.15.2.tar.gz

Affected Version: 4.15.2 (stable released May 30, 2015)

Tested on: Ubuntu 16.04 LTS

Severity: Medium

Summary

Sharutils is a package for creating and manipulating shell archives that can be readily emailed. A shell archive is a file that can be processed by a Bourne-type shell to unpack the original collection of files. Shar makes so-called shell archives out of many files, preparing them for transmission by electronic mail services (converting binary data to ASCII representations, breaking the text into multiple shar scripts, etc.). Unshar is the safe way to extract and reassemble the original files. It will automatically strip off the mail headers and other introductory text.

Vulnerability Description

Sharutils sharutils (unshar command) version 4.15.2 contains a Buffer Overflow vulnerability in Affected component on the file unshar.c at line 75, function looks_like_c_code. Failure to perform checking of the buffer containing input line that can result in Could lead to code execution. This attack appear to be exploitable via Victim have to run unshar command on a specially crafted file.

Sharutils Fuzzing

We fuzzed the sharutils package (unshar) with AFL and came up with quite number of results. Our setup:

Compile the program with the following command "CC=afl-gcc CXX=afl-g++ AFL_USE_ASAN=1 ./configure"

Once it passed, then run "AFL_USE_ASAN=1 make"

This will compile the binary with ASAN and AFL.

Once configure properly, we run the AFL fuzzer with the following command "afl-fuzz -m none -i input/ -o output/ -- ./unshar @@". Within 4 hours, we managed to get 5 unique crashed. See the result of AFL:

We then verified if the crashed are indeed valid. 

john@fuzzing:~/sharutils-4.15.2/src$ ./unshar output/crashes/id:000000,sig:06,src:000052,op:havoc,rep:64 ================================================================= ==20801==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb6101100 at pc 0x0804c6e3 bp 0xbfcb9138 sp 0xbfcb9128 READ of size 1 at 0xb6101100 thread T0 #0 0x804c6e2 in looks_like_c_code /home/john/sharutils-4.15.2/src/unshar.c:81 #1 0x804c6e2 in find_archive /home/john/sharutils-4.15.2/src/unshar.c:253 #2 0x804c6e2 in unshar_file /home/john/sharutils-4.15.2/src/unshar.c:379 #3 0x804a2f4 in validate_fname /home/john/sharutils-4.15.2/src/unshar-opts.c:604 #4 0x804a2f4 in main /home/john/sharutils-4.15.2/src/unshar-opts.c:639 #5 0xb787d636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636) #6 0x804ab95 (/home/john/sharutils-4.15.2/src/unshar+0x804ab95) 0xb6101100 is located 0 bytes to the right of 4096-byte region [0xb6100100,0xb6101100) allocated by thread T0 here: #0 0xb7ab1dee in malloc (/usr/lib/i386-linux-gnu/libasan.so.2+0x96dee) #1 0x804c9e4 in init_unshar /home/john/sharutils-4.15.2/src/unshar.c:450 #2 0xb787d636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/john/sharutils-4.15.2/src/unshar.c:81 looks_like_c_code Shadow bytes around the buggy address: 0x36c201d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36c201e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36c201f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36c20200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36c20210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x36c20220:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36c20230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36c20240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36c20250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36c20260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36c20270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe ==20801==ABORTING

Vulnerability

Our observation found that it was from unshar.c and the root cause started on "find_archive()". In the line 449, we can see rw_buffer has allocated rw_base_size which is 8192 bytes. 

Line 449 - 450:

rw_base_size = GET_PAGE_SIZE; rw_buffer = malloc (rw_base_size);

At line 45, you can see the GET_PAGE_SIZE buffer size has been set to 8192 bytes. 

Line 45:

# define GET_PAGE_SIZE 8192

We observed the size of BUFSIZ was allocated to 8192 bytes, however in this case the rw_base_size size is not similar with the memory page allocation. Thus, the issue allow to write out of the allocated memory for rw_buffer. Failure to do so, can lead to application crash. 

Line 243 - 249:

if (!fgets (rw_buffer, BUFSIZ, file)) // BUFSIZ is not equal to rw_buffer (allocated buffer) that leads to overflow { if (!start) error (0, 0, _("Found no shell commands in %s"), name); return false; }

Patch

We reported the security issue via proper channel by sending an email to [email protected] and to Bugtraq mailing-list. Initially, we find out Red Hat / Fedora Security team taking care of the issue, https://bugzilla.redhat.com/show_bug.cgi?id=1548018 and ship the fixed to stable repository on 2018-03-06. It then follow by Ubuntu security and published advisory https://usn.ubuntu.com/3605-1/ on 2018-03-22. 

Patch Diff:

Vulnerability Title: JPEGSnoop "JfifDecode.cpp" Integer Division by Zero Date: 6/5/2017 Vendor: http://www.impulseadventure.com/photo/ Software Link: http://www.impulseadventure.com/dl.php?file=JPEGsnoop_v1_7_5.zip Affected Version: 1.7.5 Tested on: Windows 7 (32-bit), Windows 10

Summary JPEGsnoop is a free Windows application that examines and decodes the inner details of JPEG, MotionJPEG AVI and Photoshop files. It can also be used to analyze the source of an image to test its authenticity.

Vulnerability Description JPEGsnoop suffers from a division by zero attack when handling JFIF decoding, resulting in denial of service vulnerability and possibly loss of data. The vulnerable part found to perform a calculations that require all tables to be present. Details of the divide by zero issue:

⦁ Exception happened on the EIP:0x011d2a1d, this can be disassemble (instruction pointer leads to where it crash). ⦁ Disassemble of EIP 0:000> u 011d2a1d JPEGsnoop+0x32a1d: 011d2a1d f7b48f78110000  div     eax,dword ptr [edi+ecx*4+1178h] 011d2a24 33d2            xor     edx,edx 011d2a26 894508          mov     dword ptr [ebp+8],eax 011d2a29 8b877c190000    mov     eax,dword ptr [edi+197Ch] 011d2a2f f7b48f78150000  div     eax,dword ptr [edi+ecx*4+1578h] 011d2a36 83bf8c19000002  cmp     dword ptr [edi+198Ch],2 011d2a3d 7414            je      JPEGsnoop+0x32a53 (011d2a53) 011d2a3f 50              push    eax ⦁ We need to take note on the registers where exception happened. This will help us to determine the exception are indeed correct. 0:000> r eax=00000000 ebx=00eb2378 ecx=00000000 edx=00000000 esi=05f5ab28 edi=00eb09e8 eip=011d2a1d esp=007ce5c8 ebp=007ce5f4 iopl=0         nv up ei pl zr na pe nc cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246 JPEGsnoop+0x32a1d: 011d2a1d f7b48f78110000  div     eax,dword ptr [edi+ecx*4+1178h] ds:002b:00eb1b60=00000000

⦁ We can see the instruction "div eax, dword ptr [edi+ecx*4+1178h], so we break down as: edi = 00eb09e8 ecx = 00000000 * 4 0x1178

The math: dword ptr --- 00eb09e8 + 00000000 * 4 + 1178 = 0xeb1b60 <--- data segment eax --- 0x00000000

Divide eax with the data segment value: 0xeb1b60 / 0x00000000 = value cannot be divide with zero

Thus, resulting to denial of service to the vulnerable application.

Below are the results of crash dump and disassembly of the root cause:

---Crash Dump--- (5d4.39c): Integer divide-by-zero - code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for JPEGsnoop.exe *** ERROR: Module load completed but symbols could not be loaded for JPEGsnoop.exe eax=00000000 ebx=00eb2378 ecx=00000000 edx=00000000 esi=05f5ab28 edi=00eb09e8 eip=011d2a1d esp=007ce5c8 ebp=007ce5f4 iopl=0         nv up ei pl zr na pe nc cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246 JPEGsnoop+0x32a1d: 011d2a1d f7b48f78110000  div     eax,dword ptr [edi+ecx*4+1178h] ds:002b:00eb1b60=00000000

---Disassembly--- .text:004329C2 loc_4329C2:                             ; CODE XREF: sub_432800+1B1j .text:004329C2                                         ; sub_432800+1BBj .text:004329C2                 push    3               ; int .text:004329C4                 lea     ebx, [edi+1990h] .text:004329CA                 push    offset a?x?     ; "?x?" .text:004329CF                 mov     ecx, ebx .text:004329D1                 call    sub_401AC0 .text:004329D6                 push    4               ; int .text:004329D8                 lea     ecx, [edi+1DE8h] .text:004329DE                 push    offset aNone    ; "NONE" .text:004329E3                 call    sub_401AC0 .text:004329E8                 push    4               ; int .text:004329EA                 lea     ecx, [edi+1DECh] .text:004329F0                 push    offset aNone    ; "NONE" .text:004329F5                 call    sub_401AC0 .text:004329FA                 cmp     byte ptr [edi+20h], 0 .text:004329FE                 jz      loc_432B3F .text:00432A04                 mov     eax, [edi+974h] .text:00432A0A                 cmp     eax, 3 .text:00432A0D                 jnz     short loc_432A67 .text:00432A0F                 mov     ecx, [edi+980h] .text:00432A15                 mov     eax, [edi+1978h] .text:00432A1B                 xor     edx, edx .text:00432A1D                 div     dword ptr [edi+ecx*4+1178h] <--- vulnerability here .text:00432A24                 xor     edx, edx .text:00432A26                 mov     dword ptr [ebp+ArgList], eax .text:00432A29                 mov     eax, [edi+197Ch] .text:00432A2F                 div     dword ptr [edi+ecx*4+1578h] .text:00432A36                 cmp     dword ptr [edi+198Ch], 2 .text:00432A3D                 jz      short loc_432A53 .text:00432A3F                 push    eax .text:00432A40                 push    dword ptr [ebp+ArgList] ; ArgList .text:00432A43                 push    offset aUxU     ; "%ux%u" .text:00432A48                 push    ebx             ; int .text:00432A49                 call    sub_401650 .text:00432A4E                 add     esp, 10h .text:00432A51                 jmp     short loc_432A78 .text:00432A53 ; --------------------------------------------------------------------------- .text:00432A53 .text:00432A53 loc_432A53:                             ; CODE XREF: sub_432800+23Dj .text:00432A53                 push    dword ptr [ebp+ArgList] .text:00432A56                 push    eax             ; ArgList .text:00432A57                 push    offset aUxU     ; "%ux%u" .text:00432A5C                 push    ebx             ; int .text:00432A5D                 call    sub_401650 .text:00432A62                 add     esp, 10h .text:00432A65                 jmp     short loc_432A78

This is a tough challenge. The bug is SQL injection in subdomain param. And it is blind based. So we need sqlmap for that. :)

Payload: select1.notepad.wargames.my:8080'

Then, dump the admin email as we can reset password later. Run sqlmap again and grab the admin token. Now, we can reset admin password and login to admin portal.

There are admin page to edit template. Here come the RCE to grab the flag. We need to use phpinfo() to get the path first. Then after checking for disabled_function, lucky file_get_contents is allowed. Use that function to get the flag.

This web challenge hints are:

do you able to retrieve the source code? - need to download the source code!!!

4 character, browse it and im yours - We dont understand this hint. lol.

silly developer leaving his code changes tracker folder.. - tracker??.. hurmm..

Fuzzing for directory/files and we got .git folder. Nice, public git folder meaning we can get the source code.

We use this tools to dump and extract the source code: https://github.com/internetwache/GitTools

Which folder do we need? Lets check the main header.

So we use the 2-6f3.....................771d. And the flag is in index.php file.

We are landed to default page of Ubuntu. The hints are:

what are other default page for apache2 with mod_php installed - ok, must be index.php

Just do it! - still dont understant until now. lol.

As the challenge is MailMarketer, the bug might be in “mail“ function related. There are a page to sent email and the function works. We try to sent email and look at the headers (took some time to notice this). They use phpmailer version 5.2.21 which has public exploit. You can refer to this: https://www.exploit-db.com/exploits/43056/.

The exploit payload is using <img src="<file to read>">. So, what do we need to read? After some fuzzing, there are flag.php file. We include the file:

<img src="</var/www/html/flag.php>">

...sent email and we got the flag.php as attachment which contain flag.

This is the pcap challenge. The hints are:

he is tracing backwardly. - read it from bottom to up?

nothing to do with Traceroute - ok then..

"hello IT, I can't access to this server" .. what IT support always start with? - ping?

RFC 792 - icmp?

Lets fireup wireshark and apply this filter: (icmp) && (ip.src == 192.168.1.8).

Now, export the displayed result by Export Packet Dissections -> As Plain Text.

As hint #1 said “tracing backwardly“, we look the data from bottom of the file. And notice there are differences between each packet frames. That is the flag for this challenge.

We didn't manage to solve this in time but wanted to share my notes on it.

After beautifying the source, we used an AST solver (http://m1el.github.io/esdeobfuscate/) to clean the code up (thanks to @najashark for pointing this out).

Next we tried to narrow down the keyspace using the code below.

<html> <body> <script> function nyahsulit(flag, key, input) { keluar = ''; for(i = 0; i < flag.length; i++) { var fi = flag[i].charCodeAt(0); kt = '' var alch = '0123456789abcdef'; for(j=0;j<16;j++){ if(i-1 < 0) var v_xor = fi^(alch[j].charCodeAt(0)); else var v_xor = fi^(alch[j].charCodeAt(0)^(i-1)); if(v_xor >= 0x2e && v_xor <= 0x7E){ kt += "(" + alch[j] + ")" + String.fromCharCode(v_xor) + ", "; //kt += String.fromCharCode(v_xor) + ", "; } } //var kk = key.charCodeAt(0); //temp = String.fromCharCode(fi^kk); //key = String.fromCharCode(i^input[i].charCodeAt(0)); keluar += "[" + i + "] = " + kt + "\n"; } return(keluar); } var flag = window.decodeURIComponent('f%7F*%3A%5CM%0DN%0B%02L%1A%02X%084O%15Z)JC%04~WHl%18eH%1DP'); var key = String.fromCharCode(0x11); var ret = nyahsulit(flag, key, 'd23456'); console.log(ret); </script> </body> </html>

And we also tried bruteforcing using the code below (this would have taken too long)

import md5 import itertools import string def bruteforce(charset, maxlength): return (''.join(candidate) for candidate in itertools.chain.from_iterable(itertools.product(charset, repeat=i) for i in range(maxlength, maxlength + 1))) for comb in bruteforce(string.ascii_lowercase, 12): #s = "0" * (3-len(s)) + s m = md5.new() m.update("".join(comb)) h = m.hexdigest() if h[0] == '8' and h[1] == 'f' and h[2] == 'a' and h[3] == 'e' and h[4] == '2' and h[-2] == '3': print("".join(comb), h)

Another alternative we tried was trying to filter out the first few chars of the hash at https://md5db.net/explore/18FA

Decryption key: bountyhunter

This challenge a pcap with USB traffic is provided, after analysis, we found that it involved keyboard input and transfer of files to a flashdrive.

We first extracted contents of the flashdrive to find a python script below.

Next we isolated and extracted the keyboard inputs and used the python processing script below (taken and adapted from https://habrahabr.ru/post/335012/) to extract the keystrokes.

#!/usr/bin/python import binascii import dpkt import struct import sys # Start the pcap file parsing f = open(sys.argv[1], 'rb') pcap = dpkt.pcap.Reader(f) # Create a partial mapping from keycodes to ASCII chars keys = {} keys.update({ i + 0x4: chr(i + ord('a')) for i in range(26) }) keys.update({ i + 0x1e: chr(i + ord('1')) for i in range(9) }) keys[0x27] = '0' keys.update({ 0x28: '\n', 0x2a: '[BACKSPACE]', 0x2b: '\t', 0x2c: ' ', 0x2d: '-', 0x2e: '=', 0x2f: '[', 0x30: ']', 0x31: '\\', 0x33: ';', 0x34: '\'', 0x35: '`', 0x36: ',', 0x37: '.', 0x38: '/', 0x4f: '[RIGHT_ARROW]', 0x50: '[LEFT_ARROW]', 0x52: '[KEY_UP]', 0x58: '[ENTER]' }) keys_shift = {} keys_shift.update({ i + 0x4: chr(i + ord('A')) for i in range(26) }) keys_shift.update({ 0x1e: '!', 0x1f: '@', 0x20: '#', 0x21: '$', 0x22: '%', 0x23: '^', 0x24: '&', 0x25: '*', 0x26: '(', 0x27: ')', 0x2e: '+', 0x2f: '{', 0x30: '}', 0x31: '|', 0x33: ':', 0x34: '"', 0x35: '~', 0x36: '<', 0x37: '>', 0x38: '?', }) txt = '' # Then iterate over each USB frame i = 0 for ts, buf in pcap: i += 1 print(repr(txt)) buf = buf[-8:] if buf == "\x00" * 8: continue #print(repr(buf)) key_code = ord(buf[2]) shift_state = ord(buf[0]) if not key_code: continue if shift_state: # print('[%d] key_code: %s char: %s' % (i, hex(key_code), keys_shift[key_code])) txt += keys_shift[key_code] else: #print('[%d] key_code: %s char: %s' % (i, hex(key_code), keys[key_code])) try: txt += keys[key_code] except: print(hex(key_code)) txt += "*" # sys.stdout.write(keys[key_code]) print(txt)

This gave us the result below.

Reordering the keystrokes gave us the below and running it provided us with the flag.

Reverse engineer protection to recover data. Below is the algorithm used,

After doing abit of digging, we find a very very very similar implementation from Microsoft @ https://msdn.microsoft.com/en-us/library/windows/desktop/aa382044(v=vs.85).aspx

The password is derived from the file name with the first char replaced, we implemented this and decrypted the flag.

Below is the code which generated the first char of the password.

Below is the decrypted flag file

This challenge required you to connect via SCTP protocol, do that and it will give you the flag, we used the template code from http://matrixsust.blogspot.my/2011/11/basic-sctp-client-server-code-in-c.html

Below is the decompiled code we identified flag sending from

Using the template C code, we managed to connect and get the flag.

This challenge is a fairly simple one, you connect to it, then it connect back to you on a random port with the flag. We solved this thanks to a many-to-one nat with Mikrotik.

Below is the code that does the connect back.

And the flag is xor’d with the port number its connecting back with.

I then used my Mikrotik to forward all connections from this server to a netcat listening on my pc. The connection finally came back on port 51038 and using the data received, we are able to recover the flag.

import struct #wgmy{r34l_m4n_w4tch_br4zz3r5} key = 0xC4D0 data = open("flag_51038", 'rb').read() x = map(''.join, zip(*[iter(data)]*4)) for y in x: y = struct.unpack("<L", y)[0] y = y ^ key print(struct.pack("<L", y))

This challenge requires you to download a 1GB file from [http://1511.wargames.my/](http://1511.wargames.my/), the only catch is, each IP is rate limited to 5600bps.

We solved it by using the HTTP Range Header

import http.client conn = http.client.HTTPConnection('1511.wargames.my') conn.request("GET", '/images.img', headers={'Range': 'bytes=1073741820-1073741857'}) resp = conn.getresponse() resp.status if resp.status == http.client.PARTIAL_CONTENT: print("OK") resp.getheader('content-range') content = resp.read() print(len(content)) print(content[::-1])

Congratulations to the winners and kudos to the organizers for a great game. See you guys again next year!!!!!!

This vulnerability was found on a huawei STB that is used by a popular ISP here in Malaysia. The flaw lies in the fact that the software relies on the client to enforce subscription validation.

The web-server that the STB connects to retrieve the UI runs over HTTP and this parameter is modifiable through a configuration menu. By relaying HTTP traffic to a custom proxy running on the STB, we can substitute the requested HTML files that contain subscription validation with local files that have them removed and enable the viewing of all the channels for free.

This vulnerability affects all the STBs (Mips/Arm/Android Firmware)

Source code of the custom proxy used is available at @ http://github.com/klks/swproxy