11 million Euro loss in VoIP fraud .. and my VoIP logs

And the attackers made over 1 million in profits.
This just emerged from a raid (and hearing apparently) in Romania and other countries. The two main persons being fingered are Catalin Zlate and Cristian Ciuvat. It seems that they were scanning for PBX servers with phone extensions that have weak passwords. Then they abused these accounts to make phone calls for "free", except that free has the price of 11 million EUR for the victims!


Apparently, originally they used these accounts for their own personal phone calls. However they got greedy and between October 2009 to February 2010, they made 23500 calls / 315000 minutes to premium numbers. Then (from what I understood), they got even more greedy and used Shadow Communication Company Ltd. This site is still available right now - whois shows the name of Cristian Ciuvat (thanks for someone on pointing this out). This site contains lists of prices for premium numbers, linking to another site Ivrstats.net. Using this they recruited other people to make  1,541,187 fraudulent calls or 11,094,167 minutes of talk time.

So right now there are 42 people in court with raids happening in London, Neamt, Brasov, Cluj and Maramures. This is all according to various sites in Romanian, translated automatically using Google translate.

One of the original articles on this can be found here.

Here's a screenshots from their site (in case it goes down):

Some thoughts

On our honeypots we have seen Zoiper messages from Romania and this could possibly be very related. I decided to check out my logs and sure enough found the sort of behavior described in the articles describing the illegal activities. The following IP addresses had Zoiper in their user-agent header when connecting to my simple VoIP honeypot:

• 89.42.156.102 - Romania
• 74.115.0.25 - US (San Jose)
• 68.194.64.146 - US - Brooklyn
• 74.115.0.24 - US (San Jose)
• 89.42.194.224 - Romania
• 79.117.27.97 - Romania
• 89.42.187.151 - Romania
• 64.9.175.89 - US (Austin)
• 95.76.211.188 - Romania 
• 109.99.35.113 - Romania
• 85.186.123.121 - Romania
• 95.22.116.11 - Spain

Here's an example SIP message that was sent from the 1st IP:

INVITE sip:[email protected];transport=UDP SIP/2.0
Via: SIP/2.0/UDP 89.42.156.102:5060;branch=z9hG4bK-d8754z-07cf25937cf90e2a-1---d8754z-
Max-Forwards: 70
Contact: <sip:[email protected]:5060;transport=udp>
To: <sip:[email protected];transport=udp>
From: "Unknown"<sip:[email protected];transport=udp>;tag=ce2e1a65
Call-ID: NmNhZTE5MGMwM2IyMDg3OTM5YWY1YTQ5OWYzZWYzNDE.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rev.6751
Content-Length: 329

v=0
o=Zoiper_user 0 0 IN IP4 89.42.156.102
s=Zoiper_session
c=IN IP4 89.42.156.102
t=0 0
m=audio 8000 RTP/AVP 3 0 8 110 98 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 speex/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

The phone number that the Zoiper user tried calling was "0040767091012". Romanian numbers start with +40, so one can assume that this is some phone that the attacker was using to see if the call is terminated or not. This number is not a premium number. I have looked at other logs and some were probably premium numbers.


Note regarding Catalin Slate: is this the same person who was in 2005 caught with credit card fraud (reference here)?

I would be interested in hearing more about this case as it sheds some light on what's actually happening in the background.

Update:
Thanks goes to Stefan Tanase for pointing out the original article in Romanian. The also added the following:

As far as I understand, they were using other premium numbers affiliate networks at first and then, when they realized the potential, they set up a company in the UK - Shadow Communications Inc. - through which they were able to sign a  contract on their own with a premium rate number provider and offer their own affiliates service, basically taking their "business" to a whole new level.

Conclusion

All in all, it looks like these attackers were not so technically advanced after all, yet managed to hit the million euro mark. I wonder what more skilled and stealthy criminals are able to do!

Distributed SIP scanning during Halloween weekend

Over last weekend there were a number of reports of VoIP (especially Asterisk) servers that were "under heavy attack". I have looked at some packet traces and noticed how the SIP messages look very similar to the ones generated by SIPVicious especially svwar.py. In fact, I think this is a modified version of SIPVicious that is being distributed on a botnet.

Take a look at the following message generated by these new scans:

REGISTER sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=88y8n2p4U3;rport
Content-Length: 0
From: "311"
Accept: application/sdp
User-Agent: Asterisk PBX
To: "311"
Contact: sip:[email protected]
CSeq: 1 REGISTER
Call-ID: 1728224566
Max-Forwards: 70

The following message would be generated by svwar.py for the same extension number (username):

REGISTER sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP yy.yy.yy.yy:5060;branch=z9hG4bK-4059165492;rport
Content-Length: 0
From: "311"; tag=3331310133333331373232343735
Accept: application/sdp
User-Agent: friendly-scanner
To: "311"
Contact: sip:[email protected]
CSeq: 1 REGISTER
Call-ID: 3259315903
Max-Forwards: 70

Notice how the order of the headers is exactly the same and so on. However there are some obvious differences:

• the user agent is now "Asterisk PBX" instead of "friendly-scanner"
• the branch is totally random instead of starting with "z9hG4bK" as is standard in SIP/2.0

Additionally the To tag is apparently generated differently. In SIPVicious the code to generate the "To tag" is the following:

def createTag(data):
    from binascii import b2a_hex
    from random import getrandbits
    rnd = getrandbits(32)
    return b2a_hex(str(data)+'\x01'+str(rnd))

The data would typically contain the extension which is then concatenated to a random number and encoded. This would later be decoded when the target responds, which helps make the scanner stateless.

In the case of this new scanner, we cannot decode the extension number in the same way.
So clearly, these guys want to bypass intrusion detection/prevention systems such as fail2ban, snort-inline etc by doing the following:

• distributing the scans across different IP addresses
• changing the obvious SIPVicious signatures to something more common, such as "Asterisk PBX" since no one in their right mind would block that

Some more interesting things:

• the source ports for these scans appear to be high ports, indicating that the same host in the botnet is scanning many other hosts at the same time (if the port allocation code is the same as the original)
• each host scans for consecutive numbers for the extension
  

If I am correct, then the goals are obvious - enumeration of extensions and then password cracking to be able to make fraudulent phone calls.

Unfortunately, this scanning has been causing bandwidth problems for VoIP providers out there who need to expose their SIP servers on the 'net.

So what do we do about this?
It appears that botnets are now being used for distributed scanning. Therefore it might make sense to look at what others have done before when it comes to botnet borne attacks:

• Improved their IPS systems to protect against attack (I have some ideas on how to do this)
• Hid behind VPNs or just shifted to another protocol that is not yet being attacked as much (think SIP over TLS or IAX2 etc)
• In the case of DDoS attacks, financial companies and online-gambling companies just use expensive 3rd parties that should absorb all the network traffic
• Usage of blacklists for IP addresses that are known to be part of a botnet (check out the VoIP Blacklist Project)

Unfortunately none of these are real solutions and are rather simply mitigation techniques. In many cases, VoIP providers cannot make use of VPNs or other similar solutions.

The mailing lists had some interesting conversations about this:

• asterisk list
• voipsa
• voipops

And Stuart Sheldon and others blogged about this too.

Thanks to anyone (you know who you are :)) who sent me info already. If anyone has any more insight into this, mitigation, solutions, code or packet traces, please email me.

AstriCon roundup and vendors adding security features

So I've finally been to AstriCon and I noticed a great increased interest amongst the attendees with regards to security, fraud and "hacking". The slides for my presentation titled "Just how vulnerable is your phone system" can be downloaded from this location.

So what are the changes and additions from the software developer's side?

1. Asterisk 1.8 has been released touting TLS support for SIP and SRTP support too, plus a framework to make auditing easier
2. 3CX have released a major security update with features to make it easier to set proper passwords
3. I just received an email from Brekeke highlighting their security page on their wiki which was originally published on March 11, 2009

What accounts for these changes? From talking with the people at AstriCon I started understanding why the increased interest in security: organizations are really getting hurt with call fraud and this seems to be on the increase.

Plus the advise I heard again and again from developers for FreePBX-based systems was:
"Do not put your FreePBX / configuration available on the Internet, it is not designed for that!"

But if you do a simple scan for Asterisk boxes (using svmap.py for example), you'll notice many systems out there that do not heed this advice. Apart from that, as Blake Cornell showed in his presentation, there are many attacks on FreePBX-based systems that can be abused without direct access to the HTTP configuration interface.

BruCON Training: Module 4, Attacking Unified Communications

The final module in the upcoming pentesting VoIP crashcourse is the most exciting one. In this section we look at VoIP systems as a whole. Unified communications is one of those words that have been hyped up to include everything, from chat to video phone calls and SMS. What we will look at in this section is how to go about breaking into the following during a penetration test:

1. Web application security flaws in Asterisk-based PBX servers
2. Attacking various services open in PBX servers, such as TFTP
3. How once you're on a PBX network, you can sometimes simply use your phone to spy on other phone calls
4. How to make use of hardware taps 
5. Hardware phone features that can be abused
6. Abuse of various exposed features in Cisco call manager accessible on the HTTP server

This module will help familiarize the attendees with the target servers and system. Who knows, it may even give a kick-start to find some new 0-days in one of these Unified Communications solutions ;-)

BruCON Training: Module 3, Attacking the media

This is part of the BruCON VoIP security crash course training intro. For more information about the course and to secure a place, check out the BruCON website.

We trust our phones with our sensitive data more than most other forms of communications. We may not trust sending our credit card number by email to the hotel. In the end we give it to them on the phone anyway, and it may not matter if the phone is a mobile phone or a VoIP phone.

Since VoIP phones look very much like traditional phones, most people are impressed to learn (the hard way) that they can be intercepted just like other devices and computers on the network. This is one of the topics covered in the third module. We will use readily available tools that will allow you to sniff phone calls over the network very easily. Tools include Wireshark, UCSniff and Cain and Abel.

These tools will handle RTP and codecs differently so we will see which ones are best for the job. 

As a penetration tester, you will encounter setups that try to prevent ARP cache poisoning and other attacks that allow for media interception. During this training we will look at each of these solutions and look how they can be often defeated.

When it comes to media, interception is not the only concern. There are tools that perform RTP injection, i.e. modify the RTP stream on the fly, which can make an interesting demonstration. Then there's convert channels, where an insider embeds his/her data inside the RTP stream.

BruCON Training: Module 2, Attacking signaling protocols

This is part of the BruCON VoIP security crash course training intro. For more information about the course and to secure a place, check out the BruCON website.

Most VoIP systems perform signaling using a protocol separate than the media transfer protocol. Signaling protocols allow VoIP systems to register, authenticate, and initiate phone calls and tends to carry a lot of intelligence with it. In this part of the training, Joffrey and myself will talk you through the following different signaling protocols and attacks that apply to these protocols:

• SIP - an open standard
• IAX2 - used by Asterisk PBX and compatible phones
• SCCP (Skinny) - used by Cisco systems
• MGCP - the media gateway control protocol, typically used between gateways and IVR systems
• H.323 - found in gateways and older systems

The fun part? The exercises! We plan to use a hands-on approach rather than simply describe the protocols and attacks.

These are some of the practicals we have in store:

1. Sniffing SIP, in order to understand how it all works and also spy on the metadata or signal
2. Scanning SIP, to see how we can easily identify SIP devices very quickly using SIPVicious and other tools
3. SIP extension enumeration and online password cracking, to understand better how VoIP attackers are in fact making phone calls for free at the expense of their victims
4. Avoiding toll / fraudulent calls, featuring the main ways that attackers are abusing SIP PBX servers out there
5. INVITE floods, which is still an effective attack and bring down various SIP enabled devices
6. Fuzzing SIP, existent tools and their usage
7. Using John the ripper to crack SIP passwords, which also includes capturing the SIP authentication messages and patching John the ripper to crack the hash
8. Online and offline password cracking in IAX2, the tools and their usage
9. Scanning IAX2 which allows us to find Asterisk servers
10. MiTM attacks using SCCP proxy, which is a fun way of playing with the phones and can allow us to turn Cisco phones into remote spy bugs
11. Capture FAC (Forced Authorization Codes) code, which is a restriction usually used in Cisco VoIP environments to allow / block international calls
12. Call fraud with MGCP, since MGCP has little or no security
13. DoS on MGCP, or how to cause your VoIP Gateway to go down
14. RTP redirection, which can allow all sorts of fun (and sometimes profit)
15. Callmanager hijack (details later ;-))

With all these exercises we expect all the attendees to get really busy and gain useful experience with the signaling protocols.

BruCON Training: Module 1, An Introduction to ...

An Introduction to VoIP technology, security threats and solutions, module 1. This module allow us to set the stage for the rest of the training. We will introduce the players - Asterisk, Cisco unified communications and other products. We will introduce the protocols briefly - SIP, SCCP (Skinny), IAX2, H.323 and MGCP. We will also look at how VLANs and other solutions are used to provide security (and where they fail).

We will then focus on security in terms of confidentiality, integrity and availability without going into too much detail (just to wet your appetite ;-)).

Confidentiality
When it comes to VoIP, confidentiality ensures that the communications - phone calls and any signaling data - cannot be spied upon. Confidentiality is a major weakness in the case of many VoIP systems. One obvious security issue is when internal attackers spy on phone calls by sniffing the RTP stream. However this is not the only attack vector. We will give examples of tricks that can be pulled off by external attackers that allow them to compromise confidentiality remotely, without (layer 2) access to the network.

Integrity
Caller ID spoofing, toll fraud and modification of signal or media affects the integrity of the VoIP system. In this section we will look at these and various other security flaws that do not necessarily allow attackers to gain illegal access to confidential information. These security flaws however, may allow attackers to cause organizations to loose large sums of money.

Availability
This tends to be the security flaw that really affects organizations directly. When the phone system is down, many organizations suffer. This is especially true for call centers, which base their revenues on phone calls. With VoIP, attackers can abuse flaws at various levels to cause denial of service. In this section we will introduce some attacks that are specific to VoIP and others that affect systems in general.

BruCON Training: A crashcourse in pentesting VOIP networks (update)

We just updated the outline of the 2 day crashcourse on the main BruCON training website! In the coming days I'll be highlighting the modules to explain what each consist of. Training registration is from this page, and for any questions get in contact with Sn0rky or myself.

This is what it looks like:

Module 1: Introduction to VoIP technology, security threats and solutions

1. Introduce the protocols
2. Mitigation technologies
3. How confidentiality / integrity / availability applies to VoIP
   1. fraud
   2. spying on phone calls
   3. modification of phone data
   4. denial of service

Module 2: Attacking signaling protocols

1. SIP
   1. introduction to the protocol
   2. scanning for SIP
   3. attacking SIP
   4. exercises include:
      1. sniffing SIP
      2. scanning SIP
      3. SIP extension enumeration and online password cracking
      4. Avoiding toll / fraudulent calls
      5. INVITE floods
      6. Fuzzing SIP
      7. Using John the ripper to crack SIP passwords
2. IAX2
   1. introduction to the protocol
   2. scanning for IAX2
   3. attacks on IAX2
   4. exercises include:
      1. online and offline password cracking
      2. scanning IAX2
3. SCCP
   1. introduction to the protocol
   2. scanning for Cisco PBX / SCCP
   3. Attacks on SCCP
   4. exercises include:
      1. MiTM attacks using SCCP proxy
      2. Capture FAC code
      3. Callmanager hijack
4. MGCP
   1. introduction to the protocol
   2. scanning for MGCP
   3. attacks on MGCP
   4. exercises include:
      1. Call fraud
      2. DoS on MGCP
      3. RTP redirection
5. H.323
   1. introduction to the protocol
      1. H.225
      2. H.245
   2. scanning for H323
   3. attacks on H323
      1. Frames Injection
      2. DoS on H323

Module 3: Attacking the media

1. Wiretapping
   1. Understanding the basics, ARP poisoning and other MiTM attacks
   2. exercises include using various tools, including Wireshark, for tapping VoIP calls
2. RTP stream modification
   1. how it works
3. Convert channels
   1. how it works, concepts and reality

Module 4: Attacking Unified Communications

1. Trixbox / Elastix vulnerabilities
   1. default passwords are common
   2. TFTP abuse
   3. Spying on phone calls using your phone
   4. Privilege escalation
   5. Exercises include:
      1. spying on phone calls
      2. abusing Trixbox features
      3. exploitation of weak permissions
2. Asterisk
   1. Dialplan injection
   2. Setting up a backdoor
3. Hardware information gathering
   1. physical bridging
   2. passive ethernet tap
   3. bypassing lock / restrictions on the phone
   4. exercises include:
      1. hardware for tapping
      2. hardware phone abuse
4. Cisco Unified Communications vulnerabilities
   1. Extension mobility abuse
   2. Webdialer
   3. CCMuser SQL injection
   4. Billing system
   5. Jailbreaking CUCM
   6. Exercises include:
   7. Jailbreaking CUCM
   8. Webdialer abuse

New beta of VIPER VAST released 2.76

And that includes all the latest goodness, including SIPVicious. This is a great tool for those needing an up to date VoIP hackin.. er penetration testing distro :-) Download it from here.

How to crash SIPVicious - introducing svcrash.py

A new tool has been added to SIPVicious - svcrash.py. As the name implies, it crashes something - svwar.py and svcrack.py. This tool is meant to be used by system administrators and organizations that are receiving unauthorized scans on their exposed IP PBX.

Quick links: Download the latest version :: Watch a short demo of svcrash.py

Since this is a little different from the usual, I'll provide a bit of background first.

Background

If you had been following the Asterisk or VoIP provider blogs and forums, you might have noticed people complaining about bandwidth saturation due to SIP scans. Some people had been using Amazon EC2 based servers to look for SIP servers such as Asterisk, which have weak passwords. As a result of these scans, organizations were getting a considerable amount of bandwidth used - leading to denial of service (DoS). Why did this happen?

• The attackers were using huge lists of extensions / passwords in their scans, (apparently) sometimes using the --force option in svwar.py
• Even if blacklisted, old versions of svwar.py and svcrack.py keep sending messages because they are stateless
• Originally, Amazon's abuse team did not respond to these attacks in a timely fashion
• The victim providers had less bandwidth than Amazon's cloud

This meant that just like other denial of service attacks, dropping the packets at the victim host (eg. using iptables) is not enough.

So what's new?

1 - Updated SIPVicious to care more...

A few weeks ago I released a new version of SIPVicious (v0.2.5) which has a timeout for svwar.py and svcrack.py. If either of these tools receives no response then it stops scanning. The reason why they receive no response could be that an intrusion prevention system blocked the scanning IP, thus making it useless to keep on scanning anyway.

I urge everyone to update to the latest version (v0.2.6).

2. Create a small basic tool that breaks the attack:
A more aggressive approach is to make use of svcrash.py. What this tool does is abuse an unhandled exception when decoding the information from the "To" tag. This causes both svwar and svcrack to crash, thus stopping an attack. This tool is included in v0.2.6, which also includes a fix for this bug.

How to run svcrash.py

Mode 1: python svcrash.py -d attackerip -p attackerport
This would send one message which causes the attack to stop. You would need to find out the IP address and the attacker port from your PBX log files or by taking a look at Wireshark or tcpdump during the attack.

Mode 2: sudo python svcrash.py --auto
This would make use of scapy (i.e. you need to have scapy v2 installed) to monitor the traffic and respond automatically every 2 seconds. This automates the whole thing so that one can leave it running to block the next attack.




Mode 3: sudo python svcrash.py --astlog=/var/log/asterisk/full
Makes use of the Asterisk log file as a source of information. This option is still experimental as it does quite a bit of guessing. Needs more testing. For production use, the --auto mode is probably safer.


If you have any questions about svcrash, check out the FAQ, and do not forget the SIPVicious FAQ too. Feel free to contact me [email protected].

A crashcourse in pentesting VOIP networks at BruCON 2010

Joffrey CZARNY and myself (Sandro) will be hosting a crashcourse at BruCON 2010. This will be a two day workshop on the 22 & 23 September 2010. In a nutshell, we will be helping the attendees quickly get up to speed with VoIP networks and performing security assessments in that idea. More information about the training can be found at the official page.

If you would like to register for the training go straight to the BruCON training registration page. Hope to see you there!

As always, I'll be glad to answer any questions by email.

Getting root access on Cisco CallManager 7 and 8 Server, Athcon, updates in new tool tftptheft and the VoIP honeynet challenge

Lots going on right now. The following is a summary:

• Recurity Labs just published the jail-break for Cisco CallManager (CUCM) v7/8 which I had something to do with ;-)
• Will be presenting at Athcon on VoIP insecurities and cybercrime - drop me an email if you'll be there
• TFTPTheft has been updated to support template filenames

Will be posting more on TFTPTheft with use cases and examples. If you do have questions, drop me an email. 

Also, right now there's a VoIP honeynet challenge for anyone into that sort of thing :-)

(image taken from striatic)

New tool in the works: TFTPTheft

Most sysadmins just love the idea of switching on a box that just works automatically. In the case of IP phones that is typically possible by setting up the right DHCP config and a TFTP server hosting firmware and configuration.

My introduction to TFTP
The TFTP protocol typically runs over port 69, and the above image shows a rather insecure doll. The TFTP protocol is rather simple and lightweight:

• Runs on top of UDP
• Does not support authentication
• Only supports pulling and pushing (GET and PUT) of files (no directory listing)

New tools?

So to retrieve a file from a reachable tftp server, one only needs to know or guess the correct filename. There are a couple of tools which do this already including a Metasploit module. However what I wanted was more specific:

• A tool that's fast like SIPVicious
• Which allows me to brute-force ranges of Cisco phone filenames (say SEP[mac-address].cnf.xml)
• And one which just downloads the guessed files as the TFTP server is being scanned

Therefore I'm releasing a new set of tools called TFTPTheft which includes 2 new tools:

• thief.py, which does what I just described (guess filenames and download files)
• finder.py, which searches for TFTP servers on the network

To give it a try, the code is currently in a mercurial repo and you can pull it by:

hg clone https://tftptheft.googlecode.com/hg/ tftptheft

I am releasing this code so that you can send me feedback. So please go forth and give this a try, run it against your VoIP system (it's likely that the PBX / Call manager will have a TFTP server running). Then send me an email with your experience: sandro at enablesecurity.com

SIPVicious 0.2.5 out

Latest SIPVicious. It has been a while since I released an update to SIPVicious. It is mostly a bug-fix and "play nice" update. Download it from here.

Changelog:

v0.2.5 (20100519)

• Feature:  svwar.py has "scan for default / typical extensions" option. This option tries to guess numeric extensions which have certain patterns such as 1212 etc. Option is -D, --enabledefaults

• General:  svwar.py and svcrack.py now have a new option which allows you to see how long the tools will scan without receiving any response back. This allows us to prevent flooding the target. Some PBX servers now have built-in firewalls / intrusion prevention systems which will blacklist the IP address of anyone using svwar or svcrack. Therefore if the IP is blacklisted it makes sense to stop scanning the target. The default for this option is 10 seconds. Set this option by using --maximumtime [seconds]

• Removed:  svlearnfp.py is now discontinued. The tool is still included for historic reasons but disabled.

• Feature:  svmap.py now includes the following new features:

            --debug - shows messages as they are received (useful for developers)
            --first - scans the first X number of hosts, useful for random or large address pool scanning
            --inputtext - scans IP ranges taken from a text file
            --fromname - sets the from header to something specific useful for abusing other security issues or when svmap is used in a more flexible way then usual ;-)

• Feature:  svreport.py now has two new modes:

            - stats, which lists some statistics
            - search, allows you to search through logs looking for specific user agents

• Bug fix:  svwar.py now by default does not send ACK messages (was a buggy feature that did not follow the standard) 

• Bug fix:  svwar.py - the template passed through --template option is now checked sanity.

RTP Traffic to 1.1.1.1

I was reading RIPE Labs' very interesting post called Pollution in 1/8. The article talks about traffic being sent to the 1/8 address space, which has recently been temporarily allocated. One part of the article caught my eye:

"We found that almost 60% of the UDP packets are sent towards the IP address 1.1.1.1 on port 15206 which makes up the largest amount of packets seen by our RRC. Most of these packets start their data section with 0x80, continue with seemingly random data and are padded to 172 bytes with an (again seemingly random) 2 byte value. Some sources (http://www.proxyblind.org/trojan.shtml) list the port as being used by a trojan called "KiLo", however information about it seem sparse."

I think I have an answer to that. Its not a trojan. On the SIP front we've been seeing some INVITE scans which start an RTP stream to IP 1.1.1.1 and port 15206. In fact RTP streams start with 0x80. Enough talk, lets take a look at a sample SIP message from these INVITE scans:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 83.142.202.195:3058;branch=ca4b60ae7ba821fREPLACEDjrgrg;rport
From: <sip:[email protected]>;tag=Za4b60aeREPLACED
To: <sip:[email protected]>
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 503

v=0
o=sip 2147483647 1 IN IP4 1.1.1.1
s=sip
c=IN IP4 1.1.1.1
t=0 0
m=audio 15206 RTP/AVP 10 4 3 0 8 112 5 7 18 111 101
a=rtpmap:10 L16/8000
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:7 LPC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

So what does this mean? According to the article, almost 60% of the traffic being sent to 1.1.1.1 consists of these RTP streams. The majority of the traffic is sent to 1.1.1.1 and is UDP traffic, meaning that the majority of Internet traffic being sent to the 1.1.1/24 is in fact RTP traffic generated by these scans.

The impression that I'm getting is that there's a lot of such INVITE scanning going on, and a large number of SIP entities on the Internet are responding to these scans by starting an RTP stream.

Sjur posted his analysis of this on his blog too.

On breaking phonecall encryption and publishing fake research

Recently, some "not so anonymous" security researcher posted research on a website called InfoSecurityGuard. It showed how he had broken the encryption provided by various mobile phone security products. Ofcourse this caught the eyes of various journalists who wrote about this without much consideration. So what did this researcher find out?



The research focuses on the fact that once you get malicious software on a phone, you can listen on the phonecall even with encryption software in place, such as CellCrypt or Gold-Lock. The researcher says that this is a result of these products not having any man in the middle protection.

Well, guess what: the products on test do network encryption. Putting software on the same phone as the one doing the encryption/decryption does not constitute as man in the middle by most definitions. Such products do not typically protect your calls from being recorded if your phone is compromised.

This applies to most other applications, not just phonecall encryption. If your security solution is meant to provide network encryption, then it typically will not resist an attack on the endpoints. Some software (like PhoneCrypt) might try to do that, but in the end of the day, if the endpoint is compromised, then there's various attacks that the software cannot handle.

Think about replacing the firmware, or the hardware itself. These are real problems that apply when your phone is compromised, yet such products are not meant to handle these issues.

After this "fake" research came out, some people actually investigated to confirm the suspicions that they were published by a known vendor - in fact the only vendor that did well in the reviews - Securstar. Read more about that on infosecurity.ch and The Register.

Oh, and one word of advice for anyone replicating Securstar's efforts - do not put your Trixbox PBX with the FOP in the open.

ps. at the time of writing Securstar's site is inaccessible and showing some php errors: