Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

The Freedom Fone Project for Africa!

Leave a comment Posted by on May 10, 2009

There are not much publicity about this project, so I wanted to explain what it’s all about.The ultimate goal is to make it easy to spread information e.g. people send a SMS and get a call informing them about HIV/AIDS or the weather.

The Freedom Fone is a universal media conveyor, it should take most media input from people (mobile, skype, web, e-mail) and generate output (sms, call, radio, web) in the best possible way.

The limitations are the usual one in Africa. No power, little or no Internet connection, few people to run it, harsh environmental conditions, etc…

Our solution seems easy, but there is some work behind it. Take a standard netbook (asus preferred) and plug in a USB to cellphone (mobigater). Install Ubuntu with Freeswitch and several other tools. Glue it all together with a lot of customization, and BINGO! We have a Freedom Fone Server!

Usage scenarios

An organization wants to spread information about specific topics. We create a SMS word people can send to be called back and informed.

Farmers want to know about the weather and subscribes on a daily or weekly weather forecast.

Ex.pats living abroad wants to help out and makes an informative radio program. This is aired on the local radio station

Others? Please comment!
[ad]

Uncategorized

And test from the Snom phone…

Leave a comment Posted by on May 5, 2009

The snom phone seems to have a built-in brute-force blocker. After a short while it does not even allow me into the web interface. This is a good idea, but can also be misused as a Denial-of-Service (DoS) attack.
Will write more about this phone when I have time.

Uncategorized

Cisco with their UC500 has not understood DNS SRV….

Leave a comment Posted by on April 30, 2009

Just setting up a Cisco UC500 and notice how “old fashioned” the VoIP settings are. The setup still believes that the provider only has one major IP address and one backup. Of course, to have one basic IP address where all traffic is routed to, and make this redudant (through virtual IP or IP take-over), is just fine and will work OK.

The DNS SRV case

If you as a VoIP Service Provider uses DNS SRV, which is designed to give you load sharing and redundancy through DNS, then the Cisco Configuration Assistant misses the point. This assistant, which is almost necessary to get the UC500 unit up and running, does a DNS lookup on the A record and takes this IP into the Access List configuration…. not good… Next time the UC500 registers, it probably uses another server, and the incoming calls are also coming from this. Then the ACL kicks in and blocks the call…

The work-around

For CCA version 1.9 there is an access-list 2 that contains the IP of the SIP server. Expand this list to cover all IP addresses from your VoIP provider. Be careful, since opening this to everybody will open you for both SPiT and possible fraud.
[ad]

Uncategorized

And the Cisc 7940 phones leaks its password hash..

Leave a comment Posted by on April 11, 2009

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]

VoIP , , ,

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

3 Comments Posted by on March 26, 2009

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)

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!

VoIP , ,

The SIP Digest leak

Leave a comment Posted by on March 22, 2009

There is a security flaw that makes a VoIP adapter send out its password. How serious is this flaw?

Sandro Gauci demonstrated on this video how a voip analog adapter sends the credentials to the other ringer. This is a lab setup, but still possible in the real world.

First, you need should be sending the traffic from the SIP Registrar (but a lot of user-agents works to send directly as well). Most VoIP SIP user-agents only accepts SIP messages from the SIP Registrar they are connected up to. Either fake the packets from the SIP Registrar, but be in-line of the traffic to receive the response, or get a real account on the SIP Registrar/Proxy and hope they do not filter these messages.

Second, you need to know the extension. This could be all from a 3-digit number, to a user name with numbers and letters of varying length.

Third, the password you receive is encrypted with MD5. You will need to brute-force this. If it is below 8 digits/letters, this is really no problem for todays computer.

Summarized:

Yes it is possible, but it does take some time and several requirements must be met. The easiest way is still (IMHO) to sniff the hourly REGISTER message (which contains the same MD5 hashed password).

UPDATE:

Just tested this on Linksys SPA2100, Grandstream GXV3000 and Fritz7270(in LAN client mode) and it worked to get the password from all of them. This is bad… really bad… further updates are coming..

[ad]

VoIP

Are your provider ready for VoIP?

Leave a comment Posted by on March 17, 2009

Companies are jumping on the VoIP wagon, but need to do their homework before implementing it locally and choosing a provider!

Tyler Merritt has written a nice article about it, I borrowed the bullet points:

Ask the provider detailed questions about their backbone.
Do they host their servers in a reputable data center? Do they get their bandwidth from a well-known provider like Level 3? A friend of mine thought it would be neat to start a VoIP company and began offering services through machines hosted in his garage. He did some good business for awhile, but his company didn’t last long.

Make sure your VoIP service requires authentication.
This point may seem like a no-brainer, but many VoIP providers do not require registration from the customer, making toll fraud incredibly easy for even amateur hackers. Authentication strings that use a hash in place of a clear-text password provide required security.

Find out what kind of VoIP architecture the provider uses.
Is their network built on a proprietary solution like Broadsoft or do they make use of Open Source VoIP solutions like Asterisk? Proprietary may turn out products with fewer initial bugs and open lines of communications to the developer via a support team, but Open Source means a much larger community of devoted followers hammering away at the application out of sheer pride and commitment to excellence. Asterisk is the most widely deployed Open Source telephony platform in the world precisely because so many people have contributed hours upon hours towards development and stability.

Figure out the DTMF type up front!
With analog lines and PRIs, DTMF was never really a consideration. VoIP companies have choices like rfc2833, inband, and info – and some companies use a different DTMF setting for inbound calls and outbound calls! If customers can reach your Auto Attendant but can’t dial an extension because key presses aren’t recognized, you might as well not have a phone system at all. This one is the Achilles Heel for almost every company I know.

Make sure your network supports QoS.
It cannot be stated enough that VoIP traffic on your network needs an all-access pass to the HOV lane. Because VoIP uses UDP instead of TCP, there are no second chances for these packets. They need to arrive in order, unchanged every time. If your network equipment does not support QoS, simple things like sending an email when someone is on the phone will have a noticeable effect to the conversation. Some customers may detect “clipping” or “clicking” on the line however briefly. A good QoS policy protecting VoIP easily soothes its greedy need for dedicated bandwidth. VoIP does not like to share.

[ad]

VoIP , , ,

Google Voice has arrived!

Leave a comment Posted by on March 12, 2009

Then GrandCentral has been re-launched as Google Voice.

Look at the interfaces here: or go to www.google.com/voice go get your own account (will be opened for new users within days..)
[ad]

Uncategorized

Presention VoIP attacks, tools and how to make a VoIP honeypot!

Leave a comment Posted by on February 17, 2009

I’m soon off on a trip to Asia to do a presentation about VoIP security and how to make a VoIP honeypot!

The presentation does an introduction to VoIP protocols and how SIP works.
Then more details about the attacks seen the last 12 months.

Watch the whole presentation here. Comments are always appreciated!

[ad#std_banner]

[ad#250×250-hj%c3%b8rnegreier]

VoIP , , , , , ,

Probing with OPTIONS messages

Leave a comment Posted by on January 24, 2009

I’m part of the Norwegian Chapter of the Honeynet Project. We have lots of honeypots with different services up and running. The most interesting for me is the VoIP honeypot. It captures all VoIP traffic and answers all incoming calls as a normal gateway or IP PBX (e.g. Asterisk) would do.

The latest traffic is again from the Piradius network.

The piradius network is now using “OPTIONS” to probe for existing IP PBX they can abuse for free calls.

Internet Protocol, Src: 124.217.230.65 (124.217.230.65), Dst: 195.159.X.X (195.159.X.X)
User Datagram Protocol, Src Port: rapido-ip (2457), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS sip:3392@195.159.X.X SIP/2.0
Message Header
Via: SIP/2.0/UDP 0.0.0.0:2457;branch=E7C34B92-11CE-87FE-DC76-8AA77F25C6B1;rport
Max-Forwards: 70
To:
From: ;tag=FB84E0A1-04AC-E4C2-D7E5-E49A34E3E90D
Call-ID: 185B191D-379F-888E-ABEB-E78C1B5DA498
CSeq: 1 OPTIONS
Contact:
Accept: application/sdp
Content-Length: 0

A new address
There is also a new IP address where the same attack is coming from. You can see it from the same structured OPTIONS message.

Internet Protocol, Src: 67.215.13.194 (67.215.13.194), Dst: 195.159.X.X (195.159.X.X)
User Datagram Protocol, Src Port: sybase-sqlany (1498), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS sip:2658@195.159.X.X SIP/2.0
Message Header
Via: SIP/2.0/UDP 0.0.0.0:1498;branch=BCEA2F83-1CEF-FC6A-2989-54C18CE6425E;rport
Max-Forwards: 70
To: <sip:2658@195.159.X.X>
From: <sip:8571@195.159.X.X>;tag=723535DC-E71F-E3D4-D572-2B41E58782E8
Call-ID: 4203F1B5-3E1F-E6D6-32FF-B8C2DFAA190F
CSeq: 1 OPTIONS
Contact: <sip:@0.0.0.0:1498;transport=udp>
Accept: application/sdp
Content-Length: 0

The packet would have been stopped in a firewall understanding SIP. The “VIA” and “Contact” field can not have a 0.0.0.0 IP address.

The OPTIONS command

From voip-info.org web page:
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without “ringing” the other party.

For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field.

All UAs MUST support the OPTIONS method.

There has been less security concern about the OPTIONS implementations, since it is the INVITE that generates the call. But the OPTIONS can reveal a lot about what User-Agent/Server it is and version. Then it is just a quick search to find a bug or backdoor on this…..
[ad]

VoIP , , , , , , ,

← Older posts

Newer posts →

Design a site like this with WordPress.com
Get started