Massimo Buso - massimobuso@yahoo.it
April 2003
Last modified: Milan, 26 April 2003
From www.irchelp.org:
IRC (Internet Relay Chat) provides a way of communicating in real time with people from all over the world. It consists of various separate networks (or "nets") of IRC servers, machines that allow users to connect to IRC.
[ ... ]
Generally, the user (such as you) runs a program (called a "client") to connect to a server on one of the IRC nets.
From RFC2810 (please consider RFC1459 as the original and basic RFC for IRC, while RFC2810/RFC2811/RFC2812/RFC2813 are actually updates; so RFC1459 is the reference for this document when IRC is involved):
The IRC Protocol is based on the client-server model, and is well suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions.
[...]
An IRC network is defined by a group of servers connected to each other. A single server forms the simplest IRC network. The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees. A sample small IRC network follows:
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
From www.irchelp.org:
The recommended order for a client to register follows (item 1. is not mandatory):
After registration, the JOIN message is used by a client to start listening a specific channel:
A botnet is a federation of IRC bot, logically group together thanks to IRC distributed architecture. An IRC bot is a program which connects to an IRC server, joins a specific channel and awaits for commands.
Illegitimate use of bots are IRC channel takeovers (IRC wars), remote access/backdoors, DDOS (Distributed Denial Of Service). Of course, as usual, the botnet concept is not malicious in principle, you can use for example for file sharing, but commonly this name addresses some sort of illegal use.
IANA registered ports for IRC are:
| ircu | 6665-6669/tcp | IRCU |
| ircu | 6665-6669/udp | IRCU |
In the real Internet world, the most common used port is 6667/tcp and udp is not used because of reliability. Anyway IRC servers tipically listen on several other ports by default including 6660-6669/tcp and 7000/tcp.
In this area the term "binary log file" means raw packet logging into a file. Tcpdump and ethereal can save the packets they capture into a binary log file by using "-w <filename>". Snort can produce binary log file in a tcpdump binary format by using a line in the snort configuration file like
output log_tcpdump: <filename>The tcpdump format (it would be better to call it libpcap format) is not the only one; for example others are snoop/novell LANalyzer/MS network monitor and many more.
Looking for TCP connections originated from the honeypot towards outside, we use tcpdump with a filtering expression to capture SYN/ACK packets incoming from outside servers (second phase of TCP/IP three-way handshaking):
tcpdump -n -nn -r sotm27 'tcp and dst host 172.16.134.191 and tcp[13]==18'By using command above, we build the pipeline:
tcpdump -n -nn -r sotm27 'tcp and dst host 172.16.134.191 and tcp[13]==18'|cut -d ' ' -f 2|sort|uniqand the output is (each line is in the form <A.B.C.D IP address>.<TCP PORT>):
128.242.214.10.80 194.192.187.194.80 194.68.68.12.80 194.68.68.39.80 198.49.161.200.80 205.188.137.80.80 206.151.167.254.80 207.172.16.150.80 207.172.16.156.80 207.46.196.108.80 207.46.196.120.80 207.68.171.238.80 207.68.171.245.80 207.68.176.250.80 207.68.183.190.80 207.68.184.62.80 209.196.44.172.6667 213.66.244.241.80 216.154.242.126.80 216.239.33.101.80 216.239.51.100.80 216.239.57.100.80 217.140.0.47.80 217.151.192.226.80 217.151.192.231.80 217.199.175.10.6667 63.241.174.144.6667 64.0.96.9.80 65.57.83.13.80
So IRC servers are:
First let's examine the traffic generated from/to the IRC server IP 209.196.44.172. We use the textual version of ethereal in this way:
tethereal -x -n -l -r sotm27 'ip.addr==209.196.44.172 and tcp.port==6667 and irc'After playing a little bit with the text/hex dump view of our traffic, we decide to write down a little piece of code to print the TCP payload of the interesting packets. The fact of the matter is that ethereal's IRC protocol support is not as strong as we need. No fear: we need only to print the raw TCP payload.
/* Compiled under RedHat 7.3 with:
gcc -o ircsniff -I/usr/include/pcap -Wall -lpcap ircsniff.c */
#include <stdio.h>
#include <string.h>
#include <pcap.h>
int main(int argc,char **argv)
{
u_char emptymsg[]="\x20\x0d\x0a\x00\x00\x00";
pcap_t *pcap_pkt;
char ebuf[PCAP_ERRBUF_SIZE];
struct pcap_pkthdr pcap_h;
unsigned char *pkt;
int i;
pcap_pkt = pcap_open_offline(argc!=2?"-":argv[1],ebuf);
while ( (pkt=(u_char *)pcap_next(pcap_pkt,&pcap_h)) != NULL )
if ( !(pcap_h.caplen==60 && !memcmp(pkt+54,emptymsg,6)) ) /* not empty msg */
for (i=54;i<pcap_h.caplen;i++) printf("%c",*(pkt+i));
pcap_close(pcap_pkt);
return 0;
}
This piece of code needs libpcap library
to be compiled. Minimal approach is used: no error management, no
clean parameters management, etc., just it should work for our current
job.
If it's called exactly with one argument then this must be the
filename of tcpdump/pcap binary file from which packets are read,
otherwise the standard input is used.
Each packet is considered only from each 55th byte, so as to print the
TCP payload only.
Using our 'ircsniff' program:
tethereal -l -w- -r sotm27 'ip.addr==209.196.44.172 and tcp.port==6667 and irc'|./ircsniff > irc.209.196.44.172
the file "irc.209.196.44.172" we get contains (partial):
NOTICE AUTH :*** Looking up your hostname... NOTICE AUTH :*** Checking Ident NOTICE AUTH :*** No Ident response NOTICE AUTH :*** Found your hostname NICK rgdiuggac USER rgdiuggac localhost localhost :rgdiuggac :irc5.aol.com 001 rgdiuggac :Welcome to the Internet Relay Network rgdiuggac :irc5.aol.com 002 rgdiuggac :Your host is irc5.aol.com[irc5.aol.com/6667], running version 2.8/hybrid-6.3.1 NOTICE rgdiuggac :*** Your host is irc5.aol.com[irc5.aol.com/6667], running version 2.8/hybrid-6.3.1 :irc5.aol.com 003 rgdiuggac :This server was created Sun Jan 19 2003 at 19:04:03 PST :irc5.aol.com 004 rgdiuggac irc5.aol.com 2.8/hybrid-6.3.1 oOiwszcrkfydnxb biklmnopstve :irc5.aol.com 005 rgdiuggac WALLCHOPS PREFIX=(ov)@+ CHANTYPES=#& MAXCHANNELS=20 MAXBANS=25 NICKLEN=9 TOPICLEN=120 KICKLEN=90 NETWORK=XNet CHANMODES=be,k,l,imnpst EXCEPTS KNOCK MODES=4 :are supported by this server :irc5.aol.com 251 rgdiuggac :There are 0 users and 4752 invisible on 4 servers :irc5.aol.com 252 rgdiuggac 1 :IRC Operators online :irc5.aol.com 254 rgdiuggac 4 :channels formed :irc5.aol.com 255 rgdiuggac :I have 346 clients and 1 servers :irc5.aol.com 265 rgdiuggac :Current local users: 346 Max: 348 :irc5.aol.com 266 rgdiuggac :Current global users: 4752 Max: 4765 :irc5.aol.com 250 rgdiuggac :Highest connection count: 349 (348 clients) (378 since server was (re)started) :irc5.aol.com 375 rgdiuggac :- irc5.aol.com Message of the Day - :irc5.aol.com 372 rgdiuggac :- - WELCOME TO AMERICA ONLINE'S - IRC SERVER :irc5.aol.com 372 rgdiuggac :- :irc5.aol.com 372 rgdiuggac :- - !!! WARNING WARNING WARNING WARNING !!! :irc5.aol.com 372 rgdiuggac :- - !!! THIS SERVER SCANS FOR OPEN PROXIES !!! :irc5.aol.com 372 rgdiuggac :- - !!! PORTS: 8080,3128,80,1080,23 !!! :irc5.aol.com 372 rgdiuggac :- - So if this is a legal problem in your :irc5.aol.com 372 rgdiuggac :- - country please disconnect NOW! :irc5.aol.com 372 rgdiuggac :- - We do this to make your IRC experience :irc5.aol.com 372 rgdiuggac :- - more enjoyable. :irc5.aol.com 376 rgdiuggac :End of /MOTD command. :rgdiuggac MODE rgdiuggac :+i MODE rgdiuggac -x MODE rgdiuggac +i JOIN #xàéüîéðìx :sex0r [...]
Interesting information can be uncovered such as:
Now we are close to the answer: "how many bots populate the botnet".
It's worth to remember that when a JOIN command - used to join an IRC channel - is accepted successfully by an IRC server then it sends back the list of users who are on the channel. If we assume an exact match between users and bot compromised site, in this way we can calculate the number of hosts on the botnet.
The command response code to use is 353 - RPL_NAMREPLY, so we can filter messages like:
grep ':irc5.aol.com 353 rgdiuggac #xàéüîéðìx' irc.209.196.44.172And finally we build a pipeline with the grep command above and a perl command to clean out just the "grepped" part above:
perl -p -e 's|:irc5.aol.com 353 rgdiuggac #xàéüîéðìx :| |g'
So the final command is:
grep ':irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx' irc.209.196.44.172 | perl -p -e 's|:irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx :| |g' > irc.209.196.44.172.users
So now the file "irc.209.196.44.172.users" contains the list of users space-separated. Rapidly we do the grand total:
cat irc.209.196.44.172.users | tr -s ' \n\r' '\n' |sort|uniq|less|wc -l
and the result is 3458.
3457 * 56 kbps, which approx equals to 189 Gbps
Our analysis is done using a different approach for UDP,TCP and ICMP. The UDP traffic from outside can be processed by
tcpdump -n -nn -r sotm27 'udp and dst host 172.16.134.191'|cut -d ' ' -f 2|cut -d '.' -f 1-4|sort|uniqGiving as a result 113 hosts from 100 class B subnets.
TCP traffic from outside can be found running tcpdump and use a capture filter to get packets originating from the honeypot with SYN / ACK flags both set (second phase of the TCP three-way handshaking of a external-originated TCP session):
tcpdump -n -nn -r sotm27 'tcp and src host 172.16.134.191 and tcp[13]==18'|cut -d " " -f 4|cut -d "." -f 1-4|sort|uniqGiving as a result 69 hosts from 67 class B subnets.
Using again tcpdump we discover that no other protocol except UDP and TCP are in our binary log file:
tcpdump -n -nn -r sotm27 '!(udp or tcp)'
Combing the two results obtained for TCP and UDP we have the following list
of 128 attacking hosts:
12.252.61.161
12.253.142.87
12.83.147.97
129.116.182.239
141.149.155.249
144.134.109.25
148.235.82.146
162.33.189.252
164.125.76.48
168.226.98.61
168.243.103.205
169.254.205.177
172.168.0.154
192.130.71.66
195.36.247.77
195.67.251.197
200.135.228.10
200.50.124.2
200.60.202.74
200.66.98.107
200.78.103.67
202.63.162.34
203.106.55.12
203.115.96.146
205.180.159.35
206.149.148.192
207.6.77.235
208.186.61.2
209.45.125.110
209.45.125.69
210.12.211.121
210.203.189.77
210.214.49.227
210.22.204.101
210.58.0.25
211.149.57.197
212.110.30.110
212.122.20.74
212.162.165.18
213.107.105.72
213.116.166.126
213.122.77.74
213.170.56.83
213.217.55.243
213.23.49.158
213.44.104.92
213.7.60.57
213.84.75.42
216.170.214.226
216.192.145.21
216.228.8.158
216.229.73.11
217.1.35.169
217.222.201.82
217.227.245.101
217.227.98.82
217.35.65.9
218.163.9.89
218.237.70.119
218.244.66.32
218.25.147.83
218.4.48.74
218.4.65.115
218.4.87.137
218.4.99.237
218.87.178.167
218.92.13.142
219.118.31.42
219.145.211.132
219.145.211.3
219.65.37.37
219.94.46.57
24.107.117.237
24.161.196.103
24.167.221.106
24.197.194.106
24.74.199.104
4.33.244.44
4.64.221.42
61.111.101.78
61.11.11.54
61.132.88.50
61.132.88.90
61.134.45.19
61.140.149.137
61.14.66.92
61.150.120.72
61.150.72.7
61.155.126.150
61.177.154.228
61.177.56.98
61.177.62.66
61.185.212.166
61.185.215.42
61.185.242.190
61.185.29.9
61.203.104.148
61.55.71.169
61.8.1.64
62.127.38.198
62.150.170.134
62.150.170.232
62.194.4.114
62.201.96.159
62.251.129.118
64.17.250.240
64.254.203.68
66.139.10.15
66.190.67.122
66.233.4.225
66.73.160.240
66.81.131.17
66.8.163.125
66.92.135.108
67.201.75.38
67.81.161.166
68.115.33.110
68.152.53.138
68.154.11.82
68.169.174.108
68.37.54.69
68.45.123.130
68.84.210.227
80.181.116.202
81.114.77.37
81.202.125.5
81.50.177.167
81.57.217.208
Snort will be used to uncover potential attacks to the honeypot. We use the standard stable ruleset and the following configuration file (suppose it's located in "/etc/snort/snort.conf"):
var HOME_NET 172.16.134.191/32 var EXTERNAL_NET !$HOME_NET var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var HTTP_PORTS 80 var SHELLCODE_PORTS any var ORACLE_PORTS 1521 var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24] var RULE_PATH /etc/snort ################################################### preprocessor frag2 preprocessor stream4: detect_scans preprocessor stream4_reassemble preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace preprocessor rpc_decode: 111 32771 preprocessor bo: -nobrute preprocessor telnet_decode preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations 32000 ################################################### output alert_full: snort_full output alert_fast: snort_fast ################################################### include classification.config include reference.config ################################################### include $RULE_PATH/bad-traffic.rules [...] include $RULE_PATH/local.ruleswe omitted all the "include" lines for each snort rule file: all available rule file is included.
snort -c /etc/snort/snort.conf -r sotm27We summarize snort processing with the following part of the standard output during snort execution:
===============================================================================
Snort processed 54536 packets.
Breakdown by protocol: Action Stats:
TCP: 54350 (99.659%) ALERTS: 67
UDP: 186 (0.341%) LOGGED: 67
ICMP: 0 (0.000%) PASSED: 0
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
===============================================================================
A first inspection to the alert (fast log "snort_fast") suggests
to eliminate a FP (False Positive), the one identified with SID
(Snort ID) 615
- SCAN SOCKS Proxy attempt.
Then we can trace the IP addresses of the offending hosts by using:
grep -v ':615:' snort_fast|perl -p -e 's|^.*\s(\S+):\S+ -> 172.16.134.191.*|$1|g' | sort | uniq
and so we have back:
12.252.61.161 12.253.142.87 12.83.147.97 168.243.103.205 200.135.228.10 200.50.124.2 205.180.159.35 206.149.148.192 210.22.204.101 212.122.20.74 212.162.165.18 213.122.77.74 213.170.56.83 216.192.145.21 216.229.73.11 217.35.65.9 218.244.66.32 218.4.48.74 218.4.65.115 218.4.87.137 218.4.99.237 218.92.13.142 219.145.211.132 219.145.211.3 24.167.221.106 24.74.199.104 4.33.244.44 61.132.88.50 61.132.88.90 61.134.45.19 61.150.120.72 61.150.72.7 61.177.56.98 61.177.62.66 61.185.212.166 61.185.215.42 61.185.242.190 61.185.29.9 61.203.104.148 61.8.1.64 66.233.4.225 66.81.131.17 67.201.75.38 67.81.161.166 68.37.54.69 68.45.123.130 68.84.210.227 81.57.217.208
The total number of the above hosts is 48. Two possible attack types are indentified by snort:
The first type rappresents the this year most famous worm based on a known vulnerability on Windows 2000 and SQL 2000. Only W2k sp3 or bug fixed systems are immune. Attacks of this type use 1434/udp port of the honeypot. The confirmation of attacks success will be done in the next section.
The second type rappresents attempts to inject a shellcode into an ip session (look at snort rule of sid 1390) which in our case is an HTTP session. The possible attack could have exploit a race condition in the Microsoft web sever (buffer overflow) and later a shellcode is tryed. As a matter of fact Microsoft web servers unpatched (our case) suffer a lot of vulnerabilities (i do not want to start a religion war here): possible candidate!
At a very end we have to notice that because the honeypot administrator password is very trivial (blank password) then sessions not considered by snort (e.g. NBT - NetBios over TCP/IP) are dangerous. We will consider this in the next section.
We start collecting protocol statistics about the binary log file:
tethereal -n -z io,phs -R '!frame' -r sotm27
===================================================================
Protocol Hierarchy Statistics
Filter: frame
frame frames:54536 bytes:17247037
eth frames:54536 bytes:17247037
ip frames:54536 bytes:17247037
udp frames:186 bytes:49962
nbns frames:129 bytes:26852
data frames:2 bytes:120
dcerpc frames:55 bytes:22990
tcp frames:54350 bytes:17197075
nbss frames:3769 bytes:2219209
smb frames:2506 bytes:511805
dcerpc frames:20 bytes:3800
pipe frames:1276 bytes:258208
dcerpc frames:1259 bytes:243638
samr frames:523 bytes:109330
malformed frames:1 bytes:1138
srvsvc frames:4 bytes:1416
data frames:17 bytes:14570
data frames:9 bytes:12466
data frames:69 bytes:104466
nbss frames:13 bytes:19682
data frames:1 bytes:1514
nbss frames:1 bytes:1514
nbss frames:1 bytes:1514
nbss frames:1 bytes:1514
nbss frames:1 bytes:1514
nbss frames:1 bytes:1514
nbss frames:1 bytes:1514
nbss frames:1 bytes:1514
http frames:12028 bytes:11481571
data frames:918 bytes:185975
ssl frames:1 bytes:105
irc frames:9809 bytes:1632635
===================================================================
As already noted, no ICMP packets flows from/to the honeypot.
This means that any UDP session from outside have found honeypot UDP
port open because no "ICMP Port Unreachable" packet is sent back.
tcpdump -n -nn -r sotm27 'udp and dst host 172.16.134.191'|cut -d ">" -f 2|cut -d "." -f 5|cut -d ":" -f 1|sort|uniqand the result is: 137/udp, 1434/udp, 28431/udp.
Similarly to what done for UDP, we would like to collect TCP sessions from outside to the honeypot. By using tcpdump we are looking for TCP packets with flags SYN and ACK active and originated from the honeypot (same idea already used before):
tcpdump -n -nn -r sotm27 'tcp and src host 172.16.134.191 and tcp[13]==18' | cut -d "." -f 6 | cut -d " " -f 1 | sort | uniqand the result is: 25/tcp, 80/tcp, 135/tcp, 139/tcp, 445/tcp, 4899/tcp.
So a summary of open ports in the whole binary file are:
| service | ports |
| smtp | 25/tcp |
| nbt | 135/tcp ; 139/tcp ; 445/tcp ; 137/udp |
| http | 80/tcp |
| radmin | 4899/tcp |
| sql dcerpc | 1434/udp |
So the suspect that the SQL worm attack were successful is very high. The final word is given by a statistical analysis of the packets over the time:
tethereal -x -n -tad -r sotm27 -R '!frame' -z io,stat,1800The output of this command shows that there are holes in the bandwidth, sometimes and for hours, just when the 1434/udp packet arrived. This is exactly the effect of the worm; SQL work attack: success!
Then, we have to confirm the shellcode injection into the MS web server. From the snort log file we have that the host originating the attack has IP 210.22.204.101; then we use tethereal to look to the session it generates:
tethereal -l -x -n -r /root/sotm27 -R 'ip.addr==210.22.204.101 and http'
We can argue that (ordering by time from the oldest to the newest event):
Looking through packets from 1841 to 1887 we can suppose that the effect of the malicious code should be to open a socket on the honeypot at port 99/tcp. The attacker is looking for that but that's not happen: attack unsuccessfull!
We are missing two issues:
The first issue, radmin, can be investigated by:
tcpdump -n -nn -r sotm27 'dst host 172.16.134.191 and tcp dst port 4899'|cut -d ' ' -f 2|cut -d '.' -f 1-4|sort|uniqWhat results from here is that only the host of IP 210.22.204.101 has session to this tcp port.
However a close analysis:
tethereal -n -l -r sotm27 -R 'ip.addr==210.22.204.101 and tcp.port==4899'reveals that at the beginning of the packet captured this port was not opened and this up to packet 1355-1356, and only at packet 2070-2071-2072 the tcp three-way handshaking successfully established a socket.
So the honeypot was violated by host IP 210.22.204.101, and this happens in the range of packets from 1357 to 2069. This happens exploiting NBT sessions, last chance. In fact the attacker by exploiting the weakness of the Administrator password, copied the radmin server into the honeypot and the put it into execution.
Firstable, i understand for what's better tcpdump and for what ethereal, that is the first is better for up-to ISO/OSI level 3 analysis, while ethereal for 4 to 7.
Second, I have studied botnet a little and i have to say that ideas behind are very fashinated.
Finally, to find common attacks is best to think simple.
Blocking NBT traffic at border routers.
Enforcing password policy (host basis and eventually at the Domain Controller)
Upgrading operating systems and installed software according to vendors bug/security fixing
Minor issues: