Sockets Practice: tpscan.c

tpscan.c is a thread portscanner--some more proof of concept/socket practice.

As expected, it speeds things up nicely:

dennis@ipa:~/projects/sockets/tpscan$ time ./tpscan x.x.x.x
25/smtp is open.
80/www is open.
995/pop3s is open.
0m28.40s real 0m0.00s user 0m0.00s system

dennis@ipa:~/projects/sockets/portscan$ time ./portscan x.x.x.x

Portscanning x.x.x.x (x.x.com)

25/smtp
80/www
995/pop3s

2m15.71s real 0m0.00s user 0m0.01s system

Update: rficrawl.c

I turned rficrawl.c from RFI Coverage in Emerging Threats into a RFI scanner, it looks like this now:

dennis@ipa:~/projects/rficrawl$ rficrawl 127.0.0.1 test

Vulnerable: /animals/animals.php?id=
Vulnerable: /OpenSiteAdmin/scripts/classes/DatabaseManager.php?path=
Vulnerable: /OpenSiteAdmin/scripts/classes/FieldManager.php?path=
Vulnerable: /OpenSiteAdmin/scripts/classes/Filter.php?path=
Vulnerable: /OpenSiteAdmin/scripts/classes/Filters/SingleFilter.php?path=
Vulnerable: /OpenSiteAdmin/scripts/classes/Form.php?path=
Vulnerable: /OpenSiteAdmin/scripts/classes/FormManager.php?path=
Vulnerable: /OpenSiteAdmin/scripts/classes/LoginManager.php?path=

Sockets Practice: pingscan.c

Some more proof of concept/socket practice, code is here.

dennis@ipa:~/projects/sockets/pingscan$ /home/dennis/projects/randips/randips 50 > ips
dennis@ipa:~/projects/sockets/pingscan$ sudo ./pingscan ips
Password:
71.45.159.69 is alive
126.4.37.254 is alive
pingscan: sendto: Network is unreachable
70.147.201.33 is alive

0x41414141.com: 1 - 3

@jjarmoc pointed me at 0x41414141.com and I spent a few hours with the first 3 challenges.

1: Base64 encoding, decoded it.

2: A PE executable:

bfab4d3c076ac4059f3c1e680c7a6933.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit

Started off with a strings of the binary which showed the following:

Email is return value of fn in form 0x12345678 zero padded to eight digits

Continued on with a objdump -D and pieced together what the ASM was doing. This lead me to the following C program:

#include <stdio.h>

int
main()
{
int val = 0xc0ffee;
int first = 0x401000;
int second = 0x8744ee;

printf("original: 0x%x\n", val);

val = val ^ first;

printf("first transform: 0x%x\n", val);

val = val ^ second;

printf("second transform: 0x%x\n", val);

return 0;
}

At first, I zero-padded the wrong side which lead me to a frustrating multi-hour "what am I missing" hunt.

3: I haven't played with a file format yet, so this challenge was very educational. They provided a PNG image named gzip.png--logo of GZIP.

I tracked down some documents on the PNG file format (1 and 2) and was delighted that it wasn't too difficult to follow. PNG files start with a header which is then followed by various variable length "chunks".

hexdump -Cing the image, I saw the string "email" inside a zTXT chunk--a compressed text string inside the image. zTXT uses zlib to compress the text string and this is where a day of frustrations began.

It turns out that there is a gzip file format, but also a zlib file format--At first, I thought they were the same and didn't know the other existed. At second, the zTXT chunk in this image almost makes sense using both formats.

3.c reads the PNG file, skips to the zTXT chunk and parses out the compressed text.

I took the easy way out and instead of learning and writing a zlib inflater, I used the zlib's API example zpipe.c to uncompress and print the txt.

Sockets Practice: ircspider.c

ircspider.c "spiders" IRC channels. Most IRC networks are smarter than me, so during testing I got banned, a lot! It does work on my small, simple test server:

dennis@ipa:~/projects/sockets/ircspider$ ./ircspider 127.0.0.1 6667
connected to 127.0.0.1 (127.0.0.1):6667

read timeout

#hi
dennis!~dennis@localhost
ircspider!~ircspider@localhost
#blah
dennis!~dennis@localhost
ircspider!~ircspider@localhost

I'm ok with it being a PoC and code practice.

Code is here.

RFI Coverage in Emerging Threats

ha.ckers posted a Large List of RFIs (1000+) awhile back which caught my eye.

Continuing on with my socket programming practice, I put together rficrawl.c that loops through each remote file include pathname, stuffs it into a GET and launches it at a webserver.

I made a PCAP of the traffic while rficrawl was running and fed it to Snort. Snort was using a default snort.conf configuration file along with the Mar 27th version of Emerging Threats ruleset.

The alert breakdown is over here.

The Mar 26th version of RSnake's RFI list contains 2203 unique RFIs. There were 1541 alerts generated, resulting in about 70% coverage. The majority of them, 1410 alerts (64%) were detected by the generic, catch-all "ET WEB_SERVER PHP Remote File Inclusion (monster list http)" signature.

This leaves 662 currently undetected vulnerabilities!

Network Forensics Puzzle Contest: Puzzle #4: The Curious Mr. X

Below are my answers for the Network Forensics Puzzle Contest: Puzzle #4: The Curious Mr. X. I didn't get to this till after the 3/18 deadline, so I wasn't able to officially submit it.

1. What was the IP address of Mr. X's scanner?

10.42.42.253

Look for source IPs sending SYNs:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x02 = 0x02' | cut -d ' ' -f 2 | awk -F '.' '{print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -nr
tcpdump: WARNING: snaplen raised from 116 to 65535
7416 10.42.42.253
27 10.42.42.50
12 10.42.42.25

Verify traffic looks like a scan:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x02 = 0x02' and src host 10.42.42.253 | more

2. For the FIRST port scan that Mr. X conducted, what type of port scan was it? (Note: the scan consisted of many thousands of packets.) Pick one:

TCP Connect - you can see the the full TCP 3-way handshake for open ports.

* TCP SYN - 2nd scan using static source port of 36020 - RST is sent as soon as a SYN/ACK is received for open ports
* TCP ACK - ACK scanning isn't really a portscan type, more of a "are you alive?"
* UDP - some UDP traffic, but not a scan
* TCP Connect - 1st scan using random source ports
* TCP XMAS - no XMAS packets, 'tcp[13] & 0xff = 0xff'
* TCP RST - no RST scanning, 'tcp[13] & 0x04 = 0x04'

3. What were the IP addresses of the targets Mr. X discovered?

sort/uniq out destination addresses:

$ tcpdump -lnr evidence04.pcap tcp and src host 10.42.42.253 | cut -d ' ' -f 4 | awk -F '.' '{print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -nr
3402 10.42.42.25
2041 10.42.42.50
2007 10.42.42.56

4. What was the MAC address of the Apple system he found?

00:16:cb:92:6e:dc

Determined via Wireshark's MAC Layer name resolution, confirmed via http://www.coffer.com/mac_find/?string=00%3A16%3Acb%3A92%3A6e%3Adc

5. What was the IP address of the Windows system he found?

10.42.42.50

Seeing NETBIOS broadcasts:

$ tcpdump -lnr evidence04.pcap udp
tcpdump: WARNING: snaplen raised from 116 to 65535
18:36:52.989943 10.42.42.50.137 > 10.255.255.255.137: udp 50

Seeing SYN/ACKS for normal windows ports of 135/139:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x12 = 0x12'
tcpdump: WARNING: snaplen raised from 116 to 65535
18:34:07.824240 10.42.42.50.139 > 10.42.42.253.56257: S 3796692784:3796692784(0) ack 3001813132 win 65535 (DF)
18:34:08.106871 10.42.42.50.135 > 10.42.42.253.42214: S 2938239898:2938239898(0) ack 2994045279 win 65535 (DF)

6. What TCP ports were open on the Windows system? (Please list the decimal numbers from lowest to highest.)

135
139

Look for SYN/ACKs sourcing from Windows system:

$ tcpdump -lnr evidence04.pcap 'tcp[13] & 0x12 = 0x12' and src host 10.42.42.50