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

It looks like everything is up and running now, more or less.  I am still tweaking the theme a bit and working on some lingering browser compatibility issues.  I’m kicking myself for starting by modifying an existing theme rather than just beginning entirely from scratch, as at least a couple of issues were the result of style issues I missed when editing the original theme.  I’ve decided that I really don’t like the fact that I can’t override user defined functions in PHP as that would have made things much easier.  Now I have to compulsively look at the change lists during each update to see if I have to merge changes, which is a pain in the butt.

So obviously I have decided to roll my own blog rather than use a blogging host such as Blogger or Spaces.  I saw benefits going both routes.  With a blog host security becomes their problem rather than mine, and considering the frequent patches pushed out for all of the existing blogging software (WordPress, Moveable Type, etc) this is a major consideration.  Hopefully I have locked things down enough that even if a zero day that grants admin functionality is released other preventative measures will still protect the admin controls (that whole defense in depth concept).  Granted that will be little condolence when some new XSS is found in the blogging software and a billion comment spam bots post attack messages with just commenter permissions.  The other major benefit of a bloghost comes from the fact that while they may have millions of users of their software they have very few users on the actual physical machines.  With my shared server cheapo LAMP host I can’t say the same for this site, as dozens of other random net users have shell accounts on the box and are hosting their questionable code.  I like Dreamhost, as they tend to offer pretty good service with gobs of storage and bandwidth at very cutthroat prices, plus they have a pyramid scheme where you make money off of people you refer (hence the presence of the "Hosted by Dreamhost" links… just hoping to milk some folk looking for a cheap but relatively good LAMP host), but even if they are great as a shared server host it doesn’t change the fact that they are ultimately a shared server host.  I don’t exactly keep anything I value sitting on their hard drives because of that, so I was a little leery of investing time in a blog hosted on servers I don’t have a great sense of security concerning.

That said, hosted blogs have several drawbacks.  Many are designed around the idea of a social experience, e.g MySpace, Facebook, etc, and I think the focus on social components in those cases detracts from them as specifically blogs.  Then you have your dedicated blog hosts that skip much of the social stuff, WordPress.com, Typepad, Blogspot, etc.  In the case of WordPress.com and Typepad it seemed that I would be just as much at the mercy of the respective wordpad and moveable type flaws as if I hosted my own blog, but without the benefit of being able to take my own measures to lock things down.  Blogspot is such a pit of malware that Google de-lists it regularly, which given the fact that Google freaking owns it isn’t a stellar endorsement.

Finally, with any of the hosted solutions I don’t have much control over things.  The level of customization is limited and usually requires people to jump around hoops (in the case of myspace it seems that every user must embed some music, make copious use of blink tags and scrolling text, and have an animated background, which I sort of got over in 1994 back when all of those things were all the rage).  When it comes down to it I find it easier just to fire up textpad and edit the layout directly in the source rather than muck around with some style editor or play with layout templates and modules.  I like that I am the only one that gets a say over whether my site has ads (none at the moment, but when I am a super Internet star that may change), where those ads are, how big they are, etc.  In the end being able to control everything about my site trumped being responsible for its maintenance.  And here I thought it would be nice to leave that sort of thing for when I was doing my real paying job. 

So watch out, I have complete control of the layout, free to completely abuse rounded corners and segregated content panels.  I also have my resolution set to 1920×1200 so the site may not be sympathetic to you folks rocking the 1024×768 (come one guys, my 12" tablet PC has a better resolution than that).  Tweaks are likely to trickle in throughout the month as I decide to ad or remove stuff, or finally decide to install safari in a VM and see how bad the browser mangles it (Apple security is so abysmal these days that I won’t run their stuff on my host OS).

Anyway, any early wayward readers that have stumbled upon the site, feel free to use the comment thread to leave feedback on its design.  I haven’t spent a great deal of time testing its layout. 

~ Joshbw