A blacklist file was found by an iPhone hacker and the internet is all abuzz over the possibility that Apple has a kill switch for applications. Well of course they do- Apple clearly shows by their insistance on the App store that they will control what gets run on the device- but I don’t think the blacklist file mentioned is that mechanism. Showing up in the location cache is a really sketchy area to put a file that blacklists applications, unless it is an exceptionally stupid instance of security through obscurity, so I think people misunderstand what it is for.

Now if I were Apple and I wanted complete control over what ran on the device I would only allow the device to run signed applications so that both the identity of the app author can be checked and the integrity of the binary can be scrutinized. I would insist on being the only CA, which I could do because all apps have to go through my store *anyway*, so why not include issueing certificates in the whole deal. I would then publish a certificate revocation list via SMS at regular intervals so that the user has no control of when an app gets blacklisted and I can count on it being pushed to the device.

This isn’t a foolproof design but it does provide pretty decent control over the platform. In essence it isn’t really any different from what console manufacturers do. People seem willing to accept that they don’t actually have control over the device the bought, and have certainly been willing to deal with the draconian oversight of cell carriers for years, so they would very likely accept this from Apple. So what if they suddenly lost they ability to use an application that they ultimately purchased from Apple?

Is this what Apple is doing? I don’t know. But given their aims it seems the best way to do it. I hate touch screen interfaces no matter how slick they are done, so I won’t be investigating myself.

~ Joshbw

It is now Joshbw, CISSP. I don’t think the cert says a great deal specifically about my App Security knowledge, that being a ten mile wide, inch deep sort of certification. The test wasn’t any less a pain because of it though, and at least it says I have the fortitude to make it through the long nights studying the optimal height and candle power of external lighting, how far away backup facilities should be, 8 million different security models, and what the initialization vector length of each encryption algorithm happens to be.

~ Joshbw, CISSP

Blizzard, makers of the extremely popular World of Warcraft game, now offer a token based authentication scheme to help with account hijacking. Two things strike me about this, first, that this is a freaking crazy world when hijacking WoW accounts is serious enough business to warrant this security and second, that we fundamentally need a better way of asserting identity when a FREAKING VIDEO GAME REQUIRES A TOKEN. I wrote a screed about that here, but I think this accentuates all the more a need for a new end to end method of asserting identity and establishing trust.

~ Joshbw

Perhaps I was a bit misleading in the title as this is a flaw in an internet connected coffee machine (why, oh why, do we need this) that allows, among other things, access to a connected PC.

There are a couple lessons in this. First, no matter how trivial your product, you very likely still need to worry about security if it connects to something that does have value. Second, your system is only as secure as all of the systems that connect to it, unless the system is inherently paranoid about connections. In this web 2.0 world of mashups, in the world of connected enterprise applications, our applications are not living in a bubble. They are connected to multiple other systems, and in most cases there isn’t a whole lot of thought that went into security over these connections. A web application may be horribly paranoid about anything it receives from the user, but then blindly accept data from internal systems without a thought. If any of those systems is flawed and you don’t validate input from them, your application is just as susceptible to attack as it would be if it didn’t validate user input.

This just further cements in my head the need to push threat modeling out to more people. I think the real value of threat modeling isn’t the complex threat trees that get built for risk analysis. I actually find those pretty worthless. I think the data flow diagram is the big thing. It is a convenient visual diagram showing where a process or feature is pulling data from and where it is sending the data to. Any source of data is a source of attack, and the DFD is a useful tool for identifying where further scrutiny is necessary. Any output source is a particular asset that might be attacked through your application. I think every dev spec should require a data flow diagram simply because it gets people thinking.

Finally, the last immediate lesson from this is that it is a scary time to be a client. The OS may be pretty solid but there are a million ways to execute code that seem perfectly valid from the OS point of view. Every connected application, any application that pulls data or opens data originally from a remote source, is a potential open door. If a freaking coffee machine can be a source of attack client security is in a lot of trouble.

~ Joshbw

Yes, its true, web applications scare the hell out of me.  Back in the grand old days of remotely exploiting rich client apps the attack of choice was buffer overflow (ignoring retarded macro attacks, for which the design was just ineptly flawed).  Sure, there were others, but at the time you could pretty much count on any given app having some unchecked buffer copy.  Today that is largely a solved problem, with static analysis tools being pretty damn good at finding such flaws.  Coupled with decent banned API rules, buffer overflows should be a solved problem, like small pox (don’t tell Apple or Adobe that though, they might actually get around to catch up with the rest of the world).  I find it laughable when a buffer overflow is found in modern software.

The thing is though, exploiting buffer overflows wasn’t trivial (well, pre-metasploit).  It actually required that a person have a decent understanding of how memory worked (so your average scripter or java developer was out in the cold) in order to craft an attack.

With web applications, the two vulnerabilities of choice are XSS and SQL Injection.  SQL Injection is pathetically simple to protect against and yet is horribly prevelent.  On a US UTF-8 only website that doesn’t need to accept HTML, XSS is also very easy to protect against (unfortunately it quickly gets complex when you internationalize, or decide to accept HTML).  These attacks are often disgustingly simple, but work well.

That concerns me a great deal, but a well designed website can put up a decent defense.  That isn’t what really scares me.  It is the fact that many of these web applications store very sensitive data, anything ranging from PII, to one’s entire collection of documents.  It isn’t just that the attacks are so simple, but that the payoff (or cost depending on which side of the coin you are on) is so large.

So enter something like Google, which wants to store your emails, health records, personal documents and files, payment information, and everything else you might value.  It takes one tiny little flaw and all of that is exposed.  It takes one well put together phishing site, and it is all exposed.

What keeps me awake at night is knowing how much there is to lose from one tiny little mistake.  What scares the hell out of me is how much data is stored, how sensitive it is, and how easy it is to find vulnerabilities and exploit.  For crying out loud, bots are doing SQL Injection attacks as we speak.

(what also scares me is that many people actually think HTML and Javascript in a browser creates a compelling competitor to rich client apps.  It will be a cold day in hell when a web app can provide even a marginally compelling experience versus the likes of Office.  Even flash and silverlight are poor replacements.  Adobe is high as a bloody kite if they think that an AIR version of Photoshop is a remotely good idea)

~ Joshbw

Reading a lot of Bruce Schneier recently, and his excellent take on the security mindset, as well as working on a full security development lifecycle at work that is focused on getting security into each stage of the application, I have security mindset on the, er, mind.  Bruce phrases it much better than me, but I think the security mindset is being able to see a scenario or situation and enumerate the potential mischief that could be enabled there.

So I see that Northwest is planning to try out paperless e-tickets using PDAs and similar smart devices.  Essentially the screen displays a version of the ticket to the screen and that gets scanned.  I already think that the current print your own ticket is ripe for abuse (for example, it wouldn’t be hard for me to make a fake ticket that got me through the ticket-required TSA checkpoint), but my mischievous little mind is already at work when going over scenarios that a dynamic screen that I control could present.  As an exercise for the reader, to flex that security mindset, what can go wrong here?

~ Joshbw

Jeff Atwood of Coding Horror posted a flawed article on why session expiration is bad.  The gist of his article is that it presents poor user experience which should trump the security concerns.  I will not deny that the user experience with session expiration is less than ideal, the whole idea of sessions to begin with is an ugly hack to get around the fact that HTTP is stateless and that the best end user authentication scheme that we have come up with is a login screen with easily stolen personal credentials.  Until a better scheme is brought up, which will be no small thing, it is something that we just have to live with.

That is not to say that the user experience can’t be improved.  Saving a session state, so that when the user is forced to authenticate again they don’t lose progress, is imminently doable and would improve the experience when sessions expire.  Getting rid of session expiration entirely is a horrible idea though.  Jeff seems to think that the risk of persistent sessions is someone sniffing the sessionID over the wire and that SSL/TLS completely mitigates that.  To me that is a low concern (sensitive data should always go over an encrypted channel, but network sniffing is rarely efficient anywhere outside of an intranet), relative to the threat of CSRF, cross site script attacks against the cookie storing the sessionID, and if the HTML 5 working group gets their way, XMLHttpRequest going across domains and passing cookies (fortunately it seems both FireFox 3 and IE 8 are inclined not to do so- take that Opera).  Regardless of how long the session is valid there is some risk from these attacks, but having persistent cookies extends the length of exposure after the sessionID has been compromised.

With the widespread presence of cross site scripting and the relative lack of protection against CSRF these are very really security concerns that are highly likely to be present on most websites.  If neither were present it would be safer to have longer sessions, but I think it would be naive to assume their absence.  Defense in Depth is a mantra for a reason.  Yeah, it sucks for the user somewhat, but erring on the side of usability is a Windows 98 style mistake.

What bothers me about Jeff’s post isn’t that a developer feels that way, sadly that is pretty common, but that a fairly competent developer with a large readership is evangelizing an unsafe practice.  It is, in effect, the same thing as Joel Spolsky of JoelOnSoftware fame advocating the avoidance of Exception Handling.  It is a bad practice and it concerns me that someone with such high visibility would actively be promoting it.  I think it also illustrates how security ignorant developers really are, when even such senior individuals don’t understand how bad a suggestion really is.  I could be wrong though, Jeff may understand- many of his past points stress usability and he could be of the mindset that usability trumps all other concerns (it is important, but it is one of many considerations that must be weighed).

~ Joshbw

So I upgraded WP to 2.5 and forgot that I tweaked how some of the Widgets outputted their HTML (it bugs me that I can’t just override the widget functions in my own PHP file, but sadly PHP doesn’t support such functionality).  Thus there is some formatting wonkiness in the standards compliant browsers (looks fine in IE 7 though; render what I mean not what I type) when I upgraded and overwrote my changes.  Fixes will be forthcoming when I have free time, but I am in the process of signing paperwork for a new place to live AND working on several projects at work AND working on several projects outside of work (like modifying phpBB to use prepared statements when the mysqli interface is available and when connecting to mysql > 3.0, since a friend of mine got burned by a retarded MOD that changed input without sanitizing it that in turn allowed for a SQL injection).  Thus free time is an undefined variable at the moment.

~ Joshbw

Following up yesterday’s post about the firewire hack that lets you read memory over firewire, it was noted in the article I linked to that the hack did not yet work in Vista.  I’m guessing that this is because of the copious use of address space randomization by the OS, which would likely make any attempt to modify the windows password code at a fixed address pretty much worthless.  That said, if you knew a particular signature for the code it seems like you could just dump the ram to your external firewire device, scan it for the signature, and then figure out the randomly created offset; however it might be pretty difficult to figure out that signature in RAM in the first place.  This is quite a bit away from my area of expertise, so thoughts from anyone a bit more knowledgeable in this area?

~ Joshbw

There is currently a fluff piece article on hijacking Windows via Firewire floating around.  Essentially the attack allows someone to network via Firewire, directly access the memory, and futz with the windows password logic, effectively bypassing it.  To this I say, well Duh!  I’ve maintained for quite a while that Firewire was inherently insecure.  It by design requires direct memory access, which in this case I think is a very bad idea.  Internally, a myriad of components use DMA to reduce the load on the processor.  Your networking card really doesn’t want to pester the CPU every time a packet arrives, nor does your SCSI controller really want to bother the CPU every time a sector is read.  DMA is a necessity within the computer case, but you inherently need to trust the contents of your case to do their job.

The difference with Firewire is that the component that has DMA is now external to the system.  Unlike ethernet, where the ethernet card has DMA but the external ethernet connections do not, Firewire is designed so that the external devices have DMA, and said devices could be even be another computer.  At the time of Firewire initial adoption Apple shipped it on all of their PowerBooks, so feasibly carrying just a laptop you could sneak into a corporate important person’s office and exploit the DMA of firewire to access their desktop’s memory.  Now there are tiny little x86 systems with an ethernet port, on board flash for storage, firewire and USB ports, and everything else you would need for an attack inside a pocket instead of inside a backpack. Either way, a company insider could feasibly exploit it.

I can see the logic at the time for the design, where CPUs were slow so you can’t take a hit interfacing with them, eSATA wasn’t an option for removable disks, USB 1.0 was slow (and also gave a CPU hit), etc.  The arguments for allowing DMA were plentiful, and security doesn’t seem like a concern during the specification process during those days. (Bluetooth 1.0 or 1.1 anyone?  Heck, even the Bluetooth 2.0 working spec considers security as an afterthought, or how about 802.11 that launched without even WEP)

What bothers me about this article is the level of irresponsible disclosure on the part of Adam Boileau.  He claims to have notified Microsoft two years ago and is releasing his tool now because MS didn’t act.  If this was a critical vulnerability in SQL Server or IE, I wouldn’t have a huge problem with it (I don’t think full disclosure is a great thing, but at the same time, if a company sits on a critical for two years that is also less than ideal), but the problem is that this is essentially a critical vulnerability in a specification.  Asking one vendor to essentially completely break the spec in their implementation (especially a vendor that gets hammered as often as they do for not supporting certain standards and specifications) is naive (how many devices would be broken if the host didn’t allow DMA).  MS can champion changes in Firewire (best of luck, since Apple rules that roost) but they don’t have control over it, and any change is necessarily going to be long and arduous.  Boileau should have approached a multitude of vendors with his proof of concept, from OS manufacturers (MS and Apple) to PC manufacturers (Dell leaving firewire out of all of their business lineup unless specifically added, with a note about security concerns, would catch IEEE attention), instead of dropping a note to MS and expecting that problem to take care of itself.

Apple probably wouldn’t have listened, they don’t really have a presence in corporate America where this attack would be most damaging nor do they exude much concern over security, but PC manufacturers likely would be a bit more receptive(hey, we get to cut out a component and claim it is to make our customers more secure in the same breadth).  Hitting MS alone and expecting them to muscle the rest of the industry into changing is essentially asking them to take an action that in the past has gotten them in a lot of trouble. Even if all parties concerned were committed to change though, it would take time to update the specification with all of the politics involved, and they can’t just drop support for all existing firewire devices on the market now. At best you could change certain default behaviors.

I guess the lesson here is that if you subscribe to the notion that full disclosure is morally justified so long as you have given the company proper notice, make sure the company has any power to realistically change the issue you are complaining about.  Otherwise you are just sort of an ass, taunting them with a vulnerability they don’t control.

~Joshbw