Ragnar 2010

Marv

There are many basic shellcodes that can be emulated from the beginning from the end providing IOC like where is connecting and so on. But what can we do when the emulation get stuck at some point?

The console has many tools to interact with the emulator like it was a debugger but the shellcode really is not being executed so is safer than a debugger.

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin -vv

In some shellcodes the emulator emulates millions of instructions without problem, but in this case at instruction number 176 there is a crash, the [esp + 30h] contain an unexpected 0xffffffff.

There are two ways to trace the memory, tracing all memory operations with -m or inspecting specific place with -i which allow to use registers to express the memory location:

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin -i 'dword ptr [esp + 0x30]'

Now we know that in position 174 the value 0xffffffff is set.

But we have more control if we set the console at first instruction with -c 1 and set a memory breakpoint on write.

This "dec" instruction changes the zero for the 0xffffffff, and the instruction 90 is what actually is changing the stack value.

Lets trace the eax register to see if its a kind of counter or what is doing.

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin --reg eax

Eax is not a counter, is getting hardcoded values which is probably an API name:

In this case this shellcode depend on previous states and crash also in the debugger because of register values. this is just an example of how to operate in cases where is not fully emulated.

In next chapter will see how to unpack and dump to disk using the emulator.

Nmap is a free utility tool for network discovery, port scanning and security auditing, even though we can use it for more than that but in this article we will learn how to do these three things with nmap.

The original author of nmap is Gordon Lyon (Fyodor). Nmap is licensed under GPL v2 and has available ports in many different languages. Nmap is available for Linux, Windows, and Mac OS X. You can download your copy of nmap from their website.

Lets get started with nmap.

When performing pentests we always look for networks we are going to attack. We need to identify live hosts on the network so that we can attack them. There are plenty of tools available for finding live hosts on a network but nmap is one of the best tools for doing this job.

Lets start with simple host (target) discovery scans i,e scans that will tell us which ip address is up on our target network. Those ip addresses which are up on our target network are the ones that are assigned to a device connected on our target network. Every device on the network is going to have a unique ip address.
To perform a simple host discovery scan we use the following command

nmap -v -sn 10.10.10.0/24

flags we used in the above command are
-v for verbose output
-sn to disable port scan (we don't want to scan for ports right now)

Following the flags is the ip address of the target network on which we want to look for live hosts. The /24 at the end of the ip address is the CIDR that specifies the subnet of the network on which we are looking for live hosts.

After running the above command you should get a list of live hosts on your target network.
If you just want to know the list of ip addresses your command is going to scan, you can use the -sL flag of the nmap like this.

nmap -sL 10.10.10.0/24

this command will simply output the list of ip addresses to scan.

We sometimes want to do dns resolution (resolving ip addresses to domain names) when performing our network scans and sometimes we don't want dns resolution. While performing a host discovery scan with nmap if we want to perform dns resolution we use -R flag in our command like this:

nmap -v -sn -R 10.10.10.0/24

And if we don't want to perform dns resolution of hosts during our scan we add the -n flag to our command like this:

nmap -v -sn -n 10.10.10.0/24

After we have discovered the hosts that are up on our target network, we usually put the ip addresses of these hosts into a file for further enumeration.

Next step in our enumeration would be to detect which operating system and which ports are running on these live hosts, for that we run this command:

nmap -O -v 10.10.10.119

here we use -O (capital o not zero) for operating system detection and by default nmap performs SYN Scan for port discovery. However nmap scans for 1000 ports only by default of a particular host.

To make nmap go over a list of ip addresses in a file we use -iL flag like this:

nmap -O -v -iL targetlist

where targetlist is the name of the file which contains ip addresses that we want to perform port scan on.

To make nmap scan all the ports of a target we use the -p flag like this:

nmap -p- -v 10.10.10.121

We can also specify a range of ports using the -p flag like this:

nmap -p1-500 -v 10.10.10.121

here 1-500 means scan all the ports from 1 to 500.

We can use a number of scan techniques to discover open ports on our network but I will only discuss some of them for brevity.

We can perform a TCP SYN scan using nmap with -sS flag like this:

nmap -sS -v 10.10.10.150

We have also flags for TCP connect and ACK scans which are -sT -sA

nmap -sT -v 10.10.10.150

nmap -sA -v 10.10.10.150

We can also perform UDP scan as well instead of TCP scan using -sU flag

nmap -sU -v 10.10.10.150

We can perform TCP Null, FIN, and Xmas scans using the flags -sN, -sF, -sX

nmap -sN -v 10.10.10.150

nmap -sF -v 10.10.10.150

nmap -sX -v 10.10.10.150

If you don't know what these scans are then please visit Port Scanning Techniques and Algorithms for explanation.

After discovering the open ports on our target host, we want to enumerate what services are running on those open ports. To enumerate services and versions information on open ports we use the -sV flag like this:

nmap -sV -v 10.10.10.118

This should give us information about what services are running on what ports and what versions of those services are running on the target host.

nmap has an interesting feature called NSE nmap scripting engine. It allows users to write their own scripts, using the Lua programming language, to automate a wide variety of networking tasks. nmap ships with a diverse set of scripts which are very helpful to enumerate a target. To use the nmap default set of scripts while enumerating the target, we use the -sC flag like this:

nmap -sC -sV -v 10.10.10.118

We can also save the results of our nmap scans to a file using the -o flag like this

nmap -sC -sV -v -oA defaultscan 10.10.10.119

here -oA tells the nmap to output results in the three major formats at once and defaultscan is the name of the file that will be prepended to all the three output files.

This is the end of this short tutorial see you next time.

References:
https://nmap.org/book/scan-methods-null-fin-xmas-scan.html

Related word

Marv

Vendor backdoors are the worst. Sloppy coding leading to unintentional "bugdoors" is somewhat defendable, but flat out backdoors are always unacceptable. Todays example is brought to you by Arris. A great quote from their site -

Subscribers want their internet to be two things, fast and worry free. Cable operators deploy services to meet the speed expectations, and trust ARRIS to provide the cable modems that deliver the reliability.

Nothing spells "trust" and "worry free" like a backdoor account, right?! Anyways, the following was observed on an Arris TG862G cable modem running the following firmware version -TS070563_092012_MODEL_862_GW

After successfully providing the correct login and password to the modems administration page, the following cookie is set (client side):

Cookie: credential=eyJ2YWxpZCI6dHJ1ZSwidGVjaG5pY2lhbiI6ZmFsc2UsImNyZWRlbnRpYWwiOiJZV1J0YVc0NmNHRnpjM2R2Y21RPSIsInByaW1hcnlPbmx5IjpmYWxzZSwiYWNjZXNzIjp7IkFMTCI6dHJ1ZX0sIm5hbWUiOiJhZG1pbiJ9

All requests must have a valid "credential" cookie set (this was not the case in a previous FW release - whoops) if the cookie is not present the modem will reply with "PLEASE LOGIN". The cookie value is just a base64 encoded json object:

{"valid":true,"technician":false,"credential":"YWRtaW46cGFzc3dvcmQ=","primaryOnly":false,"access":{"ALL":true},"name":"admin"}

And after base64 decoding the "credential" value we get:

{"valid":true,"technician":false,"credential":"admin:password","primaryOnly":false,"access":{"ALL":true},"name":"admin"}

Sweet, the device is sending your credentials on every authenticated request (without HTTPS), essentially they have created basic-auth 2.0 - As the kids say "YOLO". The part that stuck out to me is the "technician" value that is set to "false" - swapping it to "true" didn't do anything exciting, but after messing around a bit I found that the following worked wonderfully:

Cookie: credential=eyJjcmVkZW50aWFsIjoiZEdWamFHNXBZMmxoYmpvPSJ9

Which decodes to the following:

{"credential":"dGVjaG5pY2lhbjo="}

And finally:

{"credential":"technician:"}

Awesome, the username is "technician" and the password is empty. Trying to log into the interface using these credentials does not work :(

That is fairly odd. I can't think of a reasonable reason for a hidden account that is unable to log into the UI. So what exactly can you do with this account? Well, the web application is basically a html/js wrapper to some CGI that gets/sets SNMP values on the modem. It is worth noting that on previous FW revisions the CGI calls did NOT require any authentication and could be called without providing a valid "credential" cookie. That bug was killed a few years ago at HOPE 9.

Now we can resurrect the ability to set/get SNMP values by setting our "technician" account:

That's neat, but we would much rather be using the a fancy "web 2.0" UI that a normal user is accustomed to, instead of manually setting SNMP values like some sort of neckbearded unix admin. Taking a look at the password change functionality appeared to be a dead end as it requires the previous password to set a new one:

Surprisingly the application does check the value of the old password too! Back to digging around the following was observed in the "mib.js" file:

SysCfg.AdminPassword= new Scalar("AdminPassword","1.3.6.1.4.1.4115.1.20.1.1.5.1",4);

Appears that the OID "1.3.6.1.4.1.4115.1.20.1.1.5.1" holds the value of the "Admin" password! Using the "technician" account to get/walk this OID comes up with nothing:

HTTP/1.1 200 OK
Date: Tue, 23 Sep 2014 19:58:40 GMT
Server: lighttpd/1.4.26-devel-5842M
Content-Length: 55
{
"1.3.6.1.4.1.4115.1.20.1.1.5.1.0":"",
"1":"Finish"
}

What about setting a new value? Surely that will not work....

That response looks hopeful. We can now log in with the password "krad_password" for the "admin" user:

This functionality can be wrapped up in the following curl command:

curl -isk -X 'GET' -b 'credential=eyJjcmVkZW50aWFsIjoiZEdWamFHNXBZMmxoYmpvPSJ9' 'http://192.168.100.1:8080/snmpSet?oid=1.3.6.1.4.1.4115.1.20.1.1.5.1.0=krad_password;4;'

Of course if you change the password you wouldn't be very sneaky, a better approach would be re-configuring the modems DNS settings perhaps? It's also worth noting that the SNMP set/get is CSRF'able if you were to catch a user who had recently logged into their modem.

The real pain here is that Arris keeps their FW locked up tightly and only allows Cable operators to download revisions/fixes/updates, so you are at the mercy of your Cable operator, even if Arris decides that its worth the time and effort to patch this ~~bug~~ backdoor - you as the end user CANNOT update your device because the interface doesn't provide that functionality to you! Next level engineering.

Continue reading

Ragnar 2010

Monday, June 5, 2023

Emulating Shellcodes - Chapter 1

Read more

Nmap: Getting Started Guide

Related word

Sunday, June 4, 2023

Arris Cable Modem Backdoor - I'm A Technician, Trust Me.

Followers

Blog Archive

About Me