Took long enough...

No, I'm not talking about how long it's been since our last blog post, I'm talking about the iPhone.

I can't say I'm really surprised, except that maybe it took so long, but the iPhone hacking teams have announced a major remote exploit for the iPhone/iTouch. A file parsing exploit, the way we many of us expected it would happen, this is remotely exploitable via a malicious .tiff file. It appears that this was created to make it possible to remotely unlock iPhones (a dubious prospect at best).

For all the interest that the information security community had in the iPhone before it came out I've been shocked at how little has come out of our community. It's shocking how the majority of the "exploit" activity on the iPhone has been the traditional hackers, those who just seek to expand functionality. These "hacks" have been created to compensate for the lacking API, not those attempting to compromise this information rich device. Maybe good is stronger than awesome.

More info here and the actual malicious tiff here.

Another iPhone Security Perspective

Alright, I promise, last iPhone post, at least from me.

The fine folks over at Symantec's Security Response group are apparently taking a look at the iPhone from a "Wouldn't it be fun to land malicious code on this" perspective and seem to have more confidence than I did initially (See: iPhone sounds atlot like iPwn), and with good reason. It would seem that Apple hasn't been as caviler with their AJAX/iPhone integration as early reports suggested. For now that seems like good reason, but as the iPhone gets opened up further and further, either by Apple or by intrepid hackers, that may change.

So give the Symantec article a read, and enjoy your iPhone. We'll be coming for it soon...

iPh0n3: And so it begins...

From TUAW:

"iPhone enthusiasts over at the #iphone-talk and #iphone-mac channels on irc.osx86.hu have developed iPhoneInterface, a new Windows and Mac tool that allows you to manipulate the iPhone's state, launch services, and interact with the iPhone filesystem. With it, you'll be able to scan the iPhone file structure, create and remove folders, start iPhone services, and more."

I don't think anyone is really surprised that this happened I know many people who believe that Apple actually encourages this type of behavior, evidenced by the easy of cracking into the AppleTV and the numerous enhancements that followed. I don't know if I quite fall into that camp, but I do think it's inevitable that any closed system that gains interest from so many technically inclined people will not stay closed for long. I don't know if that's really a statement about security, or just common sense.

Protection/hackiblity philosophy aside I'm excited to see where this goes as I get ready to throw down my own $600 to Apple/AT&T. Take the already impressive iPhone, throw in a healthy helping of the great features you get in regular OS X, and add in some of the features found in other high end phones, and you really have a be all device. Truth be told I'd actually be reluctant to use such hacks on my main phone, but my real hope is that this kind of thing encourages Apple to open up the iPhone, add the features people have been asking for, and make it a lil hacking pad that I can also get email and make calls on.

That being said I think SSH and the ability to browse the filesystem are a must, but how about a Python interpreter or something? Flash maybe? A Safari view source option? TextMate for iPhone? Are you listening Apple? I want to be able to play next year's CTF qualifier on the Metro.

iPhone sounds alot like iPwn

So as a fairly enthusiastic Apple fan I've been getting asked often how excited I am for the iPhone ("Very"), am I going to get one ("prolly sometime in July"), and if I think it will be that great ("I do"). With someone of a basic technology background this is usually followed by some question about applications, SDKs, and if I think Apple will open it up ("I do") to third party development.

My overall take on it? I've had a number of smartphones and aside from making calls I mostly just used the browser. As for other applications after a few that I tried for experimenting I found I rarely used others, just sticking to the basic software that was included, and even that little enough.

As for the iPhone I truly believe that the killer app will be Safari itself, if it's all that Steve has tried to demonstrate it, may or may not, be cracked up to be. I'm not really sure what applications the developers who are attacking Apple for not providing an SDK think they'll create. In the years of Palm/Windows Mobile/Symbian/Blackberry smart phones I've yet to see an app that overwhelms the function of a phone to make calls, text message, and maybe, if you're lucky, get email or browse the web. All of these are functions the iPhone will do out of the box. Even on my MacBook many of the most important things I do, blogging, reading RSS feeds, getting security news, are all things done in the web browser alone. What app are Apple devs just dying for the chance to make?

Now that multi paragraph rant is not to suggest I'm peachy about the whole thing. This is a security blog after all. By not creating an SDK for creating true applications or widgets, and instead relying on Javascript/Ajax (as though you can have one without the other) you lead to a new problem, web pages can have amazing integration with your personal phone. Let me rephrase that: Advanced applications, running from remote servers, with both instructions and data, that's been shown already to have concerning security issues, will be able to run on your iPhone, and have, in some way, access to your address book, iTunes, and the ability to make phone calls. How was this a good idea?

One of the few inherent security mechanisms built into web browsers is that they, to some extent, exist in a sandbox. Most of the time Javascript can't access the OS file system, it can't control applications other than the browser, it can't access system resources, and all those are only most of the time. There are plenty of side effects to current web technology that make a security researcher pull their hair out, and that's all in the sandbox. Billy Hoffman's Shmoocon presentation discussed many of these, from keylogging to his own technique for web scanning using just Javascript and his particular brand of maniacal thought.

It would seem, based on current information, Apple is deliberately adding such features creating a potential security nightmare, deliberately adding the ability for web applications to circumvent the sandbox. So what will happened? XSS attacks that rewrite your Addressbook? A hidden iframe that calls 911 for you? Who knows really, but when "webapps" can access system functions it's hard to imagine it staying innocent. Now it's very possible, and I'm in fact hopeful, that Apple has considered these things and put protections into place, but even so it is easy to suppose that this would be a thin veil of separation, and the possibility for misuse could easily be close to the surface.

For a company like Apple, who so often touts their security record (no I will not digress into a discussion of Safari now (but yeah, wow, 2 code execution vulnerabilities in a day?)), to not aggressively market that aspect makes me wonder how much consideration that aspect of design received. All of this is obviously speculating the worst, but as Apple has messaged little to nothing about the security features of the iPhone, leaving everyone to evaluate what they see. And based on what we see of the iPhone's design what else are security researchers to assume?

Or maybe I'm the only one who is worried about all this.... well, there's also Billy.

A Safer Apple Experience per Grandma Roberts

In these days where everyone is getting worked up over OS X vulnerabilities it's somewhat easy to not know quite how to respond. I love my grandmother partially because even though she may not read all the warnings on SANS Internet Storm Center or read John Grubers surprisingly enjoyable and fair interview with Dino Dia Zovi she will email me anything she sees on CNN.com or gets via email about computer security. It's really quite touching and means a lot that she cares enough to take an interest in what I do.

It also throws some things into a different perspective for me. I often ask myself how this, be it a new vulnerability or defensive technology, would impact my grandmother. Now I've heard of this technique used to shift paradigms and gain a better understanding of a technology, but for me it's also protection, since I never know when my next call to Grandma could turn into "So Scott, is my Mac going to get broken into?"

What can I say? My grandma is a proactive person. It puts a lot of pressure on a guy. I'm used to explaining the newest vulnerabilities, exploits, worms, and attack techniques to a cadre of some of the finest information security analysts in the world. I'm used to producing technical write ups that go to highly skilled information security teams all over the world. Explaining how Dino D's exploit will impact my grand mother? Much more complicated. It can't be a "O don't worry, it'll be fine Grandma, I promise." No sir. Last time I tried that was over a printer, and so insistent was my grandmother to get it sorted out herself that I ended up wearing half a cartridge of printer ink. So I have to be prepared if Grandma gets wind of this to not just to explain whats going on and it's impact, but also how grandma can mitigate the issue for herself.

I figure such things might also be useful to the community in general. Perhaps you have a grandparent or parent with a similar iron will and determined interest. Perhaps you're just curious. Here goes.

Scott's Guide to Securing Grandmas Mac:

• Disable the automatic "Open 'Safe' files after download." in Safari.
  
• Disable Java in Safari.
• Turn on the Firewall.
• Stop using the Administrative Account for day to day stuff.
• Use strong passwords on all user accounts.
• Give Keychain a different password than your user password.
  
• Turn on Filevault.
  

There ya go. Thats the basics, as per Scott Roberts and, even though he may not remember it, Timothy Martin. Most of those steps, though very similar to those Dino himself recommended, were pulled from a presentation Tim and I gave as the Security Geniuses for the Penn State Mac Users Group more than two years ago. Oddly enough they're still relevant. Some things never change.

Not enough for you? You want more Mac security goodness? O well I've got that too:

• Want the next step up? Check out Apple's own Tiger Security Config (PDF) for a more in depth look at how to secure OS X.
• Want most of that fun without all the reading? If you know your system well then you can get a lot of automated security goodness out of Bastille for OS X. Jay Beale is a smart cookie.
• Not enough? My my, feeling ambitious, well if you want to lock your OS X down to National Security Agency Standards (something I refer as a Paperweight Lockdown) then check out the NSA's own Security Configuration Guide for OS X.

There ya go. That's four different ways to lock down your Mac. Are they perfect? No, not quite, but as fellow Vulnerable Mind Rolf constantly says "You're only 'secure' in a single moment. Staying secure is a process." Wise words from the Vulnerable Minds elder.

It's the beginning of the rest of the world...

From Errata Security:

"The badass guys at Matasano, namely Dino, just pocketed a cool 10k and a Macbook in the CanSecWest challenge to own a Mac. Tom is right, brace your self for the flood of Mac faithfully posts about why this doesn’t count. I can hear John Gruber tapping away and silent sobbing in the distance."

Yep, guess what, Dino from Matasano Chargren popped a brand new, fully patched MacBook Pro with an 0-day exploit for Apples implimentation of Java exploited through Safari (which is rumored to be vulnerable in Firefox too). Congrats to Dino, and to the rest of the OS X community: Breathe.

Now I'm a big Mac fan. I adore the things. My Mac is the best tool out there for the work I do. As a general computer user and as a security researcher it provides the platform to code, create presentations, work with multiple operating systems, communicate with others, and all the other things I do with a computer. And you know what, I do believe I have to deal with fewer actual instances of malicious code.

Now that is not me saying this doesn't count. It does and everyone needs to acknowledge it. That's not me saying that my Mac is inherently more secure, it is not. Vulnerabilities are errors in how applications are designed and/or implemented. Since Steve J, for all his brilliance, still has people designing and coding the Mac OS, its drivers, its applications, and its hardware that means there will be flaws, mistakes. Just like Windows (NT, XP, or Vista) OS X will experience flaws that can be used maliciously to execute code, corrupt files, and all manner of other things. That's not a new thing since Dino owned that Mac at CanSecWest, that's the way it's always been, and the way it will continue to be.

I take the same stance on this that I've always taken on OS X vulnerabilities. I'm not getting worked up, I'm not changing my habits, I'm not gonna sell my Macbook and get a Thinkpad to put Ubuntu on (though I may keep my Macbook and get a Thinkpad, this one if you're generous, to put Ubuntu on). I'm going to advocate the following things to Mac users:

1. If you're running a Mac, recognize that you don't exist in a bubble of security that can't be popped.
   
2. Be cognizant of what we realized in step 1, and try to learn some good computer use habits.
   
3. Inhale.
4. Exhale.
5. Repeat steps 3 and 4.

Now I have a different set of steps I'm going to advocate to Apple:

1. Get fired up. This was your warning shot, one across the bow. Heed it.
   
2. Double the number of people you're looking to fill the new security jobs available at Apple. Consider tripling it.
   
3. Take a page from Microsoft and become more transparent. Microsoft's security program has an impressive infrastructure for communicating warnings, details, preemptive fixes, and basically how Microsoft is handling things internally to make people safer. Apple has largely kept security information under the radar, releasing patches without saying much more. Time to end that.
4. Another thing to take from Microsoft: build security in from the ground up. The Secure Develoment Lifecycle isn't perfect, but it's a start. Better yet Microsoft has been open about how and what they're doing to secure their software as they build it. Not a bad idea for Apple to develop a program like that, either by creating one, or disclosing the one that they have.
5. Repeat step 5 from the users list.

It's time for everyone, users from John Gruber to my grandmother, and vendors from the Microsoft Mac Business Unit to Apple themselves, to stop believing Macs are inherently secure and start realizing that they are simply, like any other computer, securable.

Followup: Now after discussing this post with a few of the other Minds and like minded folk it may have seemed that I'm suggesting Microsoft has figured security out completely and Apple just needs to copy what Microsoft is doing. I'm not suggesting Microsoft has the answer to creating the ideal operating system security program, just that they're closer than Apple is right now. Microsoft has made many admirable steps (as the nCircle folks seem to agree with me on) and Microsoft should be applauded for doing so. As they say, you eat an elephant one bite at a time. Microsoft seems to be getting that and as for Apple, well, I'm going start working on my own recipe for elephant, but don't wait for me.

How to most effectively beat a dead horse...

The trend of Month of Bugs continues unabated. Lets look at the history and get my arm chair analyst commentary:

• Month of Browser Bugs
• Leader: HD Moore
  
• Impact: Effective, highlighted the importance of browser security and pointed out a number of noteworthy flaws in a wide range of browsers including IE, Firefox, Camino, Opera, and Safari.
• Positives: Well researched, well orchestrated, spread over multiple vendors, including some vulnerabilities that affected multiple applications.
• Negatives: Hard to say considering this one set the bar, and many since have fallen short.
  
• Site: http://browserfun.blogspot.com/
  
• Month of Kernel Bugs
• Leader: LMH
  
• Impact: Similar to MoBB. Showed that fuzzable flaws weren't purely things found in "trivial" places like browsers, but in serious places like the lowest levels of operating systems.
  
• Positives: Took on an equally, if not even more, prolific area of system security. Lots of tasty PoC code.
  
• Negatives: I didn't play with many of them myself, but I've been told some of the PoCs were a bit unreliable, not to mention many were not remotely exploitable.
  
• Site: http://kernelfun.blogspot.com/
  
• Month of Apple Bugs
• Leader: LMH and Kevin Finisterre
• Impact: Definitely the dark sheep of the "Month's" the MoAB was littered with issues. While it did expose some flaws on Apple hardware/software it did little to dissuade Mac users from a feeling of invincibility and was taken less than seriously, even by information security types. Also the first "Month" to have a concurrent project providing on the fly patches to each days bugs.
  
• Positives: Had it's sights set on a group that needed to understand their vulnerability and went after a wide spread of Mac software.
  
• Negatives: The spread was too wide. Many of the flaws found were shrugged off by Apple users as "not Apple problems" (See: PDF and VLC). Coupled with the fact that PoC was spotty and nothing was ever released about the crowning "Unspecified Kernel Remote Fun" this was thought by many to have not been worth the hype.
  
• Site: http://projects.info-pull.com/moab/
  
• Month of PHP Bugs
• Leader: Stefan Esser
  
• Impact: At first I thought this would be a joke. Vulerabilities are reported every day in various PHP based applications. What is currently making this so effective is that they're only releasing vulnerabilities in the PHP core, not the poorly written Bullitin Board applications that get reported on daily.
  
• Positives: Focused on the real security problems with PHP, not the low hanging fruit in 3rd party PHP applications.
  
• Negatives: Well... this is where that beating a dead horse comment came from. PHP can seem like the majority of all vulnerabilities reported and it can seem like more PHP vulnerabilities are just overkill. Also no word yet on if fixes will be provided.
  
• Site: http://www.php-security.org/

So what's my final take? Well, there's a place for "Months" but they're only effective if well done. What makes an effective Month? Here ya go:

• Chose a relevant technology and make sure your vulnerabilities affect it, not arbitrary related software. If you say it's Apple vulnerabilities then fuzz iTunes, not VLC.
• Going a long with the last point it's also important to deliver what you promise. If you promise a kernel level vulnerability then it better exploit the kernels. If you promise it's remote then it needs to be remote, not remote if you can social engineer someone to run it with Admin privileges.
• Give us proof of concept code, otherwise it's too easy for everyone to say you're makin' it up.
• If you break it then fix it, or at least find someone who will.
• Be fair to the vendors and be fair to the users. Dropping 30 0-days doesn't help users. Being pushed around by a vendor who doesn't wanna fix their problems doesn't help users either.

All that said I welcome the Month of PHP Bugs. While I'm not a huge fan of PHP it is an important language that makes up many sites that are used daily all over the Internet. Stefan Esser has tried to improve security in every way he can, and for my money he's now responsibly using vulnerability disclosure in a way that will hopefully encourage the PHP team to make their language more secure, and that's better for everyone.

What's up with Milw0rm?

Anyone else notice that everyone's favorite place for the new public exploits, Milw0rm.com, appears not to be up right now?

I was going to give a look at the new PoC code that they supposedly have for the Quicktime flaws that kicked off the Month of Apple Bugs, but no such luck.

Anyone know whats up?

Tell me if I'm too open about this...

So this past Friday I was lucky enough to compete in the 2006 edition of UCSB's iCTF academic information security competition. I can't say I played nearly as much of a part as I would have liked to, as my secret weapon, a culmination of my skill in both attack and defense was 1) not quite completed and 2) not relevant to the way UCSB set up the competition this year, drastically different from most CTFs.

I'm not quite sure yet what I'm going to do with my application. It's really very specialized, only useful in a computer security competition, though I hope it will be both functionally complete and feature complete in time for Defcon, where it might be useful. I think it's going to get integrated into another upcoming project. Anyway this post isn't about that, it's about something else I realized though my work setting up Snort on my iBook.

Why on earth does the OSX firewall force you to open the firewall to access ports on the localhost? To run Snort, using MySQL for my back end database and the BASE package for my user interface I needed to connect to ports 80/tcp and 3306/tcp. Now that makes sense, to connect to localhost:80 to see my BASE setup (running PHP in Apache) while both Snort and BASE connect to 3306/tcp to get to MySQL. Now those connections make sense, but the fact that I have to open my firewall to access these ports is ludicrous.

Now I don't know all the inner workings of ipfw but this doesn't seem necessary, but simply laziness on the part of Apple. It wouldn't have been hard to set up the rules in such a way that the localhost connection would be available, but not allow connections from outside hosts. I know many people who would make use of this, such as the multitude of web devs I know, and it seems ridiculous that this hasn't been implemented. There are many conceivable reasons for needing port based services without running a server that needs to be publicly accessible. Is this really too difficult or too much to ask for?

There are many things that can be done to reduce the risk to security, but by far the largest in my mind is simply reducing the attack surface of a given system. This often means minimizing access and exposure by limiting a system to necessary services. In this case, while these services are necessary they are not publicly necessary, and it is merely unnecessarily widening the attack surface to force the firewall to be opened to run these services even when the only connections necessary will be from localhost.

I hate to say this is another example of Apple being too content, bordering on complacent, in their own sense of security and not trying as hard as they could to keep their leading position. I hope someone stands up and notices, before its too late.

Also congrats to Blue Blood Alpha, top 10 next year!

Did we not see this coming?

There's an easily exploitable critical vulnerability in OSX. (See here, here, here, here, here, and here.)

I'm torn on my reaction to this, but in different ways from most. On one hand it's not worth getting worked up, anyone who can be honest will admit there are going to be security problems in any bit of code as big as an operating system, or even a file system. On the other hand as Mac users there's largely been an undeserved sense of security that can only last so long and this is a serious threat.

I'm tired of the "Is OSX or Windows more secure?" game and I'm not even gonna try to throw out a logical opinion. I have a whole new opinion; operating s ystem security is not a zero sum game. Just because one may be more secure than the other does not make it uncompromisable. I drive a car that has an impressive safety rating. I have a friend who drives one who doesn't. If I'm in a bad enough accident I'm still dead, there's no "but Amber's car is less safe so why am I dead?" Maybe OSX is more secure than Windows (though we have yet to really see Vista in action) but a system level exploit is still a system level exploit with the same results, even against the "more secure" machine.

Windows users have been under fire for years. My own mother, a very intelligent woman, though not the most computer savvy, knows that it's a problem when her anti-virus subscription is about to run out and knows why the family computer has a firewall. Mac users have been in their ivory tower too long. If Apple users don't want to learn the hard lessons that Windows users once had to learn reactively then Apple users must learn proactively and I fear few are ready for that lesson.

I was chided once by an Apple Genius for having an Open Firmware Password setup on my system. I've heard too many "respected" Apple advocates suggest that an Apple will never need anti-virus software, and that built in security features like FileVault and Secure Memory aren't worthwhile. And then today a handful of bloggers considered an easy to exploit vulnerability as something to be put out of mind cavalierly.

It's time for the security conscious of the Apple community to stop quibbling about "us vs. them" and instead to educate those who still believe they are invulnerable simply because their operating system is from Cupertino and not Redmond. We have a responsibility, and I think rather than arguing, it's time to improve things for everyone.

An Excuse and Thank You

So I've been working on a blog post for most of the day, and it'll be a good one *crosses fingers*, but trying to get the cohearance I want is taking more effort than I'd like. I'm less than pleased.

In liu of that I'll leave you something short to chew on:

I added John Grubber's Daring Fireball back to my blog list recently because.... I don't know. Everyone seems to think he's the Mac Pundit and that his words are gold, but I never really thought so. Even so if I miss some word he says someone has to say I'm missing a vital piece of the Mac blog scene. He also seems to be the fountain of all baseless drivel that Mac people spew in regards to OS X security. I mean, I agree it's better than Windows, but it's not infalable, far from it, and possibly farther from it than we like to think.

For this reason I'd like to say a big thanks Thomas Ptacek at Matasano for putting Grubber in his place. It's reasons like this that's why I hardly pay attention to Grubber, and hardly ever will. Read away:

Daring Fireball - > Matasano

Before you start reading me...

...you should know who I read.

These are my influences, opinions I largely trust, or I'm at least interested in, who I think are worth hearing, even when they're wrong. These are the people I'll comment on, debate, and recommend. In many ways they're also people at the level I aspire to. (Please note, I'm an information security guy, you're gonna notice a pattern in that regard.)

My Noteworthy Infosec Reading List:

• Matasano Chargen: Possibly more than anyone else on this list (and it's a pretty good list) the guys at Matasano are the best example of where I want to be in a few years. Well, I'd like to be there right now but I think it's gonna take some time. Informed, opinionated, recognized, these guys run their consulting firm scoring some of the sweetest projects, working with some very smart people, and on their own terms. Not to mention they're fellow Mac fans.
• TaoSecurity: I've actually met Richard once, though I never spoke with him directly, a pleasure I hope to have since he lives in the same area. In addition he works in the same area, both of us are involved with Network Security Monitoring (NSM), and there's no denying that Richard is one of the foremost people in the field, and easily up for being the most noteworthy tied only with Marty Rosche.
• Security Sauce: Well I mentioned Marty already so it seems natural to bring up how much I enjoy his blog. As someone who's using intrusion detection systems everyday, and Snort is by far my favorite among them, I've gotta keep up with what this leader in the field is up to. Even if it's just starting at the sky (jk Marty, I enjoyed my astronomy class quite a bit).
• Hexblog: Reverse engineering is something I know very little about. Of the few things I do know one is that IDA Pro is the way to go. Also it's author, Ilfak Guilfanov is one of the smartest people out there when it comes to reversing, C++, and the guts of the Windows OS. Not a high volume poster, Ilfak's posts are usually worth waiting for.
• Add/XOR/ROL: Another noteworthy reverser, with very similar posting habits, Halvar Flake has to be on the list. Witty, and he'll make your binary applications bleed.
• Daily Dave: Love it or hate it, and lately many people have loved to hate it, Daily Dave is a place where many of the movers and shakers in infosec hang out. Dave Aitel is one smart mammajamma, and he's got a very smart collection of friends (and detractors) who frequent his list.
  
• Technobabylon: Here's the surprise one, even to me. I'm not a big fan of EEye. I'm not really into their products, their tools are marginal, their research never rocks my world on the whole, and I've heard many a very comment about their questionable ethics. I also just kinda hate when security research is done by 500 machines running fuzzers. I just think there's supposed to be more art to it. Regardless Ross Brown's blog is a pleasure to read. He's quite well informed, modest, and has great style.
• IATAC IA Digest: IATAC is a Booz Allen Hamilton consulting group that does vulnerability research and digital threat analysis for the Department of Defense. Most of that research doesn't get released, much to my chagrin, but they do publish this RSS feed that has links daily to 20 to 30 must read infosec articles. Kind of them.
• Symantecs Security Response Weblog: Of all the vendor weblogs, and I'm subscribed to quite a few, this one of the only one's (along with LURHQ, though that's been silent lately) that doesn't sound like a marketing campaign pretending to be a blog. A number of very smart people post to it, usually insightful, rarely plugging some product. Kind of nice to see a corporate blog that's not just for show.

Well that's it for now. That is of course far short of my whole OPML file. There are many personal blogs, other companies, lots of Apple and general technology related news. Also when al3x requested I write this post, which seemed a very good first post of a new blog, he only asked for security stuff.

Enjoy.