Archive for March, 2006

take that!

NY hates you

best idea ever

I came up with it tonight.  And it’s awesome.  Freakin awesome.

The Intersection between VoIP and Security Reality

What follows is my short investigation into what additional risks VoIP introduces to your voice network when compared to traditional telephones. It was an essay I wrote for a network security course last semester.

Most new technologies go through very predictable evolutions of security, independent of similar advances already made in other fields, and those evolutions are usually a direct response to specific threats. For example, cell phone makers are just now beginning to think about trusted code execution and permissions systems due to the emergence of viruses on their platform. Another common occurrence amongst new technologies is to fall back to “security by patching” as they see the need to “just make it work” more important than putting security into their design process and hence, to some inexperienced managers, slowing them down. Unfortunately, it seems that a critical new technology has fallen into many of these oft-repeated traps: Voice over Internet Protocol Telephony, commonly known as VoIP.

Current implementations of VoIP are notoriously hard to integrate with existing phone networks, existing security infrastructure, and existing network architecture. VoIP requires VoIP-aware firewalls and routers and port forwarding on NAT gateways at the very least, either of which modification can introduce latency and jitter if done poorly making VoIP all but useless to the buyer. As a result, individuals and businesses alike give their main attention to fixing these problems before thinking of how to engineer security into this complex new technology. Further, one of the main reasons consumers switch to VoIP is because of the lower cost. Security can, and usually is, seen as adding unnecessary expense and slowing down the process of converting to VoIP. All of this makes security an after-the-fact addition to the deployment of VoIP, where it usually becomes more costly and less effective than if it had been integrated from the beginning.

The following is a simple quantification of threats present in VoIP voice services not present in Circuit-Switched voice services:

  • Viruses
  • Worms
  • Denial of Service
  • Hackers with knowledge of IP
  • Accessible to users on a LAN
  • More complex PBXs, media gateways, switches, routers, firewalls, cabling, phones, softphones
  • General purpose OSs, databases, web servers
  • Untested, immature software
  • Immature standards (SIP, H.323, MGCP, H.248)

These risks are slowly making their way through the cracks only a short time after VoIP has reached the mass market. A quick search for public exploits shows weakness in many SIP implementations to not properly forward the NOTIFY parameter, allowing an attacker to spoof his caller ID, buffer overflow vulnerabilities in the entire line of Cisco 7900-series IP telephones, prompting information leaks, DoS vulnerabilities, and man-in-the-middle attacks, and the emergence of sophisticated, yes easy to use, software enabling IP “wiretaps”.

Of these risks, which one could easily expand to include many more, I believe the largest and hardest to reconcile will be the use of general purpose operating systems and the hackers the VoIP platform will inherit through its use of IP data networks. Gatekeepers, call managers, media servers, IP phones, PBX’s, and more can and will be run on general purpose operating systems like Windows and Unix (or its derivatives) in the VoIP environment, which the world is constantly struggling to secure for purposes less important than a worldwide telephone network. As demonstrated above, the vast expertise of hackers knowledge of applications run over IP is already being put to work at this first generation VoIP environment.

Another major source of security problems can arise from the different paradigm VoIP follows from traditional circuit-switched networks.

  • If you have access to a computer, you can potentially turn it into a VoIP softphone. This presents interesting security problems to enterprise networks.
  • If you hack into a VoIP gateway or other server, you now have access to a fully functional operating system through which you can launch further attacks on other networks outside of the VoIP network and into a private corporate network, for example.
  • Related to the last problem, if you hack into a VoIP phone many of them run web servers, tftp servers, and some even go beyond typical embedded operating systems and include trimmed down general purpose operating systems instead like, for example, Windows Mobile. Compromising a VoIP phone can potentially give an attacker access to the network which it is connected to.
  • VoIP calls are not tied to a specific area. One of the cited benefits of VoIP is that you can pick up your hardware and account information and make a call from anywhere. Also related to the last two problems, if you gain control of a VoIP server you can make calls from it and misrepresent your location.
  • Your voice network now depends on your data network. Your voice network now inherits traditional IP-related problems like ARP spoofing, DNS poisoning, TCP injections, IP spoofing, and so on. Improper data network architecture can now greatly impact the security of voice network.

As with the previous list, this list can go on.

Many talented individuals are noticing this problem and grouping together to fix it as can be seen in the VoIP Security Alliance (VOIPSA). VOIPSA recently released its first standards document where they tried to enumerate possible threats. While this is a good first step, I believe it will take a major security-related event to shock the community into accepting these threats that VoIP brings with it to voice service. The situation now is as ripe a mass market technology can get for easy hacks that affect global audience.

References:
http://www.securiteam.com/exploits/5EP0D0AGAW.html – SIP NOTIFY message vulnerabilities
http://www.securiteam.com/exploits/5HP0O0U75Q.html – Multiple Vulnerabilities in Cisco 7900
http://vomit.xtdnet.nl/ - VOMIT, Voice Over Misconfigured Internet Telephones

Playing with CSS2

I did a major redesign of the frontpage of CryptoCity and never really said anything about it. I think it’s worthwhile to talk about how I did it.

First off, go look at it: CryptoCity.

  • It is XHTML Strict
  • There is no Javascript
  • It only displays in non-broken implementations of CSS (non-IE)

As has been said elsewhere, the foundation of the hover effect is as follows:

li ul {display: none;}
li:hover > ul {display: block;}

What this bit of CSS does is say “all lists that are themselves contained inside list elements, don’t display your contents” and “when lists that are inside of list elements are hovered over, display them.” To use this each of My Life, My Work, My Stuff is a list with the first element being the name that gets displayed.

Then inside that is the list that I want to use with the hover effect.

Just plug in the above CSS and it works!

To layout the page I got some help from glish.com’s CSS Layout Techniques. The CryptoCity layout is actually a static, centered, 3 column layout with an in-layout header and a detached footer. Each button (list of selections) is a column. To do this, first wrap the entire page except the footer in a div, mine is called ‘container’:

#container {
margin-right: auto;
margin-left: auto;
margin-top: 10%;
width: 540px;
padding:0px;
text-align:center;
}

The ‘text-align: center’ actually just aligns the text, not the frame itself. ‘margin-left/right:auto’ is what keeps the frame in the middle of the browser. Then put each column inside the container div with float:left until the pixel width of container is full:

#contentleft {
width:166px;
padding:0px;
float:left;
background:#fff;
margin-left: 20px;
}

#contentcenter {
width:166px;
padding:0px;
float:left;
background:#fff;
}

#contentright {
width:166px;
padding:0px;
float:left;
background:#fff;
margin-right: 20px;
}

The ‘margin-left/right: 20px’ is to let the separating line extend outward further than the nav buttons. The margin directives aren’t neccessary to make a 3 column layout. The big image at the top sits by itself with no float directives:

#bigimage {
height: 174px;
width: 500px;
text-align: center;
padding: 10px 20px 10px 20px;
}

That’s about it. Now just put div’s in one after another inside the main container div and you’ve got yourself a layout. The footer is separate and will work on any page. The footer is simply absolutely positioned from the bottom-left with each side having a different float and text-align value. The left size needs some padding or else it’ll be flush with the edge of the browser window.

#footer {
position: absolute;
bottom:5px;
left:5px;
font-size: 11px;
}
#footerleft {
float: left;
text-align: left;
}
#footerright {
float: right;
text-align: right;
margin-right: 5px;
}

So just make one parent div and then two children divs inside it, each with whatever you want on each side of the page.

If you want to REALLY see how CSS lays out the page with div tags, download the Firefox Web Developer extension and have it show frame outlines. It’ll put a box around each div. This helps the most when you look at the outlines side by side with the actual CSS. I used it to troubleshoot my page as I was writing it.

I may not have said it in an earlier post, but the Head First XHTML and CSS book from O’Reilly really helped. It’s a thick book but it goes fast. If you have questions I’d suggest picking up a copy.