But the Romanians keep hacking..

32 people was apprehended in Romania, but the VoIP hacking continues from this country. Low wages, highly educated people and not too many jobs often forces people to start hacking, combined with low risk of being caught.

This was from IP 188.24.194.155 caught in a SIP honeypot belonging to Honeynet Project.

REGISTER sip:IP.removed SIP/2.0
Via: SIP/2.0/UDP 192.168.0.135:5060;rport;
branch=z9hG4bK6640
From: <sip:1234@IP.removed>;tag=3202
To: <sip:1234@IP.removed>
Call-ID: 14862
CSeq: 1 REGISTER
Contact: <sip:1234@192.168.0.135>
Max-Forwards: 70
User-Agent: Linphone/3.3.99.9 (eXosip2/3.3.0)
Expires: 3600
Content-Length: 0

Normal procedures is to use SIPvicious to do scanning, then use Linphone or other softphone to test out if you can dial out on the discovered IP PBX.

VoIP admins, do a pen-test on your own system and lock it down. This is, sadly, just the start….

VoIP hacking is a BIG industry! 32 people apprehended in Romania

This morning, the Directorate for Combating Organized Crime and Terrorism (DIICOT) in Romania conducted 42 raids, identifying 32 people specializing in VoIP hacking.

Numbers so far is 11,5 million euros in fraudulent VoIP traffic from this group. The group made around 10% of this amount from their premium numbers.

The main technique seemed to establish premium numbers in Sierra Leone, Somalia, Austria, Latvia, North Korea, Zimbabwe, Madagascar, Belarus, etc and cash in on calls to these destinations.

This correlates to attacks we have seen, calls trying to go to Somalia and Sierra Leone on our VoIP honeypots (but of course they were not successful).

This only confirms that there are major money in VoIP hacking and this is not single persons doing it but organized crime. I’m afraid this is just the beginning.

Original link

Link translated to English

Sandro Gauci has written more about it here

400% rise in telecom fraud in New Zealand

Telecommunications Industry Group (TIG) in New Zealand has seen the telecom fraud quadruple in 2010. Private Branch Exchanges (PABX) can be downloaded for free and installed on an (older) PC, but not secured enough. This makes the PABX open for exploiting. TIG has made a list of what minimum(!) need to do, to ensure that your system will more secure.

Some practical tips for preventing PABX hacking

1. Choose a strong password: Voicemail and DISA passwords should be changed on a regular basis, avoiding factory defaults and obvious combinations such as 1234 or the extension number.
2. Change it: Make sure all security features – passwords, PINS etc – are changed following installation, upgrade and fault/maintenance. Don’t forget to reset password defaults.
3. Keep it confidential: Keep all internal information such as directories, call logging reports and audit logs confidential. Destroy them appropriately if no longer required.
4. Regular Review:
   • Review system security and configuration settings regularly. Follow up any vulnerabilities or irregularities.
   • Review your PABX call logging/reporting material regularly and analyse it for increases in call volumes or suspicious destinations.
5. Callers: Be vigilant against bogus callers – for example, people posing as company employees – who ask to be connected to switchboard operators to get an outgoing line.
6. Employees: Develop processes to cover employee entry procedures, passcards, new employee vetting and people leaving and changing jobs. Formally evoke their access to systems, mailboxes and buildings.
7. Vendor Terms and conditions: Make sure you have the right terms and conditions reflected in your contracts with your PABX, VoIP and/or voicemail maintainer in order to keep your system regularly maintained and serviced to stay safe.
8. De-activate, Restrict, Bar:
   • Remove or de-activate all unnecessary system functionality including remote access ports. If remote access ports are used, consider using strong authentication such as smartcards/tokens.
   • Restrict any destinations that should not normally be dialed: for example, premium rate, international, operator and directory enquiry numbers.
   • Restrict access to equipment eg. your comms room and master terminals.
   • Only give the appropriate and minimum level of system access required to carry out a task.
   • Bar voicemail ports for outgoing access to trunks if possible.  If access to trunks via voicemail is necessary then implement suitable controls. Remove auto attendant options for accessing trunks.
   • Lock surplus mailboxes until allocated to a user.
   • If DISA is not used then disable it completely.
9. Tones: Avoid using tones to prompt for password/PIN entry: these are often used by hacking programmers.

I would also like to add:

• Security updates BOTH on your server and on the phones
• Don’t expose the PABX nor the phones on public IPs.

The Honeynet Project has also picked up extensively scannings in Australia. Which country will be next?

An old SIP scanning has started again.

Now the scanning has started again.
For those remembering back in 2008 there was a large scanning in Germany, where customers with softphones experienced incoming calls (very annoying during the night..), it has now started again. A good paper from ipcom.at describing it extensively.

What caugt my attention was the very long branch and callid fields. They contain IP of the scanner, the scanned victim, the phone number trying to be called and several other fields (if you know what the rest of the codes are, please let me know!)

INVITE sip:82727117149111@the.honeypot.ip;transport=udp SIP/2.0
Via: SIP/2.0/UDP 202.71.111.5:3916;branch=11010010111010001010101000110202.71.111.5the.honeypot.ip751302518;rport
Max-Forwards: 70
From: <sip:736115896703798455@the.honeypot.ip>;tag=5475511560139881995954755115605475511560202.71.111.5
To: <sip:82727117149111@the.honeypot.ip>
Call-ID: ed6681d610110011110110100100110111000011010010111010001010101000110202.71.111.5the.honeypot.ip7513025181c895d9827271171491115475511560139881995954755115605475511560202.71.111.51621419374
CSeq: 1 INVITE
Contact: <sip:1c895d9@202.71.111.5:3916;transport=udp>
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: eyeBeam release 1003s stamp 31159
Content-Length: 208

v=0
o=- 16264 18299 IN IP4 the.honeypot.ip
s=CounterPath eyeBeam 1.5
c=IN IP4 the.honeypot.ip
t=0 0
m=audio 34222 RTP/AVP 18 0 8 101
– Hide quoted text –
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

And no, it is definely not “CounterPath eyeBeam 1.5” but a custom-made scanner. This is just an indication that people are willing to put mony into developing software to attack these insecure VoIP servers.

Status now is frequent usage of stand-alone SIPviciuous and other scanners, and two kits doing extensively scanning:

the userAgent=sundayddr
they started this spring, getting scannings from all over the world, but an overweight of Chinese IP addresses.

the current scannings with “Counterpath” as user-agent.
They have been active before, and now started again (scanning latest month)

And this is just the beginning…. so secure your VoIP servers!

Just 10 000 USD in hacking this time..

A VoIP hacking that actually reached the public, was just 10 000,- USD being frauded for. I would say they were lucky. This is just top of the iceberg, I hear about so many more not being reported because the firm or institution does not want to “have beeing hacked”. The latest news about it in Norwegian or translated to English

Another VoIP hacking in Norway

The latest month of scanning has seemed valuable for the hackers. A Norwegian municipality has been hacked and their PBX has been calling Somalia and a lot of others destinations we have picked up on our VoIP honeypots during the last month.

If you have an unsecure IP PBX on the net, now it will only take hours before it will be detected. Most normal cause for this is misconfiguration. The people setting up the IP PBX has not taken security seriously and the IP PBX is wide open for calling.

The simplest ways is that inbound calls is routed out again if no local destination is found.  A little harder is to just brute-force the password on extensions. I can only say, there will be more like this!

Norwegian version

English version

The hacker can sell this “gateway” to a third party dealing with calling cards. I have investigated frauds in Norway where they managed to send 1,2 million NOK (approx 200 000 USD) within 10 days. This was a Cisco installation, but misconfigured Asterisk installations are also abused a lot.

SIP scanning causes DDoS on IP 1.1.1.1

RIPE said a long time ago that IPv4 is running out of addresses. Now they are also allocating the 1.x.x.x network for production traffic. But this is a bit problematic, since people have been using IP addresses like 1.1.1.1 and 1.2.3.4 as examples in scripts, tools and manuals. People who don’t know any better, they try contact these. When they routes to these networks where alive, a LOT of traffic started coming in.

What made it interesting for Sandro in EnableSecurity was that most traffic was UDP (60 %) and almost 90 % to IP addresss 1.1.1.1. This is a text from RIPEs article about it:

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.

This can actually be RTP traffic (VoIP audio traffic) generated from hosts that are vulnerable to SIP INVITE attacks, as Sandro points out in his comment and on his blog.

This is also alarming! This scanning with default RTP audio to IP 1.1.1.1 and port 15206 seems to be doing REALLY well on the Internet. There are a lot of VoIP unsecure platforms accepting and responding to ANY SIP INVITE they get. The software doing it is NOT SIPVicious, but another. It normally uses port 3058 to send the SIP INVITES from. If anybody knows something about this software, please contact me.

I have had a slide in my VoIP presentations about this scenario. If you do a SIP INVITE sweep, you should NOT have a valid IP address for the audio. Every successful INVITE would then generate at least 20 seconds of 0,1Mbit per second stream (g711 audio) to your IP address. Your SIP INVITE sweep with your IP as receiver for RTP traffic will not take long before it backfires on you and you get a DDoS on yourself (well earned though IMHO).

So what is next?

I would love to have a honeypot or get access to the traffic going to port 1.1.1.1. All hosts that would send RTP traffic to this address, should be contacted and asked to secure their servers!

Status now from RIPE:

Since the traffic patterns seemed to be stable we decided to withdraw the announcement of 1.1.1.0/24 and 1.2.3.0/24 on 2 February 2010.

A great challenge awaits you!

Slightly interested in security?

Do you want to learn more about investigating attacks?

Here is your challenge!

The Honeynet Project has released this years first Scan of the Month challenge! It has many levels and now you can test if you are up to it!

[ad]

And the Cisc 7940 phones leaks its password hash..

With some help from Sean in the US, Sandro and I could access a Cisco 7940 phone (with a SIP stack) from the Internet. We called it from our public ip (showed as 192.168.1.1).

[ Fri Apr 10 21:16:16 2009 ](192.168.1.1/32) Proxy auth:
[‘Digest username=”5555914760″,realm=”localhost”,uri=”sip:192.168.2.2″,response=”a718dsf8c742799f1c22fbcd1d4637d801b”,nonce=”a”,algorithm=MD5’]
[ Fri Apr 10 21:16:16 2009 ](192.168.1.1/32) The phone rings on extension 5555914760
[ Fri Apr 10 21:16:16 2009 ](192.168.1.1/32) Launching the password cracker
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) Password was not guessed
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) Use the SIP Digest Cracker to perform an extensive bruteforce
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) username: 5555914760
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) nonce: a
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) realm: localhost
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) uri: sip:192.168.2.2
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) method: BYE
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) response: a7188cfwet742799f1c22fbcd1d4637d801b

Then we could start our brute forcing of the password, and then either log-in and receive calls as Sean, or make outbound calls as him. Next phone to test is the Snom phone.
[ad]

Get the password from ANY SIP device?!?! It is fully possible!

If I know the IP address of your SIP User-Agent and your extension, I can get your password. Not true? Here is how Sandro and I did it! Sandro Gauci also has a tool (voippack for Canvas) which automates the whole process, you can watch the video here!

The fault is that a User-Agent actually answers on an authorization request, even though there is no reason for it. We first send an INVITE, the user-agent rings and the user picks up the phone. When the user hangs-up, we reply the BYE message with an authorization request, which the User-Agent normally answers with a SIP Digest (with the encrypted password). We brute force this digest.

The master plan:

1. Check up on the Internet which ISPs are delivering VoIP. Check RIPE for their IP ranges. Scan them for SIP devices.
2. Get the extensions they are using (or their ranges of usernames (e.g phone numbers, then do brute force on these ranges on each IP)
3. Send an INVITE to the correct extension and the phone will ring. When the user hangs-up, we have the password.

The details:

We make the phone send a PROXY AUTHENTICATION when the SIP UserAgent sends the BYE message. We answer with “407 Proxy authorization required” and then the SIP UserAgent actually answers this with the password in a MD5 hash.

The problem

• The SIP stack is not connected to the IP Stack. Why is the SIP User Agent answering on SIP messages from other IPS than the SIP Registrar it is connected to? There should be automatically a rule saying “all SIP messages from other servers than what I’ve registered to = drop them!”
• Why does the User Agent blindly answer a challenge on the BYE message. Just send it a “407” and the SIP UA answers with the password…

Units tested (and we managed to get the password)

• Linksys SPA2102
• Grandstream GXV3000 (latest firmware)
• AVM Fritz 7270 (firmware december 2008)

The units that will be tested further:

• Polycom
• Thompson ST2030
• Snom

How to protect yourself (for users)

• Make sure your VoIP provider has credit limits! You don’t want to get a huge phone bill!
• Report any unusual phone calls or strange behavior!

How to protect yourself (for VoIP providers)

• Protect your SIP user-agents! This is hard with the Fritz units
  which is normally used as a router
• Have very long SIP passwords and use all characters that is possible! (#¤%” and others)
• Change the SIP password regularly
• Run VoIP honeypots to detect scans in your area

How serious do you think this is? Write your comments now!