The NSA’s Crypto Museum

Enigma Machine

I was interested last week to discover that the USA has its own Museum of Cryptography. The National Cryptologic Museum is run by the National Security Agency in Fort Meade, Maryland. Curiously, the building used to be a motel, quite literally in Fort Meade’s backyard, but was annexed by the NSA when it came up for sale.

Over the last few years I have been a regular visitor to our own British equivalent, Bletchley Park, which is both a cryptography museum and also houses a historical collection of computers. If you’re in the UK, or visiting (Bletchley is about an hour North of London), then I would highly recommend a visit. Bletchley Park is an estate with a victorian manor house, and during World War II it was the scene of operations of the UK’s codebreakers, including computer pioneer Alan Turing.

It sounds like Bletchley and the NSA’s museum have many things in common, both exhibiting the (in)famous German Enigma coding machine, and both having Cray supercomputers on display. I will certainly put the National Cryptologic Museum on my list of places to visit the next time I’m in the Washington area.

VOIPSA 2.0

It’s been over 5 years since the Voice over IP Security Alliance was born.  A small group of us originally aimed to fill a very large gap in the voip security landscape. Namely that outside of IETF meetings, the thought leaders in the carrier, vendor, and security industries didn’t really have many other vehicles to discuss and address security issues in VoIP.  VOIPSA was and is meant to bring those people together by promoting security research, testing methodologies, tools, and most importantly, discussion.

The need for VOIPSA is greater than ever, and we need fresh input to evolve to the next phase.  My professional interests have changed recently so that I will no longer have the time to devote as Chairman.

It gives me great pleasure (and relief) to announce that Dan York has graciously agreed to step up as our new Chairman and fearless leader. I am also pleased to announce that Jonathan Zar has agreed to continue on in the meantime as Secretary.  Dan and Jonathan have been instrumental since the beginning of VOIPSA in setting up the organization with me and evangelizing many of the issues that still plague VoIP deployments today.  Many of you already know Dan from his podcasts, his conference speaking, and his prolific blogging on Voipsa.org, and Jonathan from his industry leadership and venture expertise.

You’ll be hearing from Dan and Jonathan in the near future on the vision and next steps at relaunching VOIPSA.  Thank you to everyone I’ve worked with over the last 5+ years who have given selflessly of their time and effort to VOIPSA.

-dave

David Endler
david.endler@voipsa.org

Firesheep – a new tool for capturing data on unsecured WiFi

This isn’t about VoIP, per se, but it is about the threat we’ve long talked about of transmitting data over insecure WiFi networks. At the Toorcon 12 conference this week, Eric Butler and Ian Gallagher released a Firefox add-on called “Firesheep” (view their Toorcon slides) that scans an insecure WiFi network for login credentials passed as cookies and then, with a single click, lets you login to those accounts. Some of the reports:

TechCrunch followed up with a post about how to protect yourself – by forcing SSL connections:

Although as noted in the comments, that doesn’t always work.

While this Firefox add-on is focused on the security of social networks, there are many other services out that there are sending data unprotected over networks.

In the end, we need more SSL (or “TLS” to those who understand the difference) – and other end-to-end technologies – to give us a safer Internet. Sadly, it will probably take proof-of-concept apps like this to make people pay attention.

Wall St. Journal – Denial of Service attacks on phones responsible for $70 million fraud losses

wsj.jpgHave you received a barrage of phone calls to your number? If so, you may be in the process of being victimized, according to a Wall St. Journal article over the weekend called “Preventing a Hack Attack.” The article outlines how a cyber-theft ring that was broken up last week used automated dialing programs to tie up users’ phone lines while the attackers were raiding bank and brokerage accounts to the tune of around $70 million in losses.

Per the article, the attack had two components. First a malware program went out through email messages and attachments. Once a user clicked on it, the trojan searched the local computer for usernames and passwords for brokerage or online banking accounts and sent that info back to the attackers. Second:

At the same time, victims’ phones were tied up with a barrage of phone calls, according to the federal complaints, preventing them from contacting their bank or brokerage. Busy signals also prevented fraud monitors at the institutions from contacting victims, according to FBI officials who were interviewed before the announcement of the arrests.

…

The telephone bombardments lasted as long as a week, sometimes forcing victims to disconnect their lines or switch phone numbers, which bought the suspects time to raid their accounts.

The reality today is that our VoIP infrastructure makes these kind of automated attacks trivial to carry off – and they will only continue to grow as an attack mechanism. The equipment to carry off those attacks can simply be open source software running on servers or even virtualized into a cloud (or distributed on a botnet). Connections to VoIP providers which can then get you PSTN access are both trivial and incredibly cheap.

The article’s recommendations about how to protect yourself were the typical basic steps… use secure passwords, change them often, ideally use a separate computer for online banking (I highly doubt people will do that), use anti-virus, don’t open untrusted attachments, etc. For protection against malware, those are all certainly viable strategies.

For protection against a DoS on your phone number? Not so much. That kind of protection requires more systemic steps within the larger infrastructure – and is at odds with the fundamental aspect of the PSTN where anyone can call anyone else.

Welcome to our brave new world…

VoIP Firewall: Telephony vs Security world

During that period i started to deeply understand and evaluate matters related to the protection of VoIP related infrastructure against attacks and the diffused technologies for signaling and VoIP encryption.

I investigated the concept of “SIP Firewalls” and “VoIP Firewalls” and found that in this area there’s a lot of confusion and misunderstanding among the IT/Telephony and IT Security users given the fact that the VoIP telephony and IT Security world usually speak a different language.

I understood that there is a clear increasing interest by IT security world in VoIP protection even if most of the VoIP security product out there are more oriented to Telephony specialist than to Security specialist.

Security products or telephony products?

The market is very fragmented and it’s plenty of

  • Telephony Gateway doing something about Security
  • Telephony PBX with some Security feature
  • Security Gateway doing something about Telephony

It must be clearly identified whether a specific kind of device/product it’s something “doing more things about security” or “doing more things about telephony” .

That’s especially important because it must be understood whether a product can be used by who works in security or by who works in telephony, also because the knowledge required to approach a security product it’s different to approach a voip product.

I know plenty of VoIP specialist that doesn’t know about UTM, IPS, DPI and VPN technologies.

I know plenty of Security specialist that doesn’t know about SIP, RTP, VoIP protocols and architectures.

Finding out specialist of VoIP and Security together it’s a rare thing.

So it’s relevant to look at the full feature set and at the USP (Unique Selling Points) of various products to identify whether a product it’s something for the Telephony part of the world or for the Security part of the world.

We must expect that a Security product require very little understanding of Telephony while a Telephony product require very little understanding of Security.

What SIP/VoIP Firewall do?

When we glue together the terms “VoIP/SIP” and “Firewall” we generally have different understanding depending on the world from where we come.

Especially different kind of users consider valuable completely different kind of product features that can be identified as follow:

Telephony world

  • Networking and NAT related issue resolution
  • SIP compatibility among different vendors
  • Quality of Service and traffic prioritization
  • Easier VoIP trunking

Security world

  • SIP security protocol inspection
  • Closing doors by letting only minimum traffic to goes in/out firewalls (ip filtering)
  • Denial of Service prevention
  • SIP signaling and voice encryption

That said it’s clear that the expectation of what a “SIP Firewall” should deliver it’s perceived very differently among different sectors.

Telephony world care about making things works and dealing all networking/NAT/compatibility pain of VoIP, especially because of the need to integrate very old and big PBX with new extensions.

Security world care about protecting the server behind their firewalls against intrusion and information integrity/confidentiality (eavesdropping for phone calls).

Organization issues

From the organization point of view it’s also highly relevant to understand the different duties and behaviour related to Security department and IT/telephony department.

Security guys are the ones who manage the security control the firewalls and have the authority of defining what exit to the internet and that can get inside the different levels of corporate perimeters (such as DMZ and internal networks). When someone from within the organization need to expose a service to the internet they are the one saying yes/no and at which conditions.

Requests to expose internet services could come from the IT department for some server but also the accounting department for SAP and even the marketing department for some website.

When request come for telephony equipment the security always get worried.

That’s because the typical firewall setup use NAT and the Telephony guys know that putting a VoIP server behind a NAT, even controlled by a firewall could be very problematic for what’s related to the SIP protocol handling.

So Telephony guys ask to Security guys to have their gateway placed outside the firewall.

Aaaaaaaaaaargh! The Security guy will say! That’s not possible! The traffic flow must be under our control! Otherwise how could we protect the VoIP infrastructure from attacks delivered via SIP protocol and Denial of Service?

So the relationship between Security world and telephony world in a large organization can be very problematic.

Now add the fact that the Security department may require to protect the confidentiality of mobile and landline phone calls, something that’s considered a really sensitive matter and cannot be delegated to the IT/Telephony.

Who have to handle the VoIP encryption project? The Telephony department know about VoIP but only a few about Security or but the Security department know about security/crypto but only few about VoIP.

So the matter can be complicated, even more if the infrastructure and hardware/software setup include multiple different technologies and/or particular telephony services (such as multiple trunking, IVR, Queue, Call forwarding, etc, etc) that are out-of-the-scope respect to the need of protecting phone call.

Now, let’s see what’s on the market?

Let’s make some review of what’s on the market.

I will just refer the major and more known products by splitting products in 3 different categories (It’s oversimplified but effective) :

  • VoIP firewalls with voice encryption
  • VoIP PBX with VoIP encryption
  • Firewalls with SIP protection

The first two sets are products dedicated to Telephony world where a specific telephony related knowledge is required while the Firewall, now referred as UTM (Unified Threat Management) are systems requiring specific IT security knowledge.

VoIP firewall with voice encryption

The described below VoIP firewall does all the typical VoIP firewall features related to NAT/Networking, Quality of Service and SIP compatibility, but provide also an external interface to connection VoIP clients with voice encryption protocol with SIP/TLS and SRTP.

UM LABS SIP Security Controller

Ingate Firewalls

SIPera UC-SEC SIP firewall

If the specific infrastructure is using and old and outdated PBX software that may be difficult to be upgraded, then as a workaround a SIP firewall it’s needed.

If a specific infrastructure is using modern PBX software with basic security features, then a SIP firewall it’s not usually needed.

VoIP PBX with Voice Encryption

There are several PBX and SBC (Session Border Controller) that speak the VoIP encryption technologies of SIP/TLS and SRTP and among them the most known are:

– Asterisk 1.8

– FreeSWITCH 1.0.3

– Cisco VoIP PBX and SBC

All those VoIP equipments already support signaling and voice encryption without any need of adding different piece to the puzzle and those PBX can be connected to existing PBX acting as a gateway between secure users and existing users on old internal PBX.

For what apply to the protection against brute forcing and extension enumeration (finding your VoIP phone account on PBX) most now PBX support some native protection features while additional protection can be always provided with the pluggable anti-brute-force and anti-user-enumeration module such as ossec (For Asterisk and for FreeSWITCH) or Fail2ban .

Firewalls with SIP protection

Within the environment of firewalls we can find two different kind of SIP related features:

  • SIP Security Inspection: For enforcing SIP protocol inspection and direct attack protection
  • SIP ALG: For fixing NAT and SIP related networking issues

We are interested only in the device that provide a wide level of protection and will not refer Firewalls that just do SIP ALG for NAT adaptation.

While SIP protection is provided by Sonicwall, Checkpoint and Fortinet i think would say that Cisco is the most advanced one as it’s the only Firewall that support natively also VoIP encryption by leveraging the concept of VPN to VoIP.

Cisco ASA Firewall SIP/TLS Proxy and Phone Proxy (For SIP/TLS + SRTP)

Fortinet Fortigate Voice Over IP Protection over and SIP Security configuration manual

Checkpoint Firewall VoIP protection (Inspect SIP/TLS with this SIP protocol enforcement )

Sonicwall Firewall VoIP protection Base and Advanced

Sounds confused? Get a short comparison.

Maybe yes, because if you are not specifically VoIP knowledgable or very Security knowledeable it may be different to understand which product fit a specific scenario.

I tried below to make a comparison of various feature set of VoIP Firewalls, Firewalls and VoIP PBX with security features.

NOTICE: The following analysis has been done by looking at websites and configuration manuals of various vendor without deep testing in laboratory!

Product SIP/TLS SIP protocol sanitization SIP aware IP Firewall SRTP Voice Encryption SIP Brute Force Protection SIP Enumeration Protection DOS (flooding) protection
Cisco ASA Firewall YES YES YES YES YES (connection-limit) YES YES
Checkpoint Firewall YES YES YES NO NO NO YES
Fortinet Fortigate Firewall NO YES YES NO YES (rate-limit) YES (rate-limit) YES
Sonicwall UTM Firewall NO YES YES NO NO NO YES
UM LABS SIP Security Controller YES YES YES YES YES YES YES
SIPERA UC-SEC YES YES YES YES YES YES YES
Ingate SIP Firewall YES YES YES YES YES YES YES
Cisco IOS/CallManager PBX YES YES* N/A YES YES (connection-limit) YES YES (IP/FW/IDS IOS)
Asterisk PBX YES YES* N/A YES YES** YES YES**
FreeSWITCH PBX YES YES* N/A YES YES** YES YES**

* By default are quite strict at protocol compliance given their wide diffusion on the market

** With additional tool such as Fail2ban and OSSEC

*** When authentication is properly setup (all users must authenticate to do any actions in speaking with the PBX) there’s automatic call hijacking protection

Please note that modern PBX with security features already provide most of the required SIP protection, it’s obviously a matter of configuring it properly (for example enabling only authenticated SIP registration/calls, only over SIP/TLS encrypted channels with SRTP encrypted media flow).

Ok, but what do i need? It depends!

It’s not straightforward to say what kind of protection do you need, and mostly depend on what do you want to do and what do you already have in-house.

The two common scenario we can expect is:

a) The need is to expose to internet one PBX in order to establish a VoIP trunk with another PBX

In such case you may have two situation that will tell you whether to implement or not some custom Security Gateway by answering such questions:

  • Does your corporate PBX it’s old, legacy, not updated since a lot of time?
    • You need a VoIP firewall
    • OR
    • You can add a VoIP PBX with VoIP Encryption properly configured and add some little security add-on and configure it as a Gateway
  • Does your corporate PBX is a modern PBX with SIP/TLS along with strict authentication checking?
    • You could need to have a Firewall with SIP/TLS inspection feature (Cisco or Checkpoint)

b) The need is to implement VoIP encrypted calls for roaming users outside corporate perimeter

In such case you must first ask yourself some questions:

  • Does your existing VoIP equipment is compatible with the Security protocols used to provide Secure VoIP (SIP/TLS + SRTP) to roaming users?
    • You need a Firewall with SIP/TLS feature
    • OR
    • You can keep your VoIP PBX with VoIP Encryption properly configured and add some little security add-on (anti-bruteforcing, local firewall)
  • Does your existing VoIP equipment is not compatible with the Security protocols used to provide Secure VoIP (SIP/TLS + SRTP) to roaming users?
    • You need a VoIP Firewall

However in all case, if you already have a Checkpoint Firewall or a Cisco ASA, i suggest to however let them does the activity of SIP inspection and dynamic firewall port opening.

What to expect in future?

My conclusion is that the IT Security world is now starting considering serious VoIP security related issues and that there is a growing adoption of signaling and media encryption for Large Enterprise users.

While Private and Government users still need to use ZRTP, because of it’s unique end-to-end encryption feature, Enterprises are adopting SIP/TLS and SRTP given the end-to-site security model requirements.

What we can expect to see in the near future is the upcoming introduction of SRTP features into the big player of Firewall market with a concept of Voice VPN exactly like Cisco has already done with it’s own Cisco ASA.

At the same time every day more PBX start implementing security features for signaling and media encryption.

My feeling is that in the near future the VoIP Firewall market will became much more Telephony market oriented, as the Firewalls will start see improvements in their VoIP protection features along with Voice VPN functionalities.

At that time the security guys will have the VoIP security features included in their already installed Firewalls with a software upgrade and will not care anymore about VoIP Firewall.

What reasonably we should expect is also to see in upcoming year are Hardened PBX distributions that will include by default advanced security features, suitable for security departments.

Fabio Pietrosanti (naif) – http://fabio.pietrosanti.it

VoIP Attackers – Sometimes They Come Back

In my previous post I briefly touched on information that I had been collecting for over 19 months via what began as VoIP Intrusion Detection system I had whipped up from scratch. The framework for Arkeos began almost three years ago while working here at an ITSP slash managed service provider. One of our services is a “managed VoIP service” similar to Packet8 or Vonage for small to mid-sized business. I lost count of how many PBX’s we maintain nowadays but I will comfortably float this number at around 60’ish. Altogether I have about 1,600 clients mainly small to mid-sized businesses with a couple of Fortune 500’s in the mix. My company also provides SIP trunks and we have about 30-35 VoIP companies who use us as their backbone for their VoIP services. Because of my position in my company (multiple roles), I have great visibility into many different VoIP hardware and software vendors in fact, I can’t think of a VoIP related vendor I haven’t dealt with in the past 5 years. Avaya, Nortel, Mitel, Cisco, Acme Packet, Audiocodes, Allworx, PBXNSIP, Asterisk and the list goes on. Because my “main cup of tea” is security, I began meshing security with VoIP.

Arkeos does a few things: 1) Collects information on bruteforcers 2) Collects information on attackers 3) Records the calls an attacker is trying to send and 4) Mimics a phone so that an attacker thinks they are placing a valid call. When I first scripted it, I had to customize it in accordance to the device it was being deployed on, these were mainly Asterisk based PBX’s. Because I was using different versions of Asterisk, I had to tweak the script almost daily as the columns in Asterisk’s message file was different. For example:

2010-09-25 21:02:48 NOTICE[14155] chan_sip.c: Registration from '"3068" ' failed for '72.55.179.180' - Wrong password
2010-09-25 21:02:50 NOTICE[14155] chan_sip.c: Registration from '"3068"' failed for '72.55.179.180' - Wrong password

These are two different entries to parse with awk. To obtain the first entry, I would use ‘awk {print $10}’ whereas the other would be awk ‘{print $9}’. I initially thought of going with Python, then Perl, but settled on good old fashioned shell scripting. This ensured me that no matter what system I deployed it to, I would be able to use readily available tools on the system without introducing another application. Arkeos in all honesty is a nightmare to look at if you’re a coder, yet completely functional for what it does.

After tweaking it to my needs, I began to see many patterns die and many emerge. Years back, I saw the “fire and forget” method of attacks where you had a bruteforcer compromise an account, then that same bruteforcer fire of as many calls as they could possibly send. Nowadays I see “bruteforce” drive-bys and an attacker come from left field. Without giving up information to potential attackers who may read this, let’s assume I have an account of 5000 with a password of 5000, I’ll see say 10,000 attempts from an address of 10.10.10.10 trying to guess the password, with an attacker from 20.20.20.20 registering to use the account. From more or less November of 2009 through now, I have yet to see a bruteforcer gain an account AND log in at the same time. On the contrary, I don’t see bruteforcers’ addresses on my honeypots anymore.

mysql> use arkeos;
Database changed
mysql> select * from attackers where attacker_address='92.81.245.67';
ZZZZ, 92.81.245.67, Zoiper rev.5324, XXXX, 2010-09-11, 03:16:28
1 row in set (0.00 sec)

mysql> select * from bruteforcers where attacker='92.81.245.67';
Empty set (0.01 sec)

mysql> select * from bruteforcers where start_date='2010-09-11';
Empty set (0.00 sec)

mysql>

NOTE: I modified the output to fit it to page, the exact format of Arkeos and its tables can be seen at: http://infiltrated.net/arkeos-w-mysql.txt and the audio for this call can be heard at http://infiltrated.net/mgz/92-81-245-67-audio.wav)

So why is this information not only important to engineers (be they VoIP, Security, Network or Systems engineers) but also to perhaps law enforcement, the answer is a bit complex so I will try my best to explain my point of view, theory and concept. Imagine that right now I saw a bruteforce attack from say Korea with the account actually being used from say Romania. Romania hoses my machine and costs me say 100,000.00. For the time it would take for an investigation to even take place, get subpoenas in order, go around the world, get those companies to co-operate, at the end of the day, the investigation would likely yield NOTHING. I say this because of the ease of readily available networks and hosts that are likely compromised and used for bruteforcing and attacking. However, this is SOLELY for the bruteforcers. Did I mention the actual attacker is coming from elsewhere?

An attacker is, who I categorize in my writing, someone who has actually tried to place a call through my honeypot. Heck, bruteforcers I can easily block, prior to my honeypot I had created my own Asterisk based IPS capable of blocking bruteforcers in real-time. Attackers I want to believe are a bit more static in the sense that I believe whoever is behind 92.81.245.67 is the culprit who needs to be either arrested or rubber-hosed (depending on your view of justice). So what is relevant for an investigator outside of the attacking IP? For starters, Zoiper is a softphone (for those who don’t already know this) which means this attacker is likely using either a desktop or a laptop. Further, because I’m also tracking the number(s) being called, I gained the following insight:

awk '/407272/{print $1}' /usr/share/arkeos/calls/92.81.245.67/*
0040727246641
01140727246641
00140727246641
901140727246641
90040727246641
90040727246641
90040727246641

What have we here? Intervention is what. Arkeos mimics a telephone so unless an attacker was on the opposite end of the number dialed, how would they know to try 011, 001, 9011, 900 and so on and so forth. Hence the title “Sometimes they come back.” I have seen quite a few attackers coming back week after week from the same addresses sometimes, using the same accounts, trying to call the same number. So where would I look if I were an investigator? Directly at whomever owns that number they’re trying to call, that’s where. I theorize that if one tracked the owner of that number, searched the computers of who owned that number for Zoiper, I’m willing to bet they’re one in the same. Coincidental? Highly unlikely. An IP address, a phone number AND a softphone client ALL coincidentally belonging to one person is more than coincidental.

Anyhow, I have created an online submission form for others to submit attacker data and am trying to figure out a way I can streamline Arkeos to be a “plug and play” script for anyone willing to use it. I will eventually create a database which others who collaborate can update and pull from but I don’t want to run into a thousand emails asking me to “customize” Arkeos. This is the only reason I haven’t made it public. Remember, I made this from scratch and it was tailored to my machines and since all machines differ, I do know that I will receive those emails. To which I have little time to respond to. I try to answer as many emails as I can, but the fact is, I’m all over the place sometimes (literally.)

VoIP Abuse Project

Brief History

Throughout the course of three years I have been studying the Voice Over IP attack canvas. As a security engineer, I have had the privilege of seeing an enormous amount of attacks while working at a Managed Services Provider. Because I have multiple roles in the company I am working at, I get the best of multiple worlds. Sometimes I’m a VoIP engineer, sometimes a pentester, sometimes systems engineer, other times it depends highly on my mood. Overall I’m a Senior Coffee Tasting Engineer working at a company that gives me great flexibility to do what I want. This allowed me to create my own Voice Over IP Honeypot I called Arkeos for data analysis.

My original security application began as a “blacklisting” slash “VoIP Intrusion Prevention System” program using Asterisk. The goal was simple, keep an eye on live servers and when an attacker made a move, initiate a mechanism to automatically block the attacker, send the engineers a report, place the offender in a list to be distributed to all other PBX’s in my company so they too can block them. Initially my VoIP IPS worked just as programmed however, because I have clients all over the world, it became difficult to outright block entire CIDR ranges. I quickly whitelisted many addresses, re-hashed the IPS which worked fine for years.

The Arkeos idea came to mind after browsing around to see that there really wasn’t anyone to correspond with in this matter. People looking for and sharing similar data were few as opposed to normal networking slash abuse. I decided to build my honeypot based on what I was seeing from monitoring logs. Anyone who has known me for years can tell you that I kept tons of terminals opened with good old faithful tail -f running alongside whatever logging applications I have in house (Splunk, etc). As months passed by, I began archiving data from attacks spread across 20-30 Internet facing PBX’s. My current company sells VoIP trunks, managed VoIP services, T1-OCx connections, managed security services, video conferencing, digital signage, etc.; if it’s out there, then we likely do it. This gives me a high degree of visibility for not only VoIP attacks, but other attacks as well.

Arkeos is a program primarily used on Unix based servers running the Asterisk Open Source PBX. The application mimics a valid extension in which an attacker, after bruteforcing an account, attempts to place calls. What the attacker doesn’t know is that their calls go nowhere. The sole purpose of allowing them to perceive they have an account is to track them. Where they come from, what accounts they use, what VoIP account scanners they use, what numbers they try to dial. Because of the flexibility of Asterisk and Unix as a whole, the application does a lot more than stated however, I will not disclose too much otherwise any attackers reading this might catch on. Then I won’t have anyone to play with.

As time progressed customers who purchased SIP trunks from us were getting “owned” from time to time and to date, I have been called to handle incident response and forensics on over 75 VoIP servers ranging from Asterisk, Avaya, pbxnsip, CME and a mixture of everything in between. Usually the outcome has been the same: weak accounts and weak passwords.

2007 – 2008’s Attackers trends

For the better part of 2007 and 2008, attackers had a common modus operandi: scan a host for an open account, register a device (soft phone, another SIP trunk) and fire away thousands of calls. I have personally seen a company spend over a quarter of a million US dollars because of these attacks. Before I dive more into stats a bit, I will explain a bit about the financial loss for those who don’t think that it’s a big deal. I currently have a client who purchases a heavy amount of SIP trunks from my company, they in turn have a “Vonage” like business. Their customers buy an ATA, number, connect and place calls from Latin America. My client one day sends me an e-mail asking me if I would be willing to take a look at his network as his upstream was sending them abuse messages. Game on.

My client has approximately 20 servers in the continental US and 20 in Latin America. They were using a mixture of Asterisk and other equipment. What was happening to their servers was two-fold, attackers were leveraging VoIP accounts and placing thousands of calls. During the times when attacks took place, their bandwidth was so saturated that normal clients’ calls experienced horrible quality and drops. This led to loss of clients, enormous phone bills to places like Sierra Leone, Romania and the list goes on. To make a long story short, it took me approximately six weeks to clean up their shop as I could NOT take any of their servers offline. I essentially had to analyze what occurred, cut the bleeding, implement a fix and implement post remediation. Ultimately I programmed a distributed “cleaning” application to clean up accounts, create appropriate firewall rules, clean up backdoored binaries, implement an SIEM. This was another cost the client had to contend with. When I say over a quarter of a million dollars I am being very conservative. That was only the first instance of what occurred in their network, the second was, a few of their servers had become bots – but that is another story. Moving back into the statistics and trends of attackers I’ve seen, attackers are becoming smarter and the attacks seem more focused and targeted.

2009 – 2010’s Attackers trends

On a daily basis I see approximately six or seven attacks on each one of my Internet facing PBX’s, this estimate is based on solid numbers. The total amount of attacks divided by the amount of servers I have. While it may not seem like a big deal but the fact of the matter is, if one attack cost a company a quarter of a million in damages, the last thing I need to see is an attack on my company. Management’s first response would be “why didn’t you stop it.” The reality is, my company too was the victim of tollfraud via legacy VoIP accounts. We experienced 96 billable hours from our carrier to calls made to numbers in Sierra Leone. I know firsthand that these attackers are not “script kiddies” but focused fraudsters. Altogether during a highly volatile week, I can see approximately 150 – 200 attacks per day.

Previously (between 2007 – 2008) when I monitored the attacks, the attack phase was: “get an account, fire and forget,” whereas now, there seems to be less automation and more intervention. This is evident in the way attackers are placing calls. Here is an entry from today in my Arkeos database of an attacker coming from an address in Germany. Take note that I have sanitized data to keep the identity of my honeypot at bay:


# more peer-verbose-Mon-21-Sep-2009-11\:59\:34-AM-EDT.txt
 -- General --
           Name: SIP/300-b6b241c0
           Type: SIP
       UniqueID: 1253548774.7688
      Caller ID: 1xxxxxxxxxx
 Caller ID Name: xxxxxxxxxx
    DNID Digits: 16085541772
          State: Ring (4)
          Rings: 0
  NativeFormats: 0x2 (gsm)
    WriteFormat: 0x40 (slin)
     ReadFormat: 0x40 (slin)
 WriteTranscode: Yes
  ReadTranscode: Yes
1st File Descriptor: 39
      Frames in: 0
     Frames out: 0
 Time to Hangup: 0
   Elapsed Time: 0h0m0s
  Direct Bridge:
Indirect Bridge:
 --   PBX   --
        Context: xxxxxxxx
      Extension: xxxxxxxx
       Priority: 2
     Call Group: 0
   Pickup Group: 0
    Application: Dial
           Data: SIP/1xxxxxxxxxx
    Blocking in: ast_waitfor_nandfds
      Variables:

SYSTEMSTATUS=SUCCESS
SIPCALLID=146ef044580a3a795de94b541db21249@xxx.xxx.xxx.xxx
SIPUSERAGENT=Asterisk PBX
SIPDOMAIN=xxx.xxx.xxx.xxx
SIPURI=sip:300@85.214.85.180

  CDR Variables:
level 1: clid=xxxxxxxx
level 1: src=xxxxxxxx
level 1: dst=xxxxxxxx
level 1: dcontext=xxxxxxxx
level 1: channel=SIP/300-b6b241c0
level 1: dstchannel=SIP/xxxxxxxx
level 1: lastapp=Dial
level 1: lastdata=SIP/xxxxxxxx
level 1: start=2009-09-21 11:59:34
level 1: answer=2009-09-21 11:59:34
level 1: end=2009-09-21 11:59:34
level 1: duration=0
level 1: billsec=0
level 1: disposition=NO ANSWER
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1253548774.7688

So what occurred here? The who, what, where and how? The four most important variables are easy to parse:


How: Name: SIP/300-b6b241c0
Where: DNID Digits: 002314599711
What: SIPUSERAGENT=Asterisk PBX
Who: SIPURI=sip:300@85.214.85.180

How? An attacker leveraged a SIP account on the honeypot (username=300) Where? They tried dialing 16085541772 What? They likely tried trunking the SIP account to their Asterisk box Who? 85.214.85.180 So who owns the server? A company reselling hosting:


inetnum:        85.214.16.0 - 85.214.139.255
netname:        STRATO-RZG-DED2
descr:          Strato Rechenzentrum, Berlin
country:        DE
admin-c:        SRDS-RIPE
tech-c:         SRDS-RIPE
remarks:        ************************************************************
remarks:        * Please send abuse complaints to abuse-server@strato.de   *
remarks:        * or fax +49-30-88615-755 ONLY.                            *
remarks:        * Abuse reports to other e-mail addresses will be ignored. *
remarks:        ************************************************************
status:         ASSIGNED PA
mnt-by:         STRATO-RZG-MNT
source:         RIPE # Filtered

Wondering if this is spoofed (since some seem to think it is):


# nmap -sU -p 5060 85.214.85.180

Interesting ports on server1.stacheshof.de (85.214.85.180):
PORT     STATE         SERVICE
5060/udp open|filtered sip

Nmap finished: 1 IP address (1 host up) scanned in 1.755 seconds

Likely not spoofed however, this does not stop someone from compromising a host and using it to do other things. The likelihood of this server being compromised AND running a PBX on it is low and here is my reasoning for this comment, I’ve seen this address quite a few times connecting to different addresses during different months. I would think a server’s administrator would notice a PBX server running on their system. What makes things even more interesting is the following, the attacker tries to make one call, then starts changing his (or her) dialing patterns:


002314599711 - 20100921-11:41:33
92314599711 - 20100921-11:47:42
9002314599711 - 20100921-11:54:31
90112314599711 - 20100921-12:00:29

The calls were placed at odd times to make me think they were automated. The first call was at 11:41 followed by six minute gap, followed by a 7 minute gap, followed by another 6 minute gap. In previous times, automation was instant. Even odder is, how is this person aware that a call didn’t go through and that they should be changing the dial plan? My response is, they have some form of visibility into that destination number. Calls from my honeypot sound just as any other call with the exception they all end up in one place. Voicemail to a non-existent account. This further allows me to hear the audio if any is left.

After accumulating all of this data, I figured it would be best to share it with others in the industry via the “VoIP Abuse Project.” The purpose of the project is to create a blacklist of sorts for any engineer or admin to be able to use to block out the bad guys. Alongside blocking out the bad guys, it always offers a place to showcase the realities of “abuse desks” of companies whose networks are being used in attacks. That goal too is simple, systems are attacked and reported, companies responding and correcting issues should be applauded, companies ignoring the issue should know that it will only be a matter of time before their clients cost them more in lost revenue. It’s their networks, they should be more responsible about what leaves their network. Anyhow, this has become rather long so I will leave this as a part one. Stay tuned for more.

VoIP Fraudster Edwin Pena sentenced to 10 years in prison and repayment of $1 million

Bringing closure to a case we’ve been following literally for years since it was first reported way back in June 2006, fraudster Edwin Pena was sentenced last Friday to 10 years in prison and ordered to repay the $1 million in restitution.  It appears he also won’t be in the US after he serves his time:

In addition to his 120-month prison sentence, Pena was ordered to pay restitution of a little more than $1m. He will also be deported once he completes his time. Pena has already surrendered a large number of luxury items that were purchased using the ill-gotten profits, including a 40-foot motor boat and a 2004 BMW M3.

Back in February 2010, Pena pled guilty and provided some details into what he had done. This previous blog post provides links to additional parts of the story.

Nice to see this finally end…

If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.

Weaponizing the Nokia N900 – Part 2

Welcome to the 2nd post in my series of leveraging the power of the Nokia N900 handheld using opensource, cutting-edge security tools for ethical penetration testing.

In keeping with the theme, the idea is to cover security-related tools and applications that enhance the N900’s offensive capability.  Recall the initial focus is on tools that are available, easy to install and require low technical expertise — that is, expertise in terms of installation, not actually running the tools in a network attack scenario. You’ll have to learn that on your own, and IronGeek is a great place to start.

As the blog series progresses, I’ll cover more unique tools and cutting-edge stuff,  I’m still working with a production phone that I can’t risk ‘bricking’ — however, if anyone’s interested in supporting advanced security tool support and research on the Nokia N900 platform and seeing the results posted here on infosecisland, please drop me a note offline.

NeoPwn Update — BETA versions leaked, possible malicious modification

In Weaponizing the Nokia N900 – Part 1, I mentioned the upcoming release of NeoPwn, a software image designed specifically for the Nokia N900.  The software is still unreleased, but there’s been a BETA test going on.  Unfortunately, someone in the BETA program has re-released the BETA into the wild, and quite possibly did some malicious modifications.

A warning, if you’re trying to go trolling around the Torrent sites or RapidShare for this leaked NeoPwn image, I’d suggest you re-think that strategy.  Not only will you possibly get a bad, or trojaned image, but you’ll also drain support from cool projects like NeoPwn — I think that specialized projects like this that take alot of time should be supported, and it’s worth paying for this kind of effort.

Oh, and bonus points for locating and publishing analysis of a trojaned N900 NeoPwn BETA image!

Easy Debian with LXDE

Easy Debian on the Nokia N900 is super-easy to install, well-documented, and provides you with a full desktop environment that is separate from the underlying OS.  Here’s a nice 8-minute video on Easy Debian on the N900, and to get you started, there’s great documentation on the Maemo Wiki.

Basically, you can install Easy Debian LXDE using the GUI application manager.  It’s a snap, and easy to back out of if you want to. With this package you get a full Linux distro that runs on top of the N900’s native OS — think of it as similar to running a VMware appliance image on a host.

Once you have Easy Debian and LXDE installed, you can begin to add the kinds of security tools  that would typically install on a full-fledged desktop!  Think a full version of Nessus, both client and server, running on the N900 in LXDE.

It’s totally doable, albeit these packages can be a bit of a drain on the CPU and memory — that is, it’s workable, but don’t expect snappy and fast.  Still, running the Nessus client and/or daemon on this device is a useful feature — serious security tools like Nessus running on a compact phone-sized device open awesome possibilities for covert testing in on-site ethical penetration testing engagements.

If you’re contemplating adding several security tools for the N900, definitely look into adding the Easy Debian LXDE package.  Overall, it makes life much easier and enables you to play around with a full OS without modifying the base OS on the phone.

There’s potential here for custom LXDE images for the N900 as well.  Could be an interesting project…

It’s noteworthy that from a law-enforcement forensics standpoint, the N900 presents an advanced challenge.  If LEA are going after more than the removable SIM, the “virtual image” Easy Dedian LXDE capability makes it more of a challenge for airport cell phone siezures and subsequent analysis.

The potential for running LXDE with an encrypted filesystem will add to this forensics challenge in the future.  On the flip side, it’s also a useful privacy enhancement, and can aid in the unwanted intrusion into private data.

LiveCast Mobile for N900 — Poor Man’s James Bond Espionage Tool?

It’s worthwhile to cover several applications that can turn the N900 into a powerful multimedia broadcasting device — or in terms of espionage a “corporate green killer, bean spiller” as Boots from “The Coup” might say.  I’m going to only focus on one for now, and will expand on others that are worthy in future posts.

By far the scariest I’ve seen so far is the Livecast Mobile.  This app will allow you to stream to a webserver live audio and video from the N900.  What’s interesting is you can set either of the two cameras on the N900 — while front camera’s red LED is illuminated when the software is running, there’s no indication if the front camera is used, which has lower resolution, but is much more covert.

Speaking from personal experience, it’s a bit unnerving to fire this app up, leave the N900 on a table, go to another room, go to a Livecast webpage and see live video and hear live audio from this phone — going out to the Interwebs — to the Livecast servers — back to my PC browser.  Yikes.

Think about that next time you’re in a highly confidential meeting and a N900 (or any of several phones) are lying on the table, or “forgotten” on a chair or end-table.  For that matter, anyone check above the ceiling in the plenum in your company’s corporate boardroom lately? 🙂

All kidding aside, clearly, there are a number of legal issues with using this kind of application, so be aware of the risks and liabilities.

Coming Up Next…

Some of the things I’m going to focus on in upcoming articles for the “Weaponizing the Nokia N900” series includes:

  • More scary applications for poor man’s espionage
  • Using the Nokia 900 for wireless attacks, including WEP/WPA capture and cracking, packet injection, Kismet on the N900, etc.
  • FakeAP and Karma type attacks — turning the N900 into a rouge AP that does MITM, etc.
  • USB Ethernet to add a third data interface (wifi, cellular, US)