Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

For what may well be the last time, Macworld Expo begins Monday in San Francisco, with the Steve-less keynote really kicking things off on Tuesday. Open Door will again have representatives at the show, this year with a dual Macintosh/iPhone focus. We’ll be on the lookout for security-related products and information, and report back as best we can.

From a security perspective, the main thing to know at this point is that Alan Oppenheimer, Open Door’s founder and president, and co-author of the book and this blog, will again be presenting at the conference with Marshall Clow from Idio, The two will be giving an updated reprise of last year’s well-received talk, “Keeping Safe on the Internet.”

The talk will hopefully again be as straightforward as it sounds, since simple remains good when it comes to security. It’s again based directly on the “Internet Security Top 10” associated with this blog, a dynamic list that changes as security threats change. If you’re at the talk (Thursday 11:00am), stop by afterward and say hi.

OK, so this entry has almost nothing to do with Internet security or the Macintosh, but it does have to do with the Internet and what the Macintosh is evolving into for all of us, which is the iPhone. And it does have to do with today, Christmas. Open Door Networks and Project A (together We-Envision.com), shipped twelve new iPhone “Envi” apps just in time for Christmas. Based on our iEnvision Web-image browser (which is itself based on our Mac Envision product), the event was just crying out for a Christmas card, so here it is. Enjoy!

http://shows.we-envision.com/12.html

Merry Christmas!

Yah, late commentary.  Sorry, been a little busy.  Brian Chess kicked the hornet’s nest beautifully by declaring:

Penetration Testing: Dead in 2009

with:  

“Death doesn’t mean it goes away, it means it transforms. Pen testing will be reborn in the area of production monitoring and measurement,” Chess said. “The goal won’t be that failure is found and must be fixed. The goal is that failures will become a much rarer event.”

That is a great goal.  However, the goal of penetration testing (which in my world is synonymous with security assessments, so if you are going to get all semantic on me, go nuts, most of my customers use these words interchangably, and they are some of the most sophisticated puchasers of security), is not to prove you have a problem, it is a last minute check to find what you missed elsewhere during the construction of a given application or environment.  In the future, where security in the SDLC is considered mature, penetration testing will still be there for assurance purposes, but also perform continuous improvement, where the findings get looped back into the process so that developers learn about the latest security flaws that they aren’t defending their applications against.

Spending more in other parts of the lifecycle is essential to effectively manage security.  But, no matter how much you spend this year in other parts of your development lifecycle, you will have NO idea what still lurks inside of your application until a qualified party investigates it.  The success rate of any top rate security consultancy in finding critical vulnerabilities that customers think were worth the cost of the engagement in 2008 is going to be over 90%.  

What should really die in 2009 is the low hanging fruit findings that still plague applications going into production today.  SQL injection and Cross Site Scripting were all to prevalent in 2008.  

What I actually think is going to happen is that SDLC efforts are going to have an incredibly hard time in 2009.  Strategic security initiatives are expensive and time consuming, especially to developers.  If you are going to be effective at security in 2009, you are going to have to be low-drag.  Dev teams are not going to have the time to delay product releases, by increasing the overhead involved in cumbersome security at each phase.

The status quo is likely to remain just that over the next 12 months.  On our list of blog posts coming up will be one on lightweight SDLC.  I promise.

ps: if it isn’t at all obvious, it is in Brian Chess’ best interest to say that penetration testing is dead, and it is in mine to say that it is alive and well.

pps: I just read this and I am apparently really rusty at writing blog posts.  Please be patient as I evolve from 16 year old emo livejournal quality to the slightly higher Matasano quality.

ppps: Read Ivan’s excellent response and Brian’s response to Ivan’s response.

Just wanted to wish our customers, our readers, the blogosphere, the internet, the world, and the universe a happy holiday season.   With an economic decline and mass layoffs, IT security budgets are going to get smaller.  Security teams will have to do more with less. 

Meanwhile, an economic downturn will increase motivations to commit crime (including computer based).  And motivations aren’t the only thing increasing.  Attacker sophistication always goes up.  Every year, attackers get more and more sophisticated, and no matter how much improvement we make in application security, there still seems to be enough critical security vulnerabilities out there to keep everyone frantically patching.

I promised that I wasn’t going to do a predictions blog post, because next year predictions are like new years resolutions.  They seem important on January 1st, and by February 1st you can’t even remember what they were.  But, I do have one prediction:

We are going to see an increase in stupid, stupid insider attacks.  People who just get mad at their employers and try to inflict damage.  

No matter what happens, 2009 is going to be an interesting year for the information security space. 

Happy Holidays!

We’ve just released a new version of our first product: Playbook v1.2.

Textual and structured search

Playbook v1.2 now includes full textual search to complement the previously available rule search. We’ve always known search would be important for Playbook: once you manage a certain amount of firewalls being able to quickly find policies referencing an IP address or service can be a huge time-saver.

Before v1.2 search was limited to what we now call rule format aware search, where only specific elements (e.g., addresses, port numbers, host names) within rules could be used as search terms. This form of structured search works great when you are looking for things that fall within the supported structure: it is often more accurate than its unstructured counterpart, and can provide additional benefits when the search terms are more complex than simple text or numbers. For example, using rule format aware search you can identify all rulesets that reference a given IP address, including those that do so by using a netblock that includes it (e.g., searching for “192.168.2.1” will return firewalls with rules for “192.168.2.0/24”).

But sometimes what you are looking for may not be structured information. You may be interested in all uses of an interface name, specific text within macros or all mentions of “FIXME!” in comments. That’s where textual search comes in. With Playbook v1.2 you can now search all your rulesets using both mechanisms, with the added benefit that textual search can also be used to search the wiki and all firewall doc you’ve written, to, for example, find all mentions of a customer name in your rules and doc at the same time.

Search is also aware of versioning, letting you search any arbitrary version of the content. For example, Playbook can search for all references of a name on last month’s version of the rules, or identify all recent changes affecting firewalls with rules that reference port 8080 (including those edits where the reference was removed).

New rule and wiki editor

Playbook v1.2 includes a new AJAX editor optimized for editing firewall rules right from your browser, with no additional plugins required. This new editor supports Playbook’s edit/preview/publish workflow for editing rules and other content such as firewall doc and wiki pages. A preview button lets you see what your content would look like before submitting your edit. In the few cases where a web-based editor may not be the best tool to edit rules, upload and download buttons let you work on your rules outside the browser.

Where do I sign up?

Check out the product’s website for more information on these and other features and to sign up to see the product in action. We’ve added new information on all major features as well as a few additional product screenshots (click on any screenshot to see a larger version).

Let us know what you think.

Security Update 2008-008 is out, along with Mac OS X 10.5.6. That makes 5 security updates in 6 months. Apple continues to stick to a fairly regular schedule of security updates, which is a very good idea. The content of the update again doesn’t suggest that there has been any higher rate of real-world security issues.

The release is for both Tiger and Leopard, and includes very few fixes, another good sign. Notable is another significant fix for Flash Player, definitely one of the current weak links in the security chain. Also an important fix for anyone using Internet Sharing, a service we recommend against running wherever possible in the book. That’s pretty much it as far as fixes of interest. So this is a pretty short entry :)

In an unfortunate case of what was probably over-zealousness on the part of an Apple employee, Apple posted and then quickly removed a confusing Knowledge Base article regarding use of anti-virus software on Mac OS X. The article, previously available at http://support.apple.com/kb/HT2550 began as follows:

Mac OS: Antivirus utilities
Last Modified: December 02, 2008
Article: HT2550
Old Article: 4454
Summary
Learn about antivirus utilities available for the Mac OS.
Products Affected
Consumer Software, Mac OS
Apple encourages the widespread use of multiple antivirus utilities so that virus programmers have more than one application to circumvent, thus making the whole virus writing process more difficult. Here are some available antivirus utilities:

The BBC quotes an Apple spokesman as saying that advice was “inaccurate” and "The Mac is designed with built-in technologies that provide protection against malicious software and security threats right out of the box.”

It seems the media and PR storm caused by Apple’s “admitting” viruses were a potential threat, especially in light of certain anti-PC ads, may have had something to do with the article’s disappearance. That’s too bad in a way, although the article’s encouragement to use “multiple” anti-virus utilities was quite confusing, because that can’t be done on a single Mac (the advice was likely intended to be a statement to be applied across the Mac community as a whole, and is quite accurate in that regard).

Last week, Apple released Safari 3.2 through Software Update. The release notes detailed a number of security fixes, mainly for Windows. So we didn’t think much about it here. However it turns out to have two significant, undocumented new security features. There has been chatter on the Net about these features since Safari 3.2 was released, and TidBITs has recently published an excellent overview of the features and their utility (or lack thereof).

The two features are anti-phishing warnings and indication if a secure site is using an Extended Validation digital certificate. These features are thus opposites. If you go to a “very bad” site, one which is believed (by Google, it turns out) to be a phishing or otherwise fraudulent site, you get a warning to that effect and are asked if you want to continue. On the other hand, if you go to a “very good” site, one which is using an advanced form of digital certificate to verify its identity, you get a visual indicator as to this fact (the name of the company appears in green by the lock icon in the upper right corner).

TidBITS rightly questions the utility of both these features. Anti-phishing is similar to anti-virus, in that the most recent phishing sites will probably not be on the list. TidBITS actually tried some of the most recent scams and didn’t get a warning when they went to the associated sites. And the visual indicator for Extended Validation certificates is very easy to miss, and hard for novices to understand what it means. The EV certificates themselves are of questionable merit, since they basically simply mean that a big company had enough money to pay for one, and the extra vetting process that is involved.

Both of these new features, however, are becoming marketing “check marks” for Web browsers, so perhaps Apple felt they needed to implement those features for that reason. And maybe that reason is also why they “neglected” to document the features in their release notes.

Macworld magazine has published a well done, thorough guide to general Macintosh security, entitled “Mac Security Superguide.” In some ways this guide can be viewed as the first serious competitor to “Internet Security for your Macintosh,” the book on which this blog is based. But it’s actually more complementary than competitive.

The guide focuses on general security for your Mac, as opposed to Internet security. But in the same way that ISFYM has a major chapter on physical security for your Mac, the Superguide has a couple major chapters on Macintosh network and Internet security. Unlike ISFYM, it also delves into privacy issues. Here’s an overview of the chapters. Religious ISFYM readers should recognize many of the titles and subjects.

Safeguard Your Data: Keep sensitive files away from prying eyes
Take Advantage of User Accounts
Protect Your Passwords
Encrypt sensitive files
Thwart Potential Thieves
Protect Your Privacy Online: Battle snoops, spammers, and phishers to keep your personal information private
Surf Safely
Secure Your Communications
Fight spam and Phishing
Inoculate Your Mac against Viruses: Learn How to Keep your system safe from Malware, and How to Back up and Recover Just in Case
Know the Dangers
Prevent Infection
Locate and Treat it
Shield Your Network: Connect with Others Safely and Secure Your Wi-Fi Traffic
Set Up a Firewall
Let Outsiders Access Your Mac
Secure Your Wireless Connections

We’re also proud to note that our DoorStop X Security Suite received the highest rating among all third-party firewalls mentioned in the guide :)

Yesterday we shipped version 1.2 of our Envision for Macintosh product. Envision, and its associated iPhone version, iEnvision, are not security products. But they do contribute to an interesting story having to do with our direction in the security field, and the direction of Apple developers in general. There are actually two parts to the story.

First, as you know, Open Door Networks has been a Macintosh Internet security company for a decade now. A few years ago we made our first foray into the consumer space with Envision, focused on large-screen Macs and Macs hooked up to HDTVs. It was way cool, but ahead of its time (there were few HDTVs to really show it off), and not as successful as we had hoped. So we put it in our back pocket, so to speak, and went back to security.

When the iPhone SDK came out earlier this year, we wanted to expand our security offerings to that device. But, as discussed here previously, the design of the SDK was too good, and limiting, from a security perspective, and there was nothing for us to do in that area.

Since the iPhone was clearly a consumer device, we started looking for potential consumer apps and realized we still had the Envision code in our back pocket. We immediately recognized the irony of implementing a for-HDTV product on the iPhone, but it made sense in many other ways so we went for it. And not only were we rewarded by significant iPhone sales and revenue, critical recognition (“Top 10 apps to show off with”), and what has turned out to be the basis for a whole line of iPhone apps (there are about a dozen apps in our “Envi” line now), but we saw a marked increase in downloads of the old version of Envision for Macintosh, which wasn't even a Universal app until yesterday. Plus users emailing us and wanting improvements in it on the Mac (now that at least a few had HDTVs and other large screens), and with interesting ideas with things to do with it along with the iPhone version.

With this changed landscape, it clearly made sense to bring Envision into the modern era, and refocus it a bit in terms of a great iPhone publishing app. So that's what we've done. We’re curious as to whether there are other Mac developers who have seen the same thing. Our guess is that there are, but we're a bit too busy here right now to think about it much :)

We are happy to announce a new release of our firewall management product Playbook, available today.

Playbook v1.1 introduces Rule Macros and support for managing rules for Cisco PIX firewalls among many smaller enhancements and bug fixes.

Most firewall deployments not only involve multiple devices from diverse vendors but a complex set of rules that need to be maintained over time. Rules may refer to elements specific to each firewall as well as to elements shared across organizational units. More often than not, shared policy elements — common rules for all firewalls in a certain geography, or a common way of dealing with a specific protocol— are a substantial part of these rules. Operations teams resort to all kinds of kludges to deal with shared elements: from massive copy-paste crusades to building tall include-file houses of cards. Playbook offers a better way.

Using Playbook’s new Rule Macros feature you can now create and manage these shared elements individually as an integral part of the firewall hierarchy. Think of Rule Macros as macro language meets tree-like firewall hierarchy. Firewalls that belong to the same area inherit shared elements from the hierarchy automatically. Playbook will track and index all changes to these macros over time and tell you when a change requires you to update your firewalls.

We will be posting more about Playbook and Rule Macros shortly. Sign up to learn more about Playbook!

Anonymizing proxies are often used by people who wish privacy, or to circumvent access controls. High profile political cases such as circumventing the Great Firewall of China and the protection of pro-democracy movements are held up as a model of the positive contributions of anonymizing proxies.

But there are also dark sides to anonymizing proxies, such as using them to harass or stalk other people. Many services such as MUDs or web boards want to be semi-anonymous, and have no interest in the user’s actual identity. In this day and age of free throwaway email accounts, establishing a new identity is easy. Banning an account can be rather futile if all what the offender has to do is establish a new email account. So, access control is often done via IP blocking. If the banned offender continues to persist, often the IP blocks are expanded to include the entire range of dynamic addresses allocated for the offender’s ISP.

However, anonymizing proxies are used to circumvent these IP blocks, and raise the bar for those people trying to control access to their services. While there are many valid uses for anonymizing proxies, a few abusers cause there to be a keen desire on the part of administrators to ban them from connecting or utilizing their services outright.

Many of these anonymizing proxies are not helpful enough to identify themselves as such, making banning them tricky. The question then becomes, how can the use of anonymizing proxies be detected? This in part depends on what sort of proxy is used.

There are:

• Protocol specific anonymizers — these are often specific to one protocol at a time, such as an anonymizing web proxy (HTTP) or Internet Relay Chat (IRC). These involve rewriting the messages that are sent between the communicating hosts.

• Protocol independent anonymizers — these create tunnels to carry traffic to the anonymizer. There are two major categories of protocol independent anonymizers:
  • Application-dependent — the application needs to support the tunneling protocol and communicates directly to the anonymizer.  This includes SOCKS.
  • Application-independent — these implement IP-based tunnelling and is the most transparent for the user.  PPTP and OpenVPN are examples of this.

• Multiple relays — while anonymizers such as TOR are really classified as application dependent and protocol independent, it is unique enough to merit a separate look. TOR uses a technique called ‘onion routing’, where communications are relayed through multiple random hosts for each connection that is made.

The various types of anonymizing proxies makes a general solution for detecting them non-trivial. This depends a large degree on what is being communicated, and what clients are in use. One of easier scenarios to detect are Web traffic over HTTP via anonymizers.

Analysis of the HTTP headers can reveal anonymous proxies, as these headers are often rewritten in a very characteristic way. User-Agent, From, and Referer headers are usually modified or removed to protect the user’s privacy. By outright rejecting unusual variations on these, it is possible to detect and stop anonymous proxies. There are Snort signatures for detecting this as well.

Along the vein of detecting proxy usage, one approach that works against TOR as well is to exploit the fact that the web browser client is executing client-side code such as Javascript, Java, or Flash. TOR uses Privoxy, and Privoxy often rewrites the content that is sent to the client. By detecting altered content using Javascript, it is possible to determine the use of specific anonymizing proxies and reacting differently. This code can be used as a gatekeeper, that checks before loading extra content. Sending this information back to the server might be viewed as a privacy violation. But this is not perfect, as it could be circumvented by a savvy user using force browsing.

A lower level mechanism is to open a Java socket connection back to the server. Jeremiah Grossman and RSnake at ha.ckers.org presented on this technique at Blackhat 2007. When the connection is successful, the server has the IP address of the origin, circumventing the proxy. By comparing the IP address provided by the connection with the one obtained via the original connection, a decision can be made as to if it is a proxy. There are also various other techniques that rely on client-side exploitation.

For each connection via Tor, the exit node changes. HTTP uses multiple sequential connections. This can be exploited readily by embedding a signature that contains the remote address that previously connected, the user agent, and other headers. This is then MD5’ed into a session hash. If the exit node changes, the remote address will change, consequentially, changing the session hash. When the session hash changes, the application or site can kick the user out to a login page.

Another way to detect anonymizing proxies is to download proxy listings on a daily basis and add them to a list. By comparing the connecting IP address to the list, it can be determined if it was via a proxy. This is imperfect and does not cover all the possible proxies. This also includes downloading a list of Tor exit nodes.

One of the more intriguing papers encountered during the research for this post was Identifying Proxy Nodes in a Tor Anonymization Circuit by Chakravarty, Stavrou, and Keromytis. By measuring the network characteristics of a connection via Tor, it may be possible to determine that the communications came via the anonymous proxy. This is speculation, however, and further research may be coming to investigate this. There may be a technical and detailed blog post on this in the future!

As stated earlier, it is not the most trivial of tasks, but by using a combination of techniques, a website operator should be able to block anonymous proxies. If it is a lower level application such as a MUD that one connects to via telnet, then simpler techniques such as proxy list blocking are necessary. Packet inspection or characteristic measurements may allow such applications to block proxy nodes.

I just finished an interesting pen test: an infrastructure who’s entire attack surface consisted of custom embedded hardware devices. They communicated via proprietary wireless data connections.

It was a short project. A few weeks, tops. Getting in bed with their comms wasn’t really feasible: high barrier to entry, requiring hardware I didn’t have. All the traditional back-end systems (PC, servers, etc.) were also out of scope, because they were housed in a secure data center away from the internets, accessible only via the private connections with the devices.

It was looking bleak.

Physical access to the devices was ‘in scope’, so I reluctantly popped one open. As I expected, it was full of entirely proprietary hardware: the mainboard and the peripherals, all communicating across several proprietary buses… and… serial.

So I decided (again reluctantly) to look at the serial stuff. I found a few admin ports, but that was underwhelming. But things got interesting when I noticed that, in one special mode, all the communication peripherals spoke to the mainboard over serial and not the bus they were seated in.

I am not really a hardware guy. I reverse and source audit. So, in my view, it still looked bleak.

Nonetheless, I decided to try my hand at spying on the serial traffic. The first technique I tried was suggested by Eric Monti (who I discovered had done something similar with great success in the past). His suggestion: use two serial ports on my laptop, making it “inline” between peripherals intercepting and rewriting the data with a vanilla “select() loop” style mux. Eric provided some code that I hacked up a bit. This worked, but only partially, because some of the devices failed to initialize during hardware handshake when my laptop was inline (I still don’t know why. I suspect some of the pins I couldn’t control went from low to high… again… I’m not one of the Matasano hardware guys).

The only thing left to do really was passively spy on the traffic between the peripherals. This would require a hardware serial tap. I thought about it, and it seemed reasonable. So I googled around and found this.

I took some (reluctant) trips to Radio Shack and Fry’s and tried my hand at building his tap, not really expecting to get anywhere. After three failed attempts, I realized that this guy’s wiring diagrams were subtly incorrect. The pinouts were wrong. I tried my new design which looks more like the diagram above. The device came out looking something like the photograph below.

I fired up minicom/zterm, and began seeing all the traffic on the bus! (Really only half because each side of the tap is only half duplex.) So now I was starting to feel a little more confident. This was familiar territory, I could now try my hand at reversing the protocol spoken across the peripherals to see what was being sent to the back-end servers. Before I could do that however, I needed to write custom tools —- minicom wouldn’t cut it.

So I wrote an internal serial terminal and injection tool called serial_snoop to be used with this serial tap. It has two modes: The first is passive, and it just displays data on one or two buses. The second drops you into a interactive python shell, and acts like minicom, only instead of reading from STDIN (as minicom does) serial_snoop sends data out onto the serial device via object method calls (which I provide in a big class). Because it’s interactive python you can also import “helper objects” to perform tasks… this allowed me to play interactively with the devices, and name helper functions specifically to their purpose (“initialize_wireless_iface()”, “send_packet()”, and potentially “crash_server()” :-).

And this is where our story ends. I spent about a week reversing the protocols spoken by the device to the back-end systems. It was a surprisingly simple protocol. By the middle of the last week, I had replicated most of the functional parts of the protocol and I had successful data injection into the back-end systems via the wireless interfaces in the device.

The moral of the story, I guess, is that if I can do simple hardware stuff like this, anyone can. Hardware never gets solid testing because of obstacles that may actually be easy to overcome. If you can successfully hop the hardware hurdle, you can find all that never-before-seen attack surface.

Yesterday Apple shipped Security Update 2008-007, making it 4 security updates in 4 months. Perhaps Apple is trying to institute regular security updates, which would be a very good idea. The content of the current update certainly doesn’t suggest that there has been any higher rate of real-world security issues, since most of the issues addressed, as is often the case, seem either minor or theoretical.

The release is again for both Tiger and Leopard, and mainly rolls in a number of fixes to third-party components with strange names: Apache, ClamAV, CUPS, MySQL, PHP, Postfix, Tomcat and vim. There are also the usual set of fixes for potential “arbitrary code execution” bugs.

Probably the most interesting “fix” is simply the addition of new and updated security “root certificates” to the OS. Used primarily in Web browsers when validating secure Web sites (via SSL and https), certificates help “prove” a site is what it claims to be. Keeping the OS root certificates up to date is certainly an important and practical thing.

I didn’t mean to! … Ok yes I did.

http://www.opera.com/support/search/view/901/

I like Opera but it has not received as much ‘security attention’ as Firefox or Internet Explorer. Opera is pretty big in the mobile browser market, so this will probably be changing real soon. Web application flaws and attack techniques are growing everyday but the browser itself is still an excellent and reliable attack vector. In this case the vulnerability is based on a ‘specially crafted URI’ which of course can be triggered by any attacker controlled content. It is reproducible on both x86 Linux and Win XP SP2 and Vista.

This flaw was found using some rudimentary fuzzing, simple stuff really. I basically whipped up a few lines of Javascript to create different URI’s with incrementing string lengths (yes I’m serious). And thanks to Immunity Debugger I was able to boil it down to a heap overflow in no time.

The offending URI was ‘http://BBB*BBB:password@example.com’. This took minimal effort to find and underscores the importance of simple fuzzing test cases being built into your SDLC.

Here is a screenshot of Immunity Debugger when Opera crashed.

Don’t forget to patch: Opera

Been a long time since I’ve posted. I am hereby posting to say that I will be posting again. Specifically about testing Web Services. Which often turns out to be a pain in the arse.

In the interim, I wanted to say that I was going to be in Chicago next week. From Tuesday to Thursday. If anyone wants to meetup, just send me an email or leave a comment. That also means, I will be there for Chisec 21, 7PM-9PM Hop Haus.

I now return you to our irregularly scheduled programming.

This month’s Macworld magazine features an article on personal firewall options for Mac OS X. Entitled “Mac Security: Firewalls,” with sub-title “Do you need more than the firewalls built into OS X?” the article is an excellent introduction to the topic, but overlooks one key item.

The article starts out with a number of important points:

Macs aren’t immune to Internet-based attacks
There are computers out there that do nothing but look for vulnerable machines, and these will at some point find your Mac
When you’re at a WiFi hotspot, you’re particularly vulnerable.

The article then points out how Mac OS X has two different firewall technologies built in : ipfw and Leopard’s new application firewall (which the article refers to as a “socket firewall”). ipfw is off by default, in deference to the application firewall, which the article accurately points out has a number of limitations.

The article then talks about third-party options for activating ipfw to recover the features missing from the application firewall. These options include our DoorStop X Security Suite. The article specifically highlights DoorStop’s ability to easily switch between configurations when you change locations (for instance if you’re in a coffee shop with a WiFi hotspot and want greater protection).

The otherwise-excellent article overlooks one key feature of all firewalls however: logging. Any good firewall should log all access attempts, and advanced ones should provide forensic analysis features. Leopard’s application firewall does provide a log of sorts, but that log is missing critical information and is nearly useless. ipfw technology includes excellent logging, which the Who’s There? component of our Suite can analyze in detail. The article should have at least brought up the logging issue.

Finally, I guess we should also mention that DoorStop X was the highest ranked firewall of those listed at the end of the article, with four-and-a-half mice :)

This is the first in a series of posts covering VoIP.

There are two separate components to most VoIP implementations:

• Signalling, which is communicating call setup and details. (Ex: SIP, H.323)
• Session, which carries the actual media stream and conversation itself. (Ex: RTP)

There are also master/slave protocols that incorporate signalling, but directly control the client hardware or software. With this, the handset or softphone is a dumb terminal where keypresses are sent directly to the host which controls the display and indicator lights. Examples include Nortel’s UNISTIM, and Cisco’s Skinny Client Control Protocol (SCCP).

With this in mind, we can classify VoIP endpoint philisophies as follows:

• Peer to peer - with more intelligence in the phones itself, and using SIP or H.323, the phone can negotiate and initiate calls on its own.
• Dumb endpoints - calls are initiated and negotiated on behalf of the endpoint by the controlling host, the PBX.

In this post, I am going to be focusing on and attempting to distill the essentials of SIP, demystifying it for the security audience who wishes to work with it.

One day, Mario was on his way to visit Princess Peach at her invitation. He saw her standing outside of the Warp Pipe that lead to her Castle. He waved at her. She waved back.

And then, oh no! Bowser’s minions snatched her away!

But fortunately, the Mushroom Kingdom was recently wired for WiFi. So Mario whips out his wireless SIP phone. He calls Toadstool, Peach’s loyal servant. Toadstool is on the local wireless network. Mario pushes the speed dial button for Toadstool, which has Toadstool’s domain name.

Once this has been resolved to an IP address, SIP handshaking happens. SIP is transport independent but is usually carried over UDP. SIP messages are text based in the theory that they are easier to monitor and diagnose, with messaging that is stateless and very alike HTTP.

First, Mario’s phone sends a SIP INVITE packet to Toadstool’s phone. It includes all the details on who is calling, including how to contact the caller. This includes origin and ports. Toadstool’s phone responds with a ‘100 Trying’ and then a ‘180 Ringing’ message. When Toadstool answers the phone, it sends a ‘200 OK’ message. When Mario’s phone receives the OK message, it sends an ACK back. Once this happens, voice on each end is sent to the other via RTP over UDP using the IP and ports set up in advance during the SIP transactions.

“Oh, no!” cried Mario to Toadstool, “Bowser’s minions kidnapped Princess Peach!”

“Again?! We have to teach her how to defend herself. She just hasn’t been herself since Super Mario Brothers 2,” replied Toadstool, “I’ll round everyone up. Luigi is away at the Mario Kart Racing Track though.”

“All right! I’ll call him,” replied Mario to Toadstool and then hung up.

Now, for those of you readers who are rooting for Bowser, was he smart enough to realize that you can spoof UDP packets and CANCEL a call before Toadstool could answer? Or did he understand that SIP packets can be intercepted on a local network, and he could set himself up as the man in the middle? Unfortunately for those of you inclined to cheer for the villain, he is a giant turtle of habit. Body snatching and sending minions out is the extent of his technique.

A pity, for that if he had sent out countless INVITE packets on the Mushroom Kingdom network, he could have shut down the entire phone system and gotten away clean with Princess Peach.

Since Luigi was outside the Cloud Kingdom, when Mario dialed for Luigi, his phone talked to the Mushroom Kingdom SIP Proxy.

The SIP Proxy does resolution for the address provided, which was luigi@mushroom. When Luigi went to the Mario Kart Racetrack, his phone registered itself with the Mushroom Kingdom SIP Proxy. When it registered, it let the proxy know what its IP address is and how to contact it.

So when Mario called Luigi, the SIP proxy resolved according to Luigi’s REGISTER information. The standard SIP handshake is passed back and forth. When it gets to RTP streams is where it gets complicated. The Mushroom Kingdom could be using a STUN server as well. Or their infrastructure could be SIP aware, and open ports accordingly on the Mushroom Kingdom firewall.

“Luigi!” Mario exclaimed and could hear his brother’s kart roaring, “Princess Peach has been kidnapped by Bowser!” And with that, Luigi veered off the race track in pursuit of Bowser’s minions.

Those that are more fond of turtles than plumbers would be saddened to note that Bowser could have impersonated as Luigi on the SIP proxy if he had stolen his credentials. Or Bowser could have spoofed Luigi’s IP address, and Mario’s brother would have kept racing on.

Using the superior communications network, they were able to catch up with Bowser’s koopas and jump on their heads. Mario was rewarded by a kiss from Princess Peach!

I hope you enjoyed reading the story as much as I enjoyed writing it. I hope that this will clarify SIP for some of my readers, and open your eyes as to some of the attack vectors inherent in SIP.

All characters and places used are copyrighted by Nintendo.

The background sprites are credited to GordonBlazin@aol.com

The character sprites are credited to davidjclarke@gmail.com

Hi!

I am Stephen A. Ridley. I recently started here at Matasano as a Senior Researcher (working out of the Manhattan office). I studied Physics, but for work I do software reversing, protocol replication, and exploit development. Before Matasano, I was at McAfee as a Senior Security Architect, in a small (5 person) R&D group learning from all-stars like Mark Dowd, John Viega, and David Coffey. Prior to McAfee I was at Aegis Research (which became ManTech Security and Mission Assurance) supporting the U.S. Defense and Intelligence communities doing reversing and vuln research. I got the opportunity to do all kinds of other neat stuff there, but mostly I got to be batboy for all the grand slammers on that team.

Here at Matasano, I again find myself fortunate enough to be on another phat team. I (probably like most of you) came up following groups like Teso, #ADM, and antisec.is while getting amused by groups like b4b0, ~el8, and gob bles. Also, like many folks in this industry, my motivation tends to wax and wane, limboing between states of limerence and ‘jaded disillusionment’. (If you remember, for a while folks thought it was all over after ~2001…but here we are.)

While the game is definitely different now, there is still some inspiring stuff being done. Most recently some of the public discoveries and techniques I found to be pretty re-inspiring in different ways were:

• Barnaby Jack’s ARM stuff (new architecture work)
• G D I + (simple bugs, big impact)
• Dan’s DNS cache (application level bugs)
• Dino’s quicktime (new platform work)
• Kostya’s kernel pools/IGMP (new exploitation techniques)
• And Dowd’s AS3 (oldschool technique with newschool application level impact)

Work like this serves as reminders that there is still a lot of unexplored landscape out there with plenty of good work waiting to be done regardless of how bleak the future might sometimes look for cool bugs. I look forward to “settling in” to work on some of the neat projects we have lined up here at Matasano and hopefully posting a bit here on the blog.

The San Jose Mercury News has a thought-provoking article about malware on smart phones. Entitled “New worry for mobile phones: malware,” the article seems inspired by the recent release of the totally “open” Google “Android” smart phone, along with the iPhone’s success. The article lumps the iPhone in with other smart phones in regards to potential malware, which isn’t entirely accurate. It also sparks an interesting insight into the ongoing Mac-verus-Windows security debate. Let’s take a look.

The article starts with “Is your phone the next [malware] battleground?” and goes on to cite security experts as thinking that it could be. And they’re right. As the article points out, a smart phone “has a full operating system and can run applications much like a desktop computer.” That’s the root of the problem in this case. Smart phones are really personal computers.

The article next goes on to under-emphasize a key point, which also applies to all computers: “Other security issues — such as simply losing a phone — are arguably of more concern to mobile phone users today.” In other words, physical security first, as we say in the book.

The article then makes a key and accurate point: “For example, owners of the iPhone, one of the first phones to have a full-fledged Web browser, are much more likely to surf the Web on the device than other smart-phone users.” Web surfing does seem to be the most vulnerable point of exposure for iPhone users. Safari has been known to have exploitable (in fact, exploited) vulnerabilities, so iPhone users are vulnerable here. Especially since Safari is really the only way to browse most of the Web on the iPhone (our iEnvision product, for instance, browses just images), we need to count on Apple to keep Safari as bug-free as possible.

Potentially the most interesting point in the article comes near the end: “Other analysts see the threat growing because of the increased ease with which mobile users can download and install applications to their phones. Apple's iTunes App Store paved the way in that regard, but Google promises to place even fewer controls on the applications for its new Android platform.” On “open” systems, like Windows, the Mac OS and Android, downloaded apps are definitely a key threat. An important point the article misses, however, is that Apple has tackled this issue head on in the App Store.

As we emphasized here previously, Apple has done an excellent job by, among other security measures, imposing slight limitations on how we developers develop iPhone apps. By slightly limiting the platform’s openness, Apple has greatly limited its vulnerabilities. This seemed, and seems, like a good tradeoff, and so far there have been no serious pieces of iPhone malware discovered in the App Store (and still lots and lots of apps). It will be interesting to see if such malware appears to a greater extent on Google’s or other smart phone platforms.

Getting back to the subject of this blog, the Mac has historically been a much more secure platform than Windows for two principal reasons: it was designed with the user, and hence security, as its focus, and it has had a much lower market share. The iPhone OS was also designed with the user as its focus, but right now is the dominant OS as far as downloadable apps go. It should thus provide some additional data in the ongoing debate as to which of the two Mac-security factors is the main one. Assuming it continues to dominate, will the iPhone succumb to malware, or will its design, and user focus, prevail? Stay tuned.