Author Archives: Shawn Merdinger

Hackers Attack International Space Station Email — Let’s Hope VoIP Isn’t Next

On April 1st VuNet reported that hackers had taken down the International Space Station’s email capabilities.

So, this was a good April Fool’s joke, right?

Three astronauts onboard the Space Station reported last night that email was no longer working.
Hackers are thought to have planted a Trojan in the computer systems at Houston and used the infection to ride the satellite uplink to the Space Station.

What is especially troubling is the email system’s reliance upon older Microsoft operating systems that are no longer supported by Microsoft.

“I am sorry but there is nothing we can do. It is past its deadline, said Professor Brian Offin, Microsoft’s head of obsolete operating systems.

Again, a good April Fool’s joke, right?

However, this false article brings to light the fact that as newer technologies replace legacy systems, we must bear in mind that the new technology changes will, over time, themselves become legacy systems and subject to the same outdated, unsupported and insecurities that plagued the very legacy systems they replaced.

So what’s this have to do with VoIP and the International Space Station? Well, details are thin, but way back in 2000 VoIP Group Inc. was awarded a contract to provide a VoIP replacement for the ISS to “bring about significant cost reductions as it supplements and then replaces an existing legacy system.”

Initially deployed at NASA’s Marshall Space Flight Center in Huntsville, Alabama, and later at other International Space Station operations centers, the solution will consist of VoIP Group’s gateways connected to the Internet and to Raytheon voice switches and CUseeMe conference servers to support voice conferencing. The system is designed to link together researchers, NASA operations personnel, and potentially ISS crew, to support collaboration during Space Station experiment planning and operations. Because users can access the system using a standard Internet browser on an inexpensive multimedia PC, they can be located at NASA centers, universities, and companies throughout the world, and still connect in real-time, 24 x 7.

iss voip

I hope that the sharp folks at NASA and VoIPgroup are taking the proactive steps to avoid security problems with critical communications with the ISS.

Snom Security – A Positive Vendor Response Case Study

It’s refreshing to see a vendor in the IP phone space respond to reported security problems with their products.  During the GNUcitizen Router Hacking Challenge several issues were reported with the Snom 320.  The vulnerabilities posted were also picked up by Tom Keating’s blog.  Gnucitizen posted a webpage detailing the vulnerabilities as well, and the vendor response has been very good, with the following actions taken by Snom (note: typos left in):

  • We will publish an article on “how to make your snom phone saver” on our website (including a link to it on the start page)
  • We will send out a newsletter to all our registred VARS and distributers with this information
  • We will work on the FW to improve security (just checked, on FW Ver. 7 the Flash applet is disabled by default)
  • We will publish a new email adress, for security matters (mostlikly security@snom.com), which goes to a bunch of people.

So, this is a good start, but I do have a few humble suggestions for Snom:

  1. Have a dedicated security page, e.g. www.snom.com/security/ that has their product security policy spelled out.
  2. Setup PGP for the security@snom.com email alias and post the public key so that communications can be encrypted.
  3. Formalize the product vulnerability advisory process, including sending out the advisory to various mailing lists, etc.  Following Cisco PSIRT and Asterisk advisory format is a fine start.
  4. Tidy up the English translations for better flow and understanding.

Overall, this is encouraging to see a VoIP phone vendor stepping up and taking ownership of product vulnerabilities – Kudos to Snom!

Hacking ZyXEL Gateways

An interesting paper recently published by Adrian Pastor of ProCheckup discusses vulnerabilities and attacks against ZyXEL gateways, including (yikes) Remote wardriving/attacking internal networks over the Internet, among others:

  • Privilege escalation from “user‟ to “admin‟ account
  • SNMP read and SNMP write access enabled by default
  • Persistent XSS via SNMP
  • Poor session management allows hijacking of admin sessions
  • Authentication vulnerable to replay and password cracking attacks
  • Disclosure of credentials
  • Considering the code reuse among various products made by most vendors of these residential gateways, not to mention the widespread deployment by service providers, I think it would be quite interesting for VOIPSA folks to expand on Adrian Pastor’s work and pursue this type of testing on some of the VoIP gateway products that ZyXEL offers, specifically the Analog Telephone Adapter, Station Gateway and Integrated Access Device to start. Also, the web interface of embedded devices like these are especially problemmatic from a security perspective, and it’s well worth a look at another one of Adrian Pastor’s papers over at OWASP.

    “So what” you might say about the security of these types of devices? Well, SANS diary notes some strange things afoot at the Circle K with Dlink, and there is the recent BT Home Hub CVE-2008-1334 vulnerability. More routers and details at GNU Citizen’s router hacking challenge.

    ISIC for VoIP Phone Stacks

    In my last post I noted that it’s a good idea to know how robust your IP phone is to attacks against the stack and mentioned the Targa3 tool for classic attacks. Continuing in this testing approach I’d like to bring up a fantastic tool called ISIC. If you dare to run ISIC, I can almost guarantee will make any IP phone drop dead in its tracks, reboot, show wierd characters on the screen, etc., etc.

    Take my word for it, you do not want to run this monster on a production network. To wit, the ISIC page states the following:

    “Warning: ISIC may break shit, melt your network, knock out your firewall, or singe the fur off your cat”

    A key takeaway of ISIC is that it is not just a single tool, but rather a suite of tools; with each tool (esic, udpsic, tcpsic, etc.) geared toward targeting a specific layer of the IP stack.

    Toasting VoIP Phones with Targa3

    With all of the VoIP tools available it’s easy to forget to test the IP stack of your VoIP phone for stability from classic attacks. With that in mind, a good tool for accomplishing this basic vetting is called Targa3. Written way back in 1999, Targa3 encompasses several attacks such as Jolt, Nestea, etc. to “generate attacks using invalid fragmentation, protocol, packet size, header values, options, offsets, tcp segments, routing flags, and other unknown/unexpected packet values.”

    You can grab Targa3 from Packetstorm here. Oh, and happy toasting. 🙂