Category Archives: Security

Dark Clouds: Can you trust the Cloud? Panel on Feb 4th at Cloud Communications Summit in Miami

CloudCommunicationsSummit __ Agenda.jpgCan you trust “the cloud” to be there for communications? What about latency issues? availability? What should you be most concerned about?

Those are issues that I (Dan York) will be discussing on a panel on Friday, Feb 4, 2011, at the Cloud Communications Summit in South Beach, Miami. The abstract is:

There’s a general consensus that Cloud Communications improves the bottom line while reducing both financial and technology risks. What about from a security perspective? This session identifies the differences between premise based and cloud based offerings from a security perspective, and provides the audience with a checklist of what to worry about as they move into the cloud. This session is appropriate for both business and technologists.

I’ll be on the panel along with folks from Rackspace, Pac-West and Path Solutions and the whole session will be moderated by analyst Dave Michels. It should be a fun discussion… if you are down in Miami, do come and join us!

GSM Encryption Cracked – Eavesdropping Now Possible

Last Friday there was news out of the Chaos Computer Club Congress in Berlin that two security researchers, Karsten Nohl and Sylvian Munaut, had successfully cracked the encryption used in the GSM cellular network. While not “VoIP”, per se, this is of interest to any of us working with VoIP as many VoIP clients are now working on “smartphones” running on top of the GSM network (like, oh, the iPhone, among others). Some of the articles on this topic:

The researchers are apparently not releasing their toolkit publicly, but obviously word of their success will encourage others to investigate further.


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


WikiLeaks as a Preview of All-Out Cyberwar, Part 2 – The Escalation

Updating twothree points from my post last week, WikiLeaks as a Preview of All-Out Cyberwar. I wrote:

On the opposite site, you have the WikiLeaks organization itself moving its content to various places and among various providers… desperately seeking a way to keep itself online. But even more you have supporters of WikiLeaks downloading all the content and popping up mirror sites all over the place, trying to keep the organization’s content out there. The distributed and decentralized nature of the Internet allows easily for this type of content propagation.

Through the WikiLeaks Twitter page, they have been reporting the growth in mirror sites, most recently 507 mirrors. (Note the reported checkbox for new mirror sites.) Which, of course, provides a nice hit list to those who want to shut it down…

And every new site or domain name that pops up with WikiLeaks content becomes yet another target for those wishing to knock the organization offline.

… such as the report today that the WikiLeaks servers in Sweden are under attack.

And undoubtedly there are supporters of WikiLeaks out there who are trying to counter-attack the attackers.

UPDATE, 2 hours later: I noticed this in a NY Times piece yesterday: The collective Anonymous, an informal but notorious group of hackers and activists, also declared war on Sunday against enemies of Mr. Assange, calling on supporters to attack sites companies that do not support WikiLeaks and to spread the leaked material online.

As I wrote last week:

I think it will get uglier before it’s all over.

Indeed, TechCrunch wonders how long the @wikileaks Twitter account will stay around

WikiLeaks as a Preview of All-Out Cyberwar

WikiLeaks.jpgAs a network security professional, the ongoing WikiLeaks saga certainly is quite concerning. I am not referring to the exposure of documents – but rather the all-out effort to completely wipe WikiLeaks off the Internet… and what that means for your business and your connectivity to the Internet.

I’m NOT talking here about the politics of the WikiLeaks situation. A significant number of you reading this will probably believe that WikiLeaks is an extreme terrorist organization that should be eliminated from the network and the leaders should be hunted down and imprisoned (or worse). And a significant number of you reading this will probably believe that WikiLeaks is a champion of transparency and openness and a leader in fighting against government censorship and secrecy and needs to be supported by all means possible.

Put the politics aside for a moment and think about WikiLeaks in terms of:

an entity that many organizations around the world want to eliminate from the Internet.

Consider the attacks they have been under:

  • Multiple reports of large-scale distributed denial-of-service attacks
  • Being kicked off of multiple hosting providers, including Amazon Web Services
  • Most recently, having the wikileaks.org domain name removed from DNS

and undoubtedly many other forms of attacks…

The Guardian in the UK had a good article up today on the issue:

WikiLeaks fights to stay online after US company withdraws domain name

I definitely understand the difficult decision EveryDNS.net faced (and in full disclosure, I do personally use their free service for some dynamic DNS domains). I know a couple of the folks there, and as they state in the notice on their home page:

More specifically, the services were terminated for violation of the provision which states that “Member shall not interfere with another Member’s use and enjoyment of the Service or another entity’s use and enjoyment of similar services.” The interference at issues arises from the fact that wikileaks.org has become the target of multiple distributed denial of service (DDOS) attacks. These attacks have, and future attacks would, threaten the stability of the EveryDNS.net infrastructure, which enables access to almost 500,000 other websites.

You are a provider of a free domain name service … and suddenly one of those 500,000+ domains comes under extreme attack to such a degree that it could endanger the accessibility for everyone. Though I am sure that the EveryDNS folks will be vilified by some (and probably attacked) and praised by others, as a network and security professional I can understand why they made the choice they did. At some point, there is a need to protect and preserve your own infrastructure and connectivity. They can’t stay in business if they don’t.

But reading that Guardian article and all the other ongoing coverage, I can’t help but think:

We are witnessing a preview of true cyber-war.

Beyond the public pressure from various senators and government officials around the world to shut down WikiLeaks and encourage companies to sever ties, you have to wonder if various intelligence and/or military agencies with different governments aren’t actively trying to shut them down online. Add in all the private groups clamoring for a shut-down… you have to think some of them are engaged in electronic activity. And add in all the individuals out there trying to do their part to shut down WikiLeaks.

How many botnets are probably active right now trying to execute DDoS’ against WikiLeaks?

On the opposite site, you have the WikiLeaks organization itself moving its content to various places and among various providers… desperately seeking a way to keep itself online. But even more you have supporters of WikiLeaks downloading all the content and popping up mirror sites all over the place, trying to keep the organization’s content out there. The distributed and decentralized nature of the Internet allows easily for this type of content propagation.

And every new site or domain name that pops up with WikiLeaks content becomes yet another target for those wishing to knock the organization offline. And undoubtedly there are supporters of WikiLeaks out there who are trying to counter-attack the attackers.

I think it will get uglier before it’s all over.

For us in the security community, there is much to think about:

  • Where are your services hosted on the Internet? How well do you know those providers? And how solid and redundant are their services?
  • Could your sites become “collateral damage” and be knocked off the ‘Net if some other site hosted at a provider came under attack?
  • Where are the single points-of-failure (SPOFs) in your hosting and Internet connectivity?
  • Where are your domain names hosted? What if the DNS provider came under attack?
  • Do you have alternative domains available? Perhaps through a completely different DNS provider and able to be pointed to a completely different hosting provider?
  • What are the Time-To-Live (TTL) values set for your primary domain names? If one provider was knocked out, how quickly could you repoint those domains to another site?
  • And if you are hosting your own services, what levels of protection do you have in place? What kind of redundant connections do you have?
  • What ability do you have to rapidly move your connectivity (and content) to another site?
  • etc., etc.

Bringing this to a VoIP and communications context, if you are using IP-based systems for real-time communications, is your architecture robust enough to withstand attacks? (whether or not those attacks are targeted at you or at others connected near you?) Can you answer those questions above for your real-time communications system? Where are your SPOFs? What are your backup plans? How will you stay online and connected in the face of an overwhelming attack?

This particular saga of WikiLeaks will play out in the days, weeks and months ahead… and whether they stay online or are forced offline remains to be seen… but what we’re publicly witnessing right now is a case study of the time ahead of us.

Are you prepared?


Dan York, CISSP, is chair of the VoIP Security Alliance, author of “Seven Deadliest Unified Communications Attacks” and a frequent speaker on communication security issues.


Slides: SIP, UC and Security Talk at ITEXPO in October 2010

Back on October 4, 2010, I spoke at Ingate Systems “SIP Trunking and Unified Communications” section of TMC’s ITEXPO event in Los Angeles. I gave an overall summary of issues around VoIP/UC security and then joined a large panel of others answering questions from the moderator and the audience. The slides I used are now available online from my SlideShare account:

ISC2 Blog on Security Issues

isc2.jpgGiven that I hold a CISSP certification, I naturally remain connected to the Information Systems Security Certification Consortium (ISC2) organization in order to maintain my credentials. I hadn’t paid much attention to the actual website for a while and only recently noted that there is a ISC2 blog and it’s been updated periodically for a while now:

http://blog.isc2.org/

Some of you may find it a useful resource. The ISC2 also is on Twitter, of course. 🙂


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


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.

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.

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.

Revisiting Shodan Computer Search Engine: Oh Noes, the places you’ll go!

I’m sorry to say so
But, sadly it’s true
That bang-ups and hang-ups
Can happen to you

— Dr. Seuss, "Oh, the places you’ll go!" (1990)

Back in January 2010, I wrote a short blog post about Shodan and VoIP devices and mentioned that it’s a site well worth revisiting.  Well, that time has come, and there’s plenty more to talk about when it comes to Shodan.

What is Shodan?

It is a publicly available, searchable database of pre-scanned networked devices.  The scanning includes banner results from common services like telnet and http, and is akin to fingerprinting.  One way to look at it is like Rainbow Tables for networked devices.

What’s the risk?

When a new vulnerability is discovered, Shodan makes it easy for attackers to search for vulnerable devices without actively scanning.  For example, say a vulnerability is published about Apache Mod_Security — an attacker can easily search Shodan for vulnerable version and then launch an attack to pwn the box.

Attackers can also use Shodan search filters and really narrow down search results, by country code or CIDR netblock for example.  You do have to register for more specific search functionality if you’re interested in say, the 24 Cisco boxes in Iran with no authentication.

Pssst….wanna Pwn 7000 Cisco routers/switches?

Yes you can.  And only because some network admin didn’t know how to configure HTTP authentication.  It’s easy peasy with Shodan’s most popular search.  Click on the resulting IP addresses from that search and you’ll get the HTTP interface of a Cisco router/switch with no authentication.  Add "/level/15/exec/-/sh/run/CR" to the IP address and you’ll get the "show running configuration" output of the device.  Understand what’s going on here.  An attacker can easily add an admin-level account, change the configuration, crack the listed Cisco passwords in the configuration to target other devices on that network, etc. 

Why should I care?

Shodan creates risk by making poor configurations and other adminstrator mistakes much more visible to potential attackers.  It also creates risk by providing a pre-scanned inventory of potential targets.  I’ve seen some amazingly frightning devices discovered through Shodan that are wide open and have no authentication — for a few examples:

  • An Eastern European country’s SCADA water treatment network
  • A switch controlling the Neurosurgery VLANs of a hospital
  • Physical security door access controller systems
  • Routers with VoIP configurations
  • and plenty more….

These are just a few examples of the micro-risks.  I think from a macro-risk perspective, specifically concerning the Cisco routers with no authentication, is the very possible and easy mass takeover of routers and potential for BGP attacks.  Not possible?  Well, think back to early 2008 when Pakistan modified BGP routes to block YouTube and because of a misconfiguration, large swaths of the Internet outside of Pakistan could not access the site. This was the result of a error from a few routers broadcasting bad BGP routes — now imagine if an attacker does this with a few thousand routers distributed globally?  I think it’s really only a matter of time…

What should I do?

There are tangible steps you can take.  First and foremost if to register fora free Shodan account and search for devices on your organization’s CIDR netblock.  If you are working with buisness partners that are connected to you, check their CIDR netblocks in Shodan as well.  Make a stink and inform the right network and security people of the risks of Shodan exposure.

Or

You can do nothing, and let Shodan determine your fate.  Your choice.