Voice of VOIPSA » VoIP Security

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

Shawn Merdinger — Thu, 26 Aug 2010 18:32:11 +0000

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.

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

Risks Of Phone Removal From University Dorm Rooms

Shawn Merdinger — Wed, 11 Aug 2010 14:33:52 +0000

Risk: A Growing And Disturbing Trend

Today the Washington Post and WSJ Blog both reported on a decision by the University of Virgina Housing Division to remove phones from student dorm rooms. The obvious justification for the decision is the cost associated with providing phone infrastructure residence halls, in UVa’s case over 500K annually.

I can understand the financial predicament many universities find themselves in today’s economy, and clearly students in general are more frequently choosing mobile communications. Further, it’s noted in the articles that the university intends to provide dedicated phones in the hallways for emergency calls.

Still, I suggest this elimination of dorm phones is going to result in increased risk to students and residence hall staff. For what it’s worth, I speak from 6 years of experience as a former resident assistant and hall director in residence halls at large public universities. While this was several years ago, and before the widespread use of cellular phones on campus, the technical and social impact of losing dorm landlines raises several troubling issues.

Risk: Cellular versus Landline Reliability

First and foremost, having hardline phones in individuals’ dorm rooms provides a constant, always-available, and above all, reliable phone connection. With the network and cellular connection problems we all constantly experience, which by-the-way we’ve have little insight into the reasons for years, having the peace-of-mind of a reliable hardline should not be dismissed lightly. If you were starting a business with a office, would you rely soley on a cellular phone? What would be your reaction if you checked into a hotel and there was no phone?

Risk: Emergency Location (e911) Issues

If you have children at home, would you choose not to have a landline? Probably not, even if you provide them with mobile phones. You might say this is not a fair question in the context of college students, of whom most are technically adults over age 18. I’ll counter this with the fact that a typical dorm has students from all over the country and world together in a close-quarter living environment. As any residential life staff can tell you, the potential for conflict outbreaks of all kinds and levels is a constant threat, and it’s important to remember that these students come from a variety of backgrounds and all have their problems and issues that become magnified in a close-quarter living environment.

From my own experiences as residence hall staff, I’ve handled everything from common roommate conflicts, breaking-up floor parties, suicidal residents, theft/vandalism, residents unconscious from alcohol/drugs, weapons, physical fights, etc. In every case, having a phone nearby proved invaluable.

Perhaps an even more important point, on one university campus we had e911 which provided the emergency operator the actual room location from where the phone call was made. On another campus we did not have that feature, and precious time was lost in the task of determining the call location — in fact, several instances of students dialing 9-911 resulted in them accessing off-campus emergency personnel, resulting the in the time-loss of transferring the call back to campus emergency resources. And this was the case of landline phones in all rooms — we can expect more confusion as these calls will now go over cellular networks.

While the location capabilities of many cellular phones and e911 is available, the difficulty in pinpointing location should not be overlooked. Aside from the network congestion and coverage issues I alluded to earlier, in many residence hall situations the building is a multi-story residence. Expecting cellular e911 to provide emergency responders accuracy to the floor and room is unrealistic in the best of circumstances. The impact of this is going to be more confusion and lost time in responding to residence hall emergency calls made over cellular.

Risk: Losing A Known Point of Contact

An overlooked benefit of landlines is that one knows the actual location one is calling (assuming call-forwarding, etc. is not in play). In the case of dorm rooms, residence hall staff have a listing of all room phone numbers. Many, many times I’ve used this list to initiate contact with a dorm resident, from trying to determine if someone was in the room without having knocking on the door, following-up with a sick resident or a resident with a disability, or tactically approaching a room party by talking one-on-one with the room’s resident rather than facing a room party and hostile audience in the doorway.

The removal of individual room phones means the loss of a valuable tool in residence hall staff’s toolkit. The ability to initiate contact over the phone to a known room should not be discarded lightly, and the loss of these phones means residence halls staff are losing a tactical advantage.

In the case of roommate and other domestic conflicts, several times I’ve seen a fight escalate to the point where one of the parties called 911. In some cases, the resident hung-up the phone immediately, before stating the issue to the emergency operator. Of course, since the call was made from a room landline, and state law required the emergency response to the call location, soon after the university police would arrive at the room. Often this resulted in the arrest, or referral to student affairs, or the people involved, which lead to them getting assistance. With cellular phones, this response is impaired greatly, and I fear that escalating situations will not reap the benefits of current landline and police response capabilities.

There are some potential loss of privacy issues for dorm residents here as well. In the case of most landlines, one can more easily choose to block their outgoing caller-id, a useful feature if a dorm resident is calling a crisis line or making inquiries on a subject they wish to remain anonymous. The ability to do this in private, from ones room, is critical; the common-area landlines in the halls are not going to provide this physical privacy, and given the location of the phones it would not surprise me if the ability to block outgoing caller-id is disabled. Why? Because I expect the amount of crank calling from common area phones in dorms will increase by orders of magnitude…

No Easy Answers

Unfortunately there is no easy solution to this dire situation. Universities, especially in the public sector, are forced to make cost cuts in this poor economy, and telecommunications overhead like dorm phones is a easy measure to take, but the increased risk and costs are at this point not worth it. The replacement technologies, such as relying on student’s to have cellular phones, or even VoIP phones replacing landlines in dorm rooms, still lack the same robustness in emergency response features that we’ve relied upon on grown accustomed to over the years. Still, like it or not, the removal of dorm phones is a trend gaining in popularity and we’re only going to see more campuses choosing this path. To this end, some recommendations I have are:

Ensure that student’, and their parents, are made aware of the issues and risks of not having a landline, as well as the benefits
Prioritize cellular e911 location tracking on college campuses
Require residents with disabilities to have a landline
Provide residence hall staff with resident’s cellular numbers
Provide a privacy booth for landline phones placed in common areas to enable students to make calls with some level of privacy and caller-id blocking

Weaponizing the Nokia N900 – Part 1

Shawn Merdinger — Thu, 22 Jul 2010 16:32:03 +0000

In the 80s movie “The Color of Money” there’s a great scene where a player challenges Tom Cruise’s character to a game. He strolls up to Vincent and says “So what you got in there?” — to which Vincent replies. “Doom.”

This is akin to how I felt a few weeks ago after I finally got ahold of a Nokia N900 smartphone. Calling it a phone is a bit of a stretch, as it is primarily a Debian Linux tablet with impressive hardware specs and a huge number of .deb packages available for installation…oh, and you can make cellular phone calls with it. Many people use this phone, and despite some glitches it is rapidly developing into a formidable platform for security tools and penetration testing.

Broadly speaking, the objective of this series of blog posts is to introduce folks to the tools available and the potential for this phone as a security testing platform. Given the fact I’m a bit late in obtaining this phone, some smart people out there have already started to address the n900′s capabilities and available tools, and I would be remiss not to mention, and build upon, their insightful work. The key phrase here is “build upon” and get the word out, not to steal or simply re-hash their fine work and efforts!

I’ve one caveat to this series of blog posts. As my n900 is for now a “production phone” for me in that I need to use it and can’t brick it just yet, the path of this blog series on “Weaponizing the Nokia N900″ will progress from known, tested and functioning security tools on this phone — and therefore lower risk of bricking — to more advanced, edgy tools that require more tweaks and modifications, such as replacing the stock kernel. If someone out there finds this series useful, and has interest in furthering research on running security tools on the n900, I’d welcome the donation of a n900 for development and testing, and would credit them for their support. Please ping me offline if you’re interested

NeoPwn and the Nokia N900

One project to watch in particular is the upcoming release of NeoPwn, which is based on BackTrack and bills itself as the “First Ever Network Auditing Distribution for a Mobile Phone Platform” and is due for release sometime this month, hopefully before DefCon. I am fortunate to be in the BETA and will write up a blog post for this series on NeoPwn once I get full access to the NeoPwn toolset.

Worthy Resources on Nokia n900 Security Tools

1. Metasploit on the Nokia n900. ‘Nuff said.

2. knownokia.ca Blog SimonLR wrote an excellent post on “Using the N900 for Fun and Profit” that covers several awesome tools, such as Metasploit, Dsniff, SSLstrip, Aircrack-NG, etc. He’s clearly savvy and his future blogging on tools for the n900 will be great to see.

3. Asterisk on the n900

When I added the extra package repositories to my n900, I was more than a bit surprised to see a full version of Asterisk available as a .deb package. Wow. Think about this for a moment. One can run a full Asterisk server on a phone in their pocket. The capability of Asterisk on the n900 could enable attackers to do all sorts of mischief, such as running the SPITTER tool from their pocket as a simple example. From a surveillance aspect, think of “bad people” with n900s in their pockets running Asterisk servers on their phones and connecting to each other point-to-point over encrypted tunnels — now that’s a challenge.

Stay tuned for more posts on “Weaponizing the Nokia N900″

Unified Communications Security Presentation at SpeechTEK NY, Aug 2nd

Dan York — Thu, 15 Jul 2010 15:33:14 +0000

If any of you will be at the SpeechTEK conference in New York August 2-4, I’ll be there and giving a presentation on Monday, August 2nd, at 4:15 about Unified Communications security. The panel abstract is:

As applications move into the multichannel and interconnected world, what are the security concerns you need to consider? Aaron Fisher enumerates the best practices for information security with speech applications and the benefits of tuning in a secure environment. Dan York, author of the bestselling book The Seven Deadliest Unified Communication Attacks, will discuss the major risk areas of unified communications, what steps you can take to mitigate/reduce those risks, a checklist of questions to consider in your implementation, and a look at the future in an increasingly interconnected and converged network.

I’ll be naturally covering some of the topics in my book and talking about overall communication security, VoIP security, cloud security, etc. Not sure if I’ll be able to make a recording of it available later, but will do so if I can. If you are going to be at the show, please do say hello. (More info on what I’m doing on the show can be found here.)

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

Facetime, Apple, and VoIP

Jason Ostrom — Fri, 09 Jul 2010 17:53:09 +0000

Very interesting news: Apple’s new iPhone4 application, Facetime, is a VoIP and IP Video application using SIP signaling and RTP media. Security researcher and SANS Instructor Josh Wright has posted a very interesting and detailed analysis of the Facetime application on Packetstan, a new blog developed by his other SANS and InGuardians colleagues . A couple of quick summary points from Josh’s analysis and a quick look at the phone that we have done thus far:

iPhone Facetime client doesn’t use SIP REGISTER for authentication
Uses STUN for NAT Traversal and resolving the remote callee and called party’s IP address of each iPhone
After the remote party’s IP address has been resolved, SIP INVITE and MESSAGE packets are exchanged directly between iPhone devices
Cleartext SIP and RTP
RTP video appears to use the H.264 video codec, and audio appears to use the AAC-LD codec (the same audio codec used in Cisco TelePresence).
FaceTime uses XMPP to authenticate each iPhone to an Apple Jabber server, using TLS and mutual certificate authentication.

Josh and I were discussing this the other day because he was trying to use the ‘VideoSnarf’ tool in order to re-construct the H.264 encoded media packets. The codec does appear to be H.264, but with some slightly modified reserved fields. Right now this isn’t working, but we hope to have an updated version of VideoSnarf working together with Facetime traffic in the near future.

This is so interesting because it is the first SIP client on a widely deployed consumer Smartphone device developed and supported by a vendor such as Apple. I think it signals that we are going to see more of these applications – these are exciting times. It will be interesting to see how other vendors follow up soon with 2-camera video clients on Smartphones using VoIP protocols, taking the lead from Apple. I am sure many others will be taking a closer look at Facetime, and the attack surface area here for potential exposures are very interesting, as well as the potential security measures that can be applied in order to protect Facetime traffic.

More on Telephony Denial of Service (TDoS) Attacks

Mark Collier — Wed, 07 Jul 2010 22:56:19 +0000

I assume most everyone has seen the FBI press release on Telephony Denial of Service (TDoS). For those who have not, see:

http://newark.fbi.gov/pressrel/pressrel10/nk051110.htm

I am also seeing the term used to describe enterprise-directed DoS, where an attacker typically floods a contact center with calls. I have recently worked with both enterprises, service providers, and hosted IVR companies that have seen these attacks. The current motive seems to be traffic pumping/revenue generation, not DoS per se, but the side impact is that operation at the target sites is degraded or seriously disrupted, depending on call volume and trunk capacity. Interestingly, the targets I have talked to are primarily using TDM trunks, while the attackers (according to the service providers I have talked to) are using VoIP. I have a post on my blog with more information:

http://voipsecurityblog.typepad.com/marks_voip_security_blog/2010/06/more-on-telephony-dos-tdos.html

Is anyone else seeing these attacks?

Linux crash on a Plane!

Shawn Merdinger — Mon, 07 Jun 2010 17:33:28 +0000

I don’t travel nearly as as much as I used to, yet when I do I always keep a sharp eye out for the technical glitches in devices around me in travel environments. What can I say? It provides me endless amusement.

While Linux boxes crashing in airlines’ on-board entertainment systems are nothing new, and several photos exist on the Internet depicting these crashes, I’m seeing something different these days…

On my way back from ph-neutral security conference in Berlin, I took a Continental 757 back to the US and observed the passenger entertainment system headrest in the row in front of me was frozen on the the movie selection GUI. The passenger in that seat asked the flight attendant to fix the problem and the headrest PC was rebooted from somewhere up front.

So, the funny (and a bit scary perhaps) bit is the screenshot I took of the reboot process. You can see the very high resolution photo here: http://tinyurl.com/linuxonplane

Observations from the linux crash on a plane photo:

1. 172.17.X.X private IP address range

2. FTP server IP address and transfer of system log tarball to the FTP server…user is “xxxxx” — imagine what the password might be…

Some reasonable concerns:

1. Tilting up the headrest PC and peeking behind it I saw CAT-5 cable. With a small tool or hands, and big cajones, an attacker *could possibly* unplug that cable and attach it to a laptop and hop onto the entertainment network. In addition, with some imagination and the right tools, an attacker could feasibly take over some or all aspects of the headrest PCs, including perhaps the sniffing of credit cards used by patrons, or even adding some specialized content…

2. This aircraft did not have on-board wireless Internet access, but I suspect that some airlines offering this service could have network crossover connectivity to different subnets, or perhaps only relying on VLANs for separation.

In the end, we can only hope that of the several networks likely running on a modern passenger jet, that true air-gapping is taking place and these systems are in no way connected to critical on-board networks. Time will tell if this is indeed the case. In the meantime, keep an eye out for those Linux boxes crashing on planes!

New Book: Seven Deadliest Unified Communications Attacks

Dan York — Thu, 20 May 2010 14:25:33 +0000

As some readers may already know, Syngress has now published a book I wrote, “Seven Deadliest Unified Communications Attacks” that dives into the threats to communications systems and the strategies to protect your systems. It is part of a series of “Seven Deadliest Attacks” books that have come out over the past couple of months. (And yes, there are seven books in the series.)

As I explained in this video, my intent was not so much to write a book about “VoIP security” but rather to take a look at a slightly larger level at the overall systems that we are connecting together under the name of “unified communications”. When we have voice, video, instant messaging, presence… coming from multiple different systems and then distributed over the global IP network… how do you secure it all?

The book was really my attempt to put in print form many of the themes we have written about on this site, talked about on the Blue Box Podcast and discussed in the VOIPSEC mailing list.

I do want to thank a couple of people in the VOIPSA circles… as I noted in the Acknowledgements, Dustin D. Trammell was an outstanding technical editor – and Andy Zmolek provided some excellent comments and thoughts. Longtime friend and VOIPSA blog contributor Martyn Davies had some helpful feedback, too, as did Scott Beer over at Ingate Systems.

Anyway, the book is out there… and I’ve put up a companion web site at www.7ducattacks.com where I’ll be listing additional resources, errata, updates, etc. There is also a Facebook page for the book. Feedback is definitely welcome (and yeah, I wouldn’t be opposed if you bought a copy or two ). I’m doing some interviews and podcasts about the book… if you are interested in interviewing me for your site or show, please contact me.

My hope with the book is that in some small way it can help encourage and spread the discussions we all have been having here… and in the end help our communications systems be a bit more secure. Thanks to all of you who have been reading posts here, commenting on them, participating in VOIPSEC and asking great questions.

P.S. If you are available tomorrow, Friday, May 20th, at 1pm US Eastern time, I’ll be interviewed live on the VoIP Users Conference call. Anyone is welcome to join in, listen, and ask questions.

Attacking the Crown Jewels through VoIP

Jason Ostrom — Tue, 18 May 2010 19:06:04 +0000

The security weaknesses of VLANs have been known for years. Recent case studies have highlighted the potential risk of using Voice VLANs together with VoIP in an infrastructure absent of properly configured security controls. While visiting Europe just recently, I was reminded of this issue for a couple of reasons.

The British Crown Jewels

Firstly, I saw the magnificent British Crown Jewels in display. They are quite impressive. They are arguably the most valuable items in the world possessed by a sovereign state, and obviously need to be properly protected. It really got me thinking about the origin of the term “Crown Jewels” and how the industry has used this term to refer to protection of a company’s most valuable and precious IT assets and data. We talk about protecting against the theft of these “Crown Jewels” – a company’s IP, trade secrets, or other mission critical data. How to protect and defend the “Crown Jewels”?

Theft of the Crown Jewels!

Hotel VoIP Deployments

After seeing the Cullinan I diamond and other precious jewels, I stayed in a hotel in Stockholm that had IP Phones deployed in guest rooms, which had me thinking again about how attackers could access a company’s IT “Jewels” from a physically unsecured area. A quick and passive view of the IP Phone network configuration showed that this network was most likely vulnerable to the aforementioned VLAN Hop vulnerability. I’ve been seeing an increasing amount of Hotel VoIP deployments in the last year exactly like this.

Both of these items reminded me of how easy it is for a would-be attacker, sitting in the comfort and privacy of their hotel room, to steal a company’s most valuable trade secrets and data through VoIP, in the right scenario and when the environment is not properly protected. We’ve seen this before in production environments, in authorized security assessments. I wanted to reach out to the community and share this with you, and see what others are seeing as well. I’ve roughly seen 1 in 3 hotels in the past year have VoIP deployed in the guest rooms. I am curious as to whether others are seeing a similar trend. What other UC business applications are you seeing deployed in physically remote areas, and how are they being used?

Trunking VoIP to Physically Isolated Areas

When VoIP networks are propagated through trunk ports to physically isolated remote locations that are still under the administrative domain of the same organization, the risk increases that a VLAN Hop into the Voice VLAN can result in unauthorized access to corporate network resources. Resources that were not intended by the system designers. I’m making generalizations because every network is different. But the most common configuration I am seeing takes place because the IP Phones normally need a range of TCP/UCP ports open into the call servers, and the call servers are centrally hosted on the corporate data network. Sometimes the firewall doesn’t properly implement the policy of least privilege for only permitting operational IP Phone traffic and denying all other traffic. The best example of a physically remote location that comes to mind is a Hotel room, but I’m sure there are other good examples. Hotel VoIP deployments with wired ethernet offer benefits to the user such as guest VLAN Internet access from the PC port of the IP Phone. But if you think about it, it offers the perfect backdoor attack vector into the internal network. Privacy and seclusion. An attacker can spend as much time as they please, evading detection and slowly discovering the network. Each time I see this, it makes me wonder the extent to which this vulnerability is getting exploited in real life, but not being publicly disclosed. We’ve seen how well publicized CHD / data breaches of the PCI DSS have taken place over wireless networks – I wonder if and how long it will take before this happens over a VoIP infrastructure deployed to a physically remote location which is trunked, unprotected into the internal network where mission critical servers are hosted.

Some would say that this is a network infrastructure “firewall” mis-configuration issue and not a VoIP issue. They are right. But you could also argue that this issue opens up only when you deploy VoIP with QoS and VoIP is so tightly integrated with the network and QoS. The VLAN Hop also enables UC attacks against not only the IP Phones, but the call server as well. For VoIP to be operational, those TCP/UDP ports between the IP phones and call server must always be permitted, even through a properly configured firewall.

Death of the Voice VLAN

Some have talked about the death of the Voice VLAN and others have questioned the relevance of Voice VLANs to UC Security. In my opinion, VLANs were never intended for security. They were designed for one thing: Broadcast Domain isolation, resulting in improved performance and host management. Then the “Voice VLAN” came about – a special access port feature for VoIP that enables the easy application of QoS and IP Phone provisioning. Brilliant, if you really think about it. Voice VLANs were also never intended for security features. However, some started seeing it this way because, by default, a PC wasn’t a member of the Voice VLAN, and Voice would have the highest priority on the network in the event of a malware outbreak on the “data” access VLAN, and so forth. This is still QoS – not security. A network with properly configured QoS at layer 2 or 3 doesn’t distinguish a virus outbreak from an extremely chatty file transfer application. In either case, VoIP will take the highest precedence through the network. Then we started hearing “VLAN is not a security measure” and now we are coming back full circle.

Voice VLANs are never going to die off due to their perceived security limitations. In fact, they are brilliant . They make it easier to deploy VoIP and other new and promising UC applications, like IP Video. Applications like IP video that are heavily reliant on QoS. This helps us all. The best thing we can do is recognize their security limitations and that they were never intended for security to begin with. Which brings me to my final point.

Why?

Many of you reading this are already well aware of this. But that doesn’t necessarily signify that others who deploy or own VoIP do as well. Just the other day, I had a conversation with a Network Engineer who had deployed VoIP for a major US sports stadium. This person believed that the IP Phones configured in the luxury suites were protected against VLAN Hop just because they had deployed MAC Address filtering on the switch ports. We all know that Voice VLAN Hop and MAC Address spoofing can be automated via myriad tools. But still, that doesn’t mean everyone else does.

I’m writing you today to ask for your help as VoIP Security professional in spreading awareness about this issue. I am open to hearing what you are seeing (specifically vendors and configurations in remote areas, and how the application is being used) or any other friendly comments or suggestions. This is an area of research and interest. Please email jostrom {at} viperlab {dot} net.

FBI Warns of New TDoS Attacks

Andy Zmolek — Sat, 15 May 2010 12:45:04 +0000

Earlier this week, several news outlets including Wired.com reported on a new Telephony Denial-of-Service attack that’s becoming more widespread. In this attack scenario, hundreds or thousands of PSTN calls are launched to the victim’s phone in order to prevent financial institution notifications from arriving while the attacker drains accounts. It’s less clear that attackers can do anything about email or SMS alerts, but based on sheer volumes alone one has to assume the attackers are using VoIP technology to originate the calls. Certainly there are many implications to consider, particularly if TDoS attacks become more common within the PSTN going forward.