More SideJacking

Our sidejacking stuff was named one of the top 5 hacks of 2007. Since then, we've noticed a few more things about it.

To recap: websites typically encrypt your password so it cannot be sniffed, but then send you an unencrypted "session-id" for that session. The session-id is either some random data in the URL, or more often, random data in an HTTP cookie. A hacker who sniffs the session-id can then use it to gain access to that session, which usually means gaining access to the account. Thus, the hacker can read your Gmail/HotMail/YahooMail, look at what books you've ordered from Amazon.com, control your MySpace/Facebook page, and so on. The hacker still cannot get your password nor your credit card number, but can most everything else.

SSL doesn't protect Google Mail

When I originally tested sidejacking, I found that there were some solutions. For example, Salesforce.Com by default encrypts EVERYTHING over SSL. While some of their customers choose to use non-SSL for some reason, the majority of their customers are protected.

SSL is not always complete. A good example is Gmail. In theory, using the HTTPS version of Gmail should protect you by going to https://mail.google.com/mail, but this doesn't work as you think. The JavaScript code uses an XMLHttpRequest object to make HTTP requests in the background. These are also SSL encrypted by default - but they become unencrypted if SSL fails.

When you open your laptop and connect to a WiFi hotspot, it usually presents you with a login page, or a page that forces you to accept their terms and conditions. During this time, SSL will be blocked. Gmail will therefore backoff and attempt non-SSL connections. These also fail - but not before disclosing the cookie information that allow hackers to sidejack your account.

This happens to Dave Maynor a lot. He leaves Gmail running using HTTPS. We sit down at a coffee shop. He opens his laptop to read a file. He doesn't even want to connect to the WiFi hotspot. However, the WiFi stack connects anyway, and Gmail sends out his session-id. I then connect to his e-mail account before he realizes what he has done. This has happened a lot, he has become very paranoid, and the first thing he now does whenever he sees me is verify his WiFi is turned off.

Hacking tools outlawed

Germany, and now the UK, outlaw the distribution of hacking tools. My sidejacking tools (Ferret, Hamster) are exactly the sort of thing they outlaw.

Does anybody know the legal ramifications of this? Does that mean I can no longer travel to those countries? Does that mean I can't travel anywhere in the European Union? BlackHat Amsterdam is coming up, and I need to know whether I shouldn't go.

This also begs the question why I distribute these if they are hacking tools. The answer is: because they demonstrate the problem. People don't believe a problem exists unless they can see it for themselves. Hackers don't need my tools - they can use the standard Wireshark product and the Mozilla cookie editor to do the job instead. What my tools do is make it obvious so that a reporter can point-and-click and hack their own accounts. Web 2.0 is fundamentally insecure because data isn't encrypted (except for passwords and credit card numbers). This insecurity exists because people can't see for themselves how the problem affects them. With my tools, they can see the danger they are in, and sidejack their own accounts.

This is part of living in a free society. Vulnerabilities released with Proof-of-Concept code help us understand the vulnerability, and security in general. Conferences like BlackHat are much more interesting because presentations release code that prove their assertions. We don't have experimental evidence in our industry, all we have is code.

Sure, the downside is that it helps hackers, but in the end, it's the defenders that win. Hackers had the edge over Windows for many years. Windows XP SP2 caught up with them, and now Vista is ahead of the hackers. The reason for this was the free and open society where we discussed and proved problems with code.

Which cookies to sidejack?

One of the problem with my tools is that they don't always work as easily as I would hope.

The basic problem is that I don't see the "Set-Cookie" sent from the server to the browser in SSL. I have to guess what that cookie is by seeing how it is used. A cookie is attached to a directory, and is sent for all accesses to that directory and subdirectories. If I see cookie "x=y" sent with subdirectory "/foo", it may actually have been attached to "/". If the browser accesses directory "/bar", I won't know if I should send the cookie or not.

One solution to this problem is to create my own accounts, and within my own browser look at where the cookies have been set. Unfortunately, the cookie editors I've used only show the permanent cookies, not the temporary cookies. In order to crack open the temporary cookies sent via SSL, I have to either rewrite a cookie editor or do a man-in-the-middle decryption of the SSL stream.

However, for HotMail, Gmail, etc., I've made some guess about what where the cookies are attached, and hard-coded them into the Hamster source code. These seem to work pretty well.

The bad part about this is that my tool may not work for a website. This will lead people to the false sense of security that sidejacking isn't a problem. However, sidejacking is ALWAYS a problem: there is no way to fix it other than encrypting the data with SSL. Just because the program guesses wrong doesn't mean that a hacker can't figure out the correct guesses and gain access to the data.

New Quicktime Flaw, this is not Deja Vu

No really. Its ANOTHER QuickTime flaw. It also involves RTSP. It was posted to Full Disclosure on Thursday afternoon. We have verified a crash on the latest OSX and are currently researching if it can lead to remote code execution and which platforms are affected.



The advisory is here:

http://aluigi.altervista.org/adv/quicktimebof-adv.txt

SCADA the easiest target...

I remember once talking to an older gentleman who was responsible for some critical infrastructure networks and the gear that made them up. He did everything up shake his fist in the air and call me a whipper snapper over my mere suggestion that SCADA security should involve more than just making sure you have proper documentation of your support agreements with the hardware vendors. He then preceded to tell me what a nusicace people like me are because even things like simple port scans could bring down SCADA gear and I had no regard for the delicate nature that people like his staff have when it comes to this equipment. He then punctuated his rant with “and my equipment is not internet accessible so I am in no way worried about your so called hacker threat”.

I was flabbergasted that actually lives depended on this gentleman.

I thought of this story this morning while reading this news article.
http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/01/11/wschool111.xml
Just because you do not think you have an internet connection doesn’t mean you are not at risk.

Anybody that spends anytime with me knows that I change phones with the same regularity most people change socks. Since some of the work I do is around mobile device security I at any given time have between 2-4 active cellular number on my person or in my bag. A phone will average about 6 2-3 months as my primary communication device before I get bored and switch it with a newer, shiner model. I just switched from the ATT Tilt (otherwise known as the HTC Kaiser) back to a Blackberry Curve 8310. Now I want to note this was not my first HTC phone and I find them to be well designed, functional, and generally good vehicles for Windows Mobile.

The Tilt suffered from a major flaw with its lack of battery life. The battery sucking blame seemed to fall squarely on the head of the 3G radio. I found a ton of stuff on the web about tools that can force it into EDGE mode to save battery. This is a good solution but then I end up with an expensive phone with nifty features I cannot use because of battery drain. The Microsoft Direct Push email is pretty good but all in all I missed my Blackberry so I switched back.

Terminator TV Show

http://www.aintitcool.com/node/35197

From Ain't It Cool News: You can watch the first episode of the new upcoming Terminator TV show now on Yahoo TV before its January 13th premier. I watched it and thought it was pretty decent, much better than T3. It will be nice to have something to fill the lack of good sci-fi on tv now, tha is until Fox cancels it.

Wow

I mean...wow...

Things to do on Christmas break...

MSN messenger built-in AV

The two things that hackers do is (1) run a debugger so that when a program they use crash (like Firefox or IE) they can figure out why, and (2) run a sniffer so that they can look at their own packets.

While sniffing my MSN connection, I saw a small XML file being transfered from the server. It has a bunch of Policy.Shield.Config.Block elements consisting of regular expressions (the ones I got are listed below). Microsoft blocks messages containing these strings.

Googling items on the list find a bunch of interesting information. To start with, you find links to anti-virus information for trojans/worms/viruses named in the regexp. I also found this story on Slashdot that calls this filtering "censorship" (because, of course, everything that Microsoft does is a conspiracy). This blogger found a much longer list back in August: apparently, Microsoft is constantly editing the list. This other blogger found a different list 12 days ago. the changes found in only a few days suggests that Microsoft is constantly monitoring what's going on, and as threats appear, they quickly move to counter them.

Apparently, Microsoft blocks these patterns on the server. I wonder why this list is sent to the client. Is it so that the client can display the server policy to the user if they are curious? I couldn't find where this list is displayed in the client, although I wasn't looking very hard. The earliest reference to this list I can find is 2005, maybe I need a newer client to display the list.

The items in this list identify "wormable" messages. There are several types of MSN-worms.

One type of a worm would exploit a vulnerability, like this worm from 2002 that exploited an Internet Explorer bug through JavaScript. Microsoft uses/used Internet Explorer to render incoming instant messages, which meant that any IE bug was a potential MSN worm.

Another worm is more like a virus. It sends a file, or a link to a file on a server, to everyone in the MSN buddy list. Once the a victims infect themselves, the program then scans the new buddy list and sends a copy to those friends as well. Thus, the worm spreads from friend to friend, leaving a virus or trojan or botnet behind.

Another worm is even easier. The last filter on the Microsoft list is a simply a website that promises to list all the people who have deleted you as a buddy -- if you just give them your username/password. Of course, what it really does (probably) is send a message to all of your buddies advertising the website. I would guess that it also uses the same login credentials to get into your HotMail or other Windows Live services. My guess is that it's ultimately trying to harvest lists of e-mail addresses, which are worth money in the hacker economy (for use in phishing attacks).

I find attacks interesting because what it teaches us about human nature. Presumably Microsoft added a filter to "blockdelete.com" because it was being effective. This means a lot of people are insecure about being removed from a buddy's buddy list.


\.pif
\.scr
miralafoto/foto\.exe
tufoto
verti2/fantasma\.zip
imp\.exe
bush-gracioso\.exe
get-messenger
album\.zip
photos\.zip
2nnvc7
blockinrio
messaging-names
images\.zip
myalbum2007\.zip
img301\.zip
img1756\.zip
hoto234\.zip
pic\.zip
g038_jpg\.zip
secretimages56\.zip
love33\.zip
monica\.zip
img-0012\.zip
imag091307\.zip
pic1273\.zip
img-3773\.zip
img-6434\.zip
img-8197\.zip
img-0950\.zip
picts-7053\.zip
pictura002
mypictures\.zip
image25\.zip
pics\.zip
msn-check-contacts-54\.tk
blockdelete\.com

Me, the office, a green laser

I blame Thinkgeek.

New Apple Problem

http://www.securityfocus.com/archive/1/485237/30/0/threaded

You know, the one thing you don't want to have when everybody needs to updated due to a critical problem is a vuln in the update process.

Bellsouth DNS goes belly up...

Oh wow. It seems like all of Bellsouth’s DNS for DSL customers is out. I switched mine to OpenDNS: 208.67.222.222. It cleared up my issues.

The thing that makes candy sweet...

UPDATE: RIght after clicking submit I saw this appear. New Quicktime exploit that targets Tiger and Leopard. The list of affected systems from the advisory:
Version: 1.0 (+leopard_ppc +leopard_x86 +tiger_x86 +tiger_ppc +win_xpsp2)

Wow the Macalope shocked Apple fans every with a statement that is reminiscent of hooves on a chalkboard.

You might be surprised to hear the Macalope agree with Maynor, but he's right.

To start with, lets settle that dydl isn’t a library so Apple’s ASLR implementation is just peachy thread in his comments section. ASLR is more than just randomizing libraries. ASLR stands for Address Space Layout Randomization not Library Space Layout Randomization. Libraries are just one piece of the pie that also includes where the stacks and heaps are located and where the executable image gets based. Keep in mind that half implementing ASLR is about as useful as halfway closing a hatch on a submarine while its diving. The new QuickTime RTSP bug proved that by taking advantage of just a few components that are statically loaded in Vista. Therefore, you may get a gold star for effort in the end you can be sure that an exploit writer can take the time to find the overlooked areas.

The Macalope suspects that the free keggers the company throws for security professionals and, well, everyone and their alcoholic mother don't hurt, either.

Ah there is the Macalope we know and love. If somebody says Microsoft did something right they must be bribed. Sorry, that’s not the case, I just think some simple things they have done will increase the overall reliability and safety of their applications. Take the Security Development Lifecycle and its list on banned functions. It not super technical all they did is identify unsafe functions that are hard or impossible to use safely like strcpy, sprintf, and scanf to name a few, and forbid their use. They even developed “safe” versions of the functions that do proper bounds checking and such like strcpy_s. This would have helped prevent the current QuickTime snafu since it was just a simple stack overflow using bcopy incorrectly. This isn't secret Redmond mojo, its just common sense. If it hurts to stick your hand in a fire, don't do it. If programmers can't use functions safely, take away the functions.

Something else Microsoft does that I really think is useful revolves around fixing vulnerabilities. So when they get a vuln report they don’t just fix that problem but also audit the surrounding code and look for additional vulnerabilities. So this RTSP bug is interesting. You may remember MOAB #1, a RTSP buffer overflow in the rtsp address. The current vuln is in an overly long content field. The problems are not directly related but they sure are neighbors. In fact I find it hard to believe you could fix MOAB #1 and not grep the source tree for other potentially bad function use.

Enough about Microsoft, they still have a long way to go. For instance trying to get a security patch for a Windows Mobile device is like trying to land a UFO in a glass of water. That is right UFOs and Windows Mobile security patches both do not exist. I am a big fan of the iPhone because you just plug it in and it will automatically check for updates.

"Vastly" is debatable. The structure is there, Apple just needs to implement it properly. Many of the items Ptacek points out are user-correctible. Apple could be just a dot release away from fixing them if it wanted to.

I stand by the “vastly” statement. You see Apple’s problem in security is not the technology. OSX has a great pedigree with its FreeBSD ties and all these problems previously mentioned are fixable. The problem I see with OS is Apple. Unless I am mistaken the Apple Security team if 4-5 people, or at least it was last year at this time. That is like having one police officer patrol New York City, its ridiculous. You can tell they are understaffed by looking at the patch cycles. An interesting thing to note is that when Microsoft releases patches for their desktop Oses I’ll write PoC samples to see if they could affect Windows Mobile. Why is this important and what does it have to do with patch cycles? OSX ships with a lot of open source software and they occasionally have flaws. Take Samba for instance. Apple shipped Security Update 2007-07 on July 31st (the day before the Blackhat Briefings started) that fixed a number of Samba flaws. The problem is that the Samba project announced the fixes for these flaws in May. That gave resourceful attackers a 3-month window to wreck havoc. The moral of this story is that hackers can take advantage of an understaffed development team just as much as a buffer overflow. I have a list of all open source software that ships with OSX and I pay close attention to any security advisories regarding them. You never know when something innocent can lead to a root compromise.

To continue the Apple Engineer problem sometimes bugs will reappear. Doesn't this look familiar (from the ISC handlers diary). Sure it may be the Japanese version of the software but overly long content type fields are a known problem, why not add a QA test case for simple stuff like that? Or even better, fuzz applications before shipping them.

Apple needs to take security seriously. They need a CSO and they need to stop believing their own press. Take the iPhone, the update features aside I think it has been an abysmal failure in terms of security as exploit after exploit is discovered and released. I think that the iPhone saga illustrates the point that as more people get their hands on OSX the problems will continue to grow.

And that’s all I have to say about that.

IDA Pro 5.2

I just installed it and the first theing i loaded is the FieldTest.app. I love random strings, I can't find in the GUI where "what do I update here? in column %d" is used.

More RTSP

WabiSabiLabi answered my question on their blog in no uncertain terms.

The exploit for sale on their site is not the same as the RTSP exploit currently being exploited in the wild.

The auction states the flaw affects 7.2 which is an older version but I wouldn't be surprised if with some tweaking you would find similar vulnerable code in 7.3. With that being said I think Apple should buy it. Think about it, they have one QuickTime vuln in the wild and another for sale. It would just take one more to make a perfect storm! Plus its only a thousand euro. Although with the current exchange rate that's like 9,213,456 dollars, but hey, Apple can afford it. To me that would mean that a company is taking the security of its clients more seriously than its image.

Mozilla kinda does it with their bug bounty program and I am pretty impressed with their response time to flaws.

IDA Pro 5.2

http://www.datarescue.com/idabase/52/index.htm

IDA Pro 5.2 is available now. Two big features are improved ARM support and native iPhone binary support.

Apple Quicktime RTSP update

Milw0rm currently has 3 Proof-of-Concepts for the QuickTime flaw that I worte about earlier.

PoC 1

PoC 2

PoC 3

The newest one by Yag Kohha has refined the attack to an almost weaponized state. This means that anklebitters, bot masters, and a general assortment of unsavory types now have everything needed to easily take advantage of the flaw.

The developers of another PoC modified it after Symantec released a blog post declaring that standard buffer overflow protection will mitigate the vulnerability in some cases. The exploit has also been tweaked to work via a redirection attack on IE7, Firefox, and Opera. Safari on Windows seems left out, but that does not mean you are safe if you use Safari.

We are also receiving some scattered reports that it is showing up in the wild but have not been able to validate them. Because malicious code can be embedded so many different ways it is advisable to following the US CERT suggestions here or remove QuickTime completely.

Although the published exploits target Windows, the flaw is present in OSX so Apple users should be cautious as well.

An interesting note is the most robust of the exploits makes a derogatory mention of WabiSabiLabi Labs, the exploit auction site. WabiSabiLabi has a QuickTime exploit for sale now that lists QuickTime 7.2 and Windows XP as the targets. You have to wonder if this is another case of a researcher using vague details to find the same vulnerability.

Keep in mind that the analysis shows that all the exploits rely on a known offset for successful attack. ASLR could mitigate these attacks by changing the load address of components to make the attacks nothing more than Denial-of-Service. If Apple had enabled QuickTime to take advantage of ASLR in all of its components, this would be a non-issue. Instead they put you at risk.

UPDATE:

I thought a screen shot of what the warning message on Vista with IE7 looks like would be appropriate.

Who doesn't need a break for 219mph cars on public roads?



From Autoblog.

Al Gore's movie website hacked...

Infoworld story

Even a former Vice President should update Wordpress.

Update:
It looks like the blog in question was running 2.0.3 of Wordpress.


THe current version is 2.3.1.

New RTSP Quicktime flaw affects both OSX and Windows

Apple’s unsafe and cavalier attitude towards security puts not only Macintosh users at risk, but also Windows users. The latest QuickTime flaw demonstrates this. QuickTime is Apple’s multimedia player. It’s the part of iTunes that plays the music/videos, although you can install it separately without iTunes. Windows users who have iPods or attempt to play “.mov” videos will likely have QuickTime installed.

QuickTime is written in an inherently insecure manner. This puts at risk anybody who uses it, Windows or Macintosh. There have been a constant stream of bugs in QuickTime published over the last couple years, such as the famous 0day that won a Hack the Mac contest.

Address Space Layout Randomization

The most interesting bit of these latest QuickTime vulnerabilities is how they react with “Address Space Layout Randomization” or “ASLR”. ASLR is a technique of mixing things up in memory so that hackers cannot find them. This is armor that prevents vulnerabilities from being exploited in practice.

Apple announced ASLR as a feature in their latest version of the operating system, Mac OS X 10.5 (TigerLeopard). However, Apple largely lied. While some insignificant items were indeed randomized, nothing that hackers are interested in where changed. If Apple had fully randomized things like Windows Vista, then this QuickTime vulnerability would (likely) not be exploitable.

Does this mean that this vulnerability is not exploitable on Vista version of QuickTime? Humorously, Apple still has a problem here. Vista ASLR requires a little cooperation from developers. Developers have to link their code with the flag /dynamicbase. This sets a bit in their compiled code that tells Vista it can randomize the layout of memory. Apple developers do not set that all-important flag, telling Vista NOT to randomize their layout.

Even though Apple didn’t set it, you can set that flag yourself. It’s just a single bit within the DLL file. If you flip that bit, then Vista will load QuickTime in a randomized fashion. As far as we can tell, QuickTime runs just fine under Vista with the ASLR bit set.

The original location of QTOControl.dll.

What it look like in PE Explorer.

After its been modified save and copy it back. (note that Vista requires admin privs to copy the file)

The new location of QTOControl.dll.

Watching a video.

QuickTime has multiple executables, all of which must be changed in this manner. We set this bit on all the DLLs, then tried the latest QuickTime exploits. As we expected, setting the flag stops the exploits from working, protecting the system.

Changing a major application like QuickTime is not as easy as snapping your fingers, but Vista has been out almost a year now so it seems like support should have trickled down now. Apple should have enabled randomization in QuickTime.

RTSP handler

The easiest way to exploit QuickTime was URLs that caused it to be executed directly. Both IE7 and Firefox 2.0.0.9 have removed the rtsp:// handler. This makes it harder to reach QuickTime. Users must manually download a QuickTime file and play it, rather than simply following a link. When trying to play QuickTime files, Vista will warn the user that they may be accessing malicious content.

Below is what message I get while trying diffrent attack methods via Firefox.

Unfortunately, Safari still supports the rtsp:// handler, meaning they are at much greater risk than IE/Firefox users.

The Proof of Concept (PoC) Exploit

Below is a screen shot of gdb attach to the QuickTime Player after the exploit was successful. It is crashing because of an attempt to dereference EAX, which is 0x41414141. You can see in the instruction before EIP that EAX is loaded from a deference of EBP+0x10. Looking at EBP the pad the author of the PoC chose, 0x41, can clearly been seen.

Tracking down this bug is easy considering the information given by the PoC author about it being a stack overflow. The problem is a lack of length checking in the _EngineNotificationProc before calling a function called BlockMoveData. BlackMoveData is just a wrapper for bcopy(), a notorious bad function from a security standpoint.

Microsoft has impressed the security community with its dedication to secure coding practice. It bans dangerous functions like bcopy(), and forces its programmers to use safer versions (such as memcpy_s(),the safer version of bcopy()). Apple has not adopted secure coding practices; they still use known dangerous code such as bcopy(), sprintf(), strcpy(), and so on.

Breaking on the _EngineNotificationProc.

(gdb) set disassembly-flavor intel
(gdb) break _EngineNotificationProc
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_EngineNotificationProc) pending.
(gdb) attach 316
Attaching to process 316.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ..................................................................................................................... done
Breakpoint 1 at 0x174816fd
Pending breakpoint 1 - "_EngineNotificationProc" resolved
0x93442446 in GIF_CDBandDecompress ()
(gdb) c
Continuing.

Tracing the bad data.

0x174329bc in INet_GetFieldBody ()
1: x/i $eip 0x174329bc : mov edx,eax
(gdb) x/20x $ebp
0xbfffc908: 0xbfffcbc8 0x174820d8 0x17bdb811 0x00001447
0xbfffc918: 0x175732d5 0x15af8808 0x00000000 0x69746c32
0xbfffc928: 0x0000bd7e 0x00000000 0x00000012 0x00000010
0xbfffc938: 0xbfffc948 0x92d90000 0x00000012 0x00000006
0xbfffc948: 0xbfffc958 0x00200020 0x00000000 0x0083f69c
(gdb) info registers
eax 0x17bdb837 398309431
ecx 0x0 0
edx 0x15 21
ebx 0x17481708 390600456
esp 0xbfffc8e0 0xbfffc8e0
ebp 0xbfffc908 0xbfffc908
esi 0x17bdb811 398309393
edi 0x15af8808 363825160
eip 0x174329bc 0x174329bc
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb) x/20x $eax
0x17bdb837: 0x70737472 0x302f2f3a 0x302e302e 0x312f302e
0x17bdb847: 0x33706d2e 0x430a0d2f 0x65746e6f 0x542d746e
0x17bdb857: 0x3a657079 0x41414120 0x41414141 0x41414141
0x17bdb867: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb877: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20s $eax
0x17bdb837: "rtsp://0.0.0.0/1.mp3/\r\nContent-Type: ", 'A' ...
0x17bdb8ff: 'A' ...
0x17bdb9c7: 'A' ...
0x17bdba8f: 'A' ...
0x17bdbb57: 'A' ...
0x17bdbc1f: 'A' , 'B' ...
0x17bdbce7: 'B' ...
0x17bdbdaf: 'B' ...
0x17bdbe77: 'B' ...
0x17bdbf3f: 'B' ...
0x17bdc007: 'B' ...
0x17bdc0cf: 'B' ...
0x17bdc197: 'B' ...
0x17bdc25f: 'B' ...
0x17bdc327: 'B' ...
0x17bdc3ef: 'B' ...
0x17bdc4b7: 'B' ...
0x17bdc57f: 'B' ...
0x17bdc647: 'B' ...
0x17bdc70f: 'B' ...
(gdb)

The guilty system call.

1: x/i $eip 0x1748216f <_enginenotificationproc+2680>: mov DWORD PTR [esp+0x4],edx
(gdb)
0x17482173 in _EngineNotificationProc ()
1: x/i $eip 0x17482173 <_enginenotificationproc+2684>: mov DWORD PTR [esp],eax
(gdb)
0x17482176 in _EngineNotificationProc ()
1: x/i $eip 0x17482176 <_enginenotificationproc+2687>: call 0x175812ae
(gdb) x/20x $eax
0x17bdb85c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb86c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb87c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb88c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb89c: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20x $edx
0xbfffca99: 0x1f000016 0x6c000000 0x00000006 0xa8000000
0xbfffcaa9: 0x0f001201 0x6c92dbbc 0x000083f6 0x5800000c
0xbfffcab9: 0x2517bdcc 0x009494bd 0x00000000 0x08000000
0xbfffcac9: 0x7abfffcb 0x009494bd 0xe0001200 0xa815ae1f
0xbfffcad9: 0x04000001 0x00000400 0x9317b7ba 0xa8175712
(gdb) info registers
eax 0x17bdb85c 398309468
ecx 0x0 0
edx 0xbfffca99 -1073755495
ebx 0x17481708 390600456
esp 0xbfffc910 0xbfffc910
ebp 0xbfffcbc8 0xbfffcbc8
esi 0xffffeae6 -5402
edi 0xbfffcd38 -1073754824
eip 0x17482176 0x17482176 <_enginenotificationproc+2687>
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb)

Conclusion

Installing Apple code on a Microsoft Vista system will make that system unsafe. Since these QuickTime vulnerabilities are equally exploitable on both Vista and Mac OS X 10.5, the fans might conclude that both operating systems are equally safe. This is not true, Vista is vastly more secure than the Macintosh. Apple’s only advantage over Microsoft is their small market share, which means hackers are less interested in them. However, as hackers are having a harder time cracking Vista, they are getting more interested in the Mac, and we are seeing more exploits and more malware targeting Apple users.

As always there is more information in the Hacker Eye View report concerining these issuses.

A roundup of stuff...

Seagate ships hard-drives with viruses...Hrm, I wonder if they will take the path of another vendor and blame Microsoft.

Vulnerability auction site WabiSabiLabi's founder was arrested for involvement in spying on several corporate officials. Some people are pointing to this as an example of why a vulnerability market is "shady" and you should just give information to the vendors. I am torn on this because to swallow that you have to believe that the vendor will do the right thing. I have reported flaws to vendors that haven't not been fixed a year later. This is mostly because they know we don't drop 0day so there is no rush to fix the problems. Its seems almost like the mindset has set in that you should ASSUME the researcher is a bad guy and the vendor is a poor victim. I don't buy into this school of thought and think its time for "responsible disclosure" to start holding to task just like they do researchers.

On the flip side you have this guy who is obviously bad.

Apple releases security updates to patch a libtiff hole in the iPhone. People are already reporting the phone is re-broken. You have to love cat and mouse games. I am happy the iPhone is here because until now nobody really though mobile vulnerabilities were a big deal. The best thing Apple has going for them the most is that they can release updates directly to the device instead of waiting for carriers to do it like Windows Mobile.

The Cyber-Jihad didn't happen, no one is surprised but yet everyone is talking about it.

Blackwater founder Eric Prince now has SIGINT and information warfare capabilities. The company, Total Intelligence Solutions, provides a range of services from penetration testing to SIGINT to OSINT for clients. They are basically an outsourced NSA and CIA rolled under one umbrella without the inter-agency rival. If you look at the people who make it up, they come with some pretty hefty bios with significant amounts of CIA experience. A thing to note is that they list former carnivore producer Netwitness as a partner. Netwitness is also headed up by Amit Yoran, the former head of the CIA VC company In-Q-Tel. Quite an old boys club there...

postmortem and ontime...

People who run WinDBG, or any debugger for that matter, as a postmortem debugger will notice alot of crashes most people won't. Flash9d everybody...

Atst glance it looks like an unexploitable double free, but I could be wrong...

http://docs.info.apple.com/article.html?artnum=306896

Crap. 5 remote code execution vulnerabilities in Quicktime alone. Can anybody tell me how to enable ASLR in 10.5, I don't want to get owned by any of these.

http://docs.info.apple.com/article.html?artnum=61798 5 updates for Quicktime this year alone? That seems a bit high.

USRP goodness

Recently I got a new USRP from Ettus Research. If you are not familiar with what a USRP is, you can read about it and the GNURadio project here. You basically get a system board with an FPGA, a enclosure, and a bunch of screws. I also got the DBSRX daughterboard.


This is literally every part that comes in the box.


This is what it looks like after mounting the board in the enclosure.


Wow, we have daughterboard!


Fixing up the connections like the fan and antenna...


Its finished!


What it looks like in its new pelican case with a satellite phone.

This is for an upcoming research project regarding the actual security of mobile devices.

A new blog has appeared that should interest chip hackers.

Mr. Bunnie pointed this out.

A firewall that protects all the nations critical infrastructure? That would be awesome. Or even individual firewalls would be great. What is not great are SCADA operators that are scared to portscan a machine because it may fall over. Oh well...

The Video..

Funny Vista Tricks with ASLR

While doing alot of testing around the implementation of ASLR on both OSX and Vista I noticed something odd. 3rd party dlls in the Internet Explorer don’t seem to change addresses. See the screenshot below. Googletoolbar and flash9d stay at the same address through multiple reboots. I thought this was odd.

Flash9d and Googletoolbar stay at the same address.

Doing some reading it turns out that a linker flag, /dynamicbase, is what tells Vista that it is ok to rebase a DLL. This gave me a bright idea that maybe I could manually enable ASLR support in a DLL. The first step to this is to find out exactly what the /dynamicbase flag does to a binary. I did a couple of things to run this down, but mainly I compared a DLL that utilized ASLR versus one that doesn't. Mshtml.dll takes advantage of ASLR so that the target. Googletoolbar is the binary I want to force to use ASLR. After comparing alot of fields in the PE header i narrowed it to an option in the PE header, DLL Characteristics. Setting this field to 0x40 enables rebasing the DLL.

The real difference is the DLL Characteristic field which has to get set to 0x40.

1. The first step in enabling ASLR for this program is to save a copy of the original file so that it can be restored in case of an accident.

2. The next step is to open the Googletoolbar in a hex editor and find the DLL Characteristics field and set it to 0x40.

These are images of modifying the googletoolbar dll. The byte that is changed is on the bottom role on the right.

3. Save the file. B00m, some ASLR action for Googletoolbar.

Every reboot changes the load address of GoogleToolbar now.

I was worried that this would not work because of application signing. I thought that once an application is modified it would no longer run. No problems like that occurred. The toolbar seemed to work just fine.

I am not advocating doing this to your system DLLs, I just thought it was interesting.

Errata goes to the races...

Today I spent time in the pits of the NASCAR truck series. It was a fun day, there was a minor accident, but the most surprising was the wireless access.

There were open wifi access points all over the pits. From Direct TV to access points used by reporters, it was ripe for credential theft not to mention people still using unencrypted pop3. Below are some screen shots from my iPhone running stumbler. These were collected just walking up and down the track. Sometimes people need to remember that although people who do security for a living know about these types of problems, the general public doesn't.

We should have a hamster and ferret package for the iPhone available soon.

OK

I got tased. Video up soon.

Evil Rob Graham Fact #3

and

Once again I am not pointing fingers, but come on, they were separated at birth. Plus the other day at lunch Rob mentioned wanting to crush the rebellion.

Evil Rob Graham Fact #2

You remember the meteor that killed all the dinosaurs 65 million years ago? I don't want to point fingers but Rob IS missing a meteor, Vote for Graham getting stunned.

Password Cracking vs. Core2/Athlon64

Today's CPU's can "crack" passwords 8 times faster than they can "check" the passwords. Normal software checks a password using roughly 500 CPU cycles, but a brute force password cracking program can check a password in roughly 65 CPU cycles. Brute force programs do this because they check multiple passwords at once using the parallel features of the CPU.

The United States is currently working on new "Advanced Hash Standard" to replace the current SHA-1 (to be used in things such as passwords). Normally, crypto algorithms are designed ignoring brute-force cracking, because it only makes a small difference overall (it only changes a constant on the complexity of the algorithm). However, since we know that software cracking is the primary way of breaking these things, it might be worthwhile tweaking the algorithm to make cracking more difficult.

In other words, if brute-force software can crack passwords eight times faster, we know that that a 160-bit hash algorithm has only 157-bits of effectiveness. If we tweak the algorithm to defeat the brute-force acceleration, then the algorithm would have a full 160-bits worth of effectiveness.

Today's CPUs are "wide", which means they can execute multiple instructions simultaneously. However, this only works if the instructions are INDEPENDENT. If the two instructions operate on the same registers (DEPENDENT), then the second instruction must wait for the first to complete before it can execute.The following is an example:

Dependent (runs in two clock cycles)
add r1 -> r2
add r2 -> r3

Independent (runs in one clock cycle)
add r1 -> r2
add r7 -> r8

The problem with cryptographic code is that it normally contains a long chain of instructions dependent upon each other. Thus, checking a single key takes 500 instructions, and therefore roughly 500 clock cycles. To get around this, brute force password crackers check multiple passwords at the same time, then interleave the instructions. They check eight passwords in the same 500 clock cycles.

The latest processors from AMD and Intel contain 3 execution units. Thus, in theory, they could check 3 passwords at the same time it would normally take to check a single password.

An even more powerful feature is the "SIMD" units. The acronym SIMD means "single-instruction multiple-data". This widens the registers so that they can hold 4 separate values simultaneously. A single instruction that adds two SIMD registers together would in fact do four simultaneous additions.

The modern processors from Intel and AMD contain 2 SIMD execution units. This means they can, in theory, check 8 passwords at the same time (two sets of registers, each holding four values).

The following is a snippet of code from John the Ripper that cracks Windows passwords. Each SIMD instruction is repeated twice for two different sets of passwords, and each register holds four different values for four different passwords. Thus, eight passwords are checked simultaneously.

paddd (512*base)+(x*32)+nt_buffer8x, aa
paddd (512*base)+(x*32)+16+nt_buffer8x, aa3
movdqa cc, t1
movdqa cc3, t13
pxor dd, t1
pxor dd3, t13
pand bb, t1
pand bb3, t13
pxor dd, t1
pxor dd3, t13
paddd t1, aa
paddd t13, aa3
movdqa aa, t2
movdqa aa3, t23
pslld $s, aa
pslld $s, aa3
psrld $(32-s), t2
psrld $(32-s), t23
por t2, aa
por t23, aa3

Right now, the above John the Ripper code doesn't give the eight-fold increase you would expect. It would take a bit more machine-language zen than simply duplicating the instructions in order to get closer to the theoretical performance. The second reason is that John the Ripper isn't fully optimized for this level of speed: while inner loop can check a password in 65 cycles instead of 500 cycles, it still takes 100 cycles for the program to choose a new password. In other words, if we could make checking passwords infinitely fast, it still would only double the speed of the code.

To get more speed, ee'd have to bring new password selection deeper into the code. For example, we could pass in a single password, and the code could add the constants {0,1,2,3, 4, 5,6,7} onto the end, thus choosing the eight sequential passwords in only a single clock cycle.

In order to defeat parallel cracking of hashes, the next hash standard could include parallel elements itself. They would have to break the long dependency chains in the algorithm into 8 independent chains. This means they could also increase the number of logical operations within the algorithm, making it 8 times stronger. Thus, a single hash could be calculated in the same 500 cycles as today's hashes, but with 8 times the number of logic operations. Brute-force crackers would therefore get no benefit from checking multiple keys at the same time.

An alternate design technique would be to include features that make SIMD processing difficult. Raw cryptographic operations consist of "permutations" and "substitutions". A permutation is an operation like "shift", "xor", "add", etc. A substitution is a table lookup of a new, mathematically unrelated value given a current value. For example, give a byte with a value of 0x61, looking the up in a table might replace that with 0xF7. There are SIMD instructions for all the permutation operators, but there aren't any equivalents for substitution operations.

The hashes we use now for passwords, such as MD4 and MD5, do not use substitutions, which is why they can be accelerated with SIMD. Some passwords still use DES, which contains a lot of substitution operations. Luckily (for crackers), a DES substitution can be replaced with multiple permutations, so it still gets accelerated by SIMD, but not as much acceleration as with MD5.

All of this may become a moot point. You can now get cheap FPGAs (for example, from Pico Computing) and open source code that cracks passwords even faster. You can also exploit graphics cards (and their GPUs) for faster cracking. Finally, botnets can herd millions of machines into a password cracking effort. With all this additional power, making software cracking slightly harder may not be worth it.


CONCLUSION: Today's crypto algorithms ignore the practicalities of software brute-force cracking. As a result, they are a few bits less effective than theory would admit. The reason is that carefully designed cracking code can take advantage of the parallelism in modern processors (multiple execution units, SIMD processors). A few algorithmic changes can defeat this, either by incorporating parallelism into the algorithm design, or by including features that are difficult to make parallel. This may be unnecessary: while the majority of brute-force cracking is done in software today, hardware approaches using FPGAs or graphics-cards may be the way of the future.

FAQ: BTW, by "multiple execution units", I mean in a single CPU core. I'm ignoring multiple cores, which do make cracking faster as well, but at the normal Moore's Law progression.

Evil Rob Fact #1

You know all those ships that went missing in the Bermuda triangle? That was Rob Graham. Vote for Rob to be tazed.

Vote which of us gets tazed

Tazers and stun guns have been in the news lately, from intelligence agencies electrocuting suspects to student demonstrators getting tazed by campus police. In order to celebrate the 1-year founding of Errata Security, we have decided therefore that it's time that ONE of the founders gets tazed by a 100,000 volt stun gun.

We have set up a poll (part of a google blog feature) on the right-hand-side of this page. Vote for which founder you would like to see tazed. We will post the results Friday afternoon, with a video of the "winner" getting his just reward.

Dave would claim that Rob hates puppies and often has fields of daffodils paved over. However, Rob would like point out something evil about Dave Maynor, but can't figure out anything more evil than DAVE MAYNOR.

If you want to hack something today...

In this post, I point out that it takes only moments to find a vulnerable system to hack with Google and SQL injection. This blog post by "pdp" shows another way, this time using Citrix instead of SQL. If you search for filetype:ica you'll find hundreds of systems that you can hack.

Citrix is a remote GUI, like VNC or X Windows or Microsoft Remote Desktop. It is a popular way for people to "host" applications. Usually its a way to provide remote access to a Windows application that was originally written to be local.

In most cases, you'll connect to an application with no specific user credentials. The security rests with the application Citrix is connecting you to. Most of these have trivial or no security, and will allow you to gain control of the entire system with just a few clicks. The blog by "pdp" shows a video of Citrix connecting to the "calc.exe" program (the Windows Calculator accessory) and then gaining a command-prompt.

However, you can usually edit the ".ica" file that the server gives you and enter a different application to run, such as "explorer.exe". You can also edit the user credentials. Google for filetype:ica ClearPassword for some extra special fun. If you read the content of the ".ica" files, you'll quickly find other tricks you can do in order to hack systems.

Last month, major news outlets reported that the Chinese had hacked the Pentagon. My mother asked me how this could be. The answer is: a teenager can find and hack a .mil or .gov system in minutes using Citrix, SQL injection, or a dozen other well-known techniques.

I'm bored today...

What you packing?

The Cost of Security

Airplanes carry flight-recorders made of an indestructible material that will survive a crash. A common joke is to ask "Why can't the entire airplane be made from the same material?" The answer is, of course, that this would make the airplane too heavy to lift off the ground. Planes need to be dangerously flimsy to fly.

Cybersecurity has the same issues. People point out "obvious" solutions to cybersecurity while ignoring costs they would entail.

A good example is this story at The Register where former cyberczar Richard Clarke outlines his 5-point plan for securing the Internet. All his points make as much sense as building airplanes from cast iron. An example is his quote:

"We should look, as an industry, at improving the quality of secure code, so that we don't need to issue software patches, so there aren't trap doors - intentional or otherwise. This is not a revolutionary idea. We put this in place a long time ago for electrical appliances."

Is this as cost-free and uncontroversial as Clarke pretends? No, of course not, or else such laws would already have been passed.

"Safety" is not "security". Safety protects against ACCIDENTAL problems, security protects against INTENTIONAL problems. Regulations are designed to protect your gas stove from accidentally exploding, but they can't protect you if somebody intentionally rigs your stove to explode. In much the same way, automobile safety protects against accidental problems, but does nothing to stop your tires being slashed or your break lines from being punctured intentionally. Product safety protects against the INANIMATE effects of bad design, bad construction, and wear-and-tear. Security protects against the ANIMATE and unpredictable adversary who is likely more clever than the engineers who designed the product.

In other words, the analogy between "product safety" and "software security" is faulty.

Not only would regulations work less well, they would cost more. Government regulations have hidden costs. That's why economists and politicians spend so much time trying to get rid of them. While you can't see the costs directly, you can see their effects. For example, what appliances do you own that were NOT created by a huge multinational corporation? This is because small companies cannot afford the heavy costs of regulation. Countries that regulate more innovate less. Regulation favors large companies over small companies.

Think of this another way. Right now, you can start your own software company and (hopefully) make a million dollars. That's because you don't have to worry about government regulations. If Clarke were to get his way, it would take several full time employees and high-priced lawyers just to deal with the regulations, leaving nobody left to create your software. Software innovation would come to a stop in the name of cybersecurity. Only megacorporations would then be able to ship software (which is why companies like Microsoft support such regulation). A good example of this is the "Common Criteria" certification for government software, where it takes at least a million dollars to get certified (and which still fails to produce secure software).

Richard Clarke's remaining proposals are even worse. Clarke's solution to cybersecurity is to convert our free society into a totalitarian police state. He's right, of course, doing so WILL improve cybersecurity, but at a huge cost to civil liberties. Even today, we live in a slight police state: you are more likely to be arrested falsely by the police than you are to be attacked by terrorists. There are many of us who believe that the slight improvement in security is not worth the huge cost in liberty.

Anybody can pass themselves off as a security expert by proposing extreme solutions and silencing their opponents with the accusations that they aren't taking security "seriously" enough. That's not what an expert is. Instead, an expert is somebody who can find solutions WITHIN a reasonable set of costs/sacrifices.

Google Protection

With all the cross-site scripting bugs in Google, I'm surprised our blog (hosted by Google's Blogspot) hasn't been defaced yet.

One way to protect against this is to open separate instances of Firefox, one for Google, and one without Google. This allows you to have GMail up on a separate windows on your desktop, but without the danger of XSS bugs crossing over and hijacking the GMail session.

In order for this, you need to take advantage of Firefox profiles. You need to create two scripts, one that launches the existing "default" profile, and one that launches a "gmail" profile. The following is the script for Windows that launches the "default" profile, just change "default" to "gmail" for the second script.

You need to now launch Firefox using these scripts, because launching it normally will just use whichever of the two profiles you used last.


<?xml version="1.0"?>
<package>
<job id="Firefox:GMail:Loader">
<?job debug="true"?>
<script language="javascript">
var shell = WScript.CreateObject("WScript.Shell");
var env = shell.Environment("User");
var installpath = shell.RegRead("HKLM\\SOFTWARE\\Clients\\StartMenuInternet\\FIREFOX.EXE\\shell\\open\\command\\");
env("MOZ_NO_REMOTE") = 1;
shell.Exec(installpath + ' -P "default"');
env("MOZ_NO_REMOTE") = 0;
</script>
</job>
</package>

iPhone Shellcode by Metasploit

HD Moore publishes information on iPhone shellcode at the Metasploit blog. The shellcode combined with the number of bugs present in the iPhone finally make mobile attacks a real threat.

An open letter to my CEO

Dear Rob,
Wow, time sure does fly. It just seems like a mere 13 hours ago I made a post asking computer criminals not to attack on Tuesday, September 25th because it was Halo 3 launch day and a lot of Microsoft geeks would be calling into work sick/permanently incapacitated/dead.

You are not going to believe this...

On my way to bible study, after dropping off cookies to orphans and chopping wood for grandma the oddest thing happened. I got sick. My lungs/spleen/stomach/left side of brain/right leg no longer work. It's funny in a painful sort of way. It is so bad that every time I cough I solve an integral. Weird, right? Because I am such a team player I am going to go ahead and stay home, better not to get everyone sick. I know it's ice cream social Tuesday, and darn it, that upsets me but I will do this for the team.

Oh and do not call; I think I might be so contagious that the mere sound of my voice could get everyone sick. And if you do call the sounds you hear in the background are a soothing audio book I got by Eric S. Nylund on something Sci-Fi related, I can’t really remember in my current state.

Thanks for understanding,
David *cough its Halo 3 Tuesday* Maynor

PS: Ignore the picture above becasue I was actually deathly sick when it was taken.

UPDATE: Forget this, there is framerate slowdown on the first level with MAYBE 10 badguys on the screen. I'm no video gamer developer but it seems like that would be a QA check or something. Halo 3 sucks, I am going to work tommorow.

An open letter to computer criminals...

Dear Computer Criminals,

I would like to have a word with you about an event this week. As you might know from the commercials, advertising tie-ins, and reviews, Microsoft’s latest entry in the Halo series becomes available at midnight. In fact, many stores will be opening at midnight to support the expected rush for Master Chief goodness.

Now it may seem that, with the flood of people developing the flu or strep throat or other non-diagnosable aliments resulting in Tuesday being a sick day, that it would be a great time to launch a new worm or add a new attack to your botnet. Its almost like Microsoft fan boys will be leaving the doors to the castle open due to the number of cellphones and blackberries that will be ignored in pursuit of unlocking Halo achievements.

I would, on behalf of these dorks, like to ask you to let this day pass. It is like shooting fish in a barrel; where is the glory in that.

Thank you for your time,
David

Response to some Bloggers

Analogies are a funny thing; much like statistics, they are often warped to support any point of view. A few Mac bloggers came up with analogies around why they were not show our exploit work from last year. Of course, their conclusion is that we made it up. Forget the fact that if you were to follow the instructions from our presentation you would have found these bugs, they still write that it was a fraud.

I have my own analogy. Wait, it is less of an analogy and more of a statement. Why would I show them anything I do? Are these bloggers a responsible party at any affected vendor, a third party agency, or either Jon’s employer or mine? After Blackhat 2006, numerous driver developers contacted us across a variety of platforms for things they could do to make their code better that ranged from defensive coding techniques to better ways to test for vulnerabilities. This was the point of the presentation. Proving ourselves to bloggers was not.

To be very honest I had never heard of any of these people before they start yelling about me being a fraud last year. Their demands and “contests” for me to show them my work is literally the equivalent of me making a blog post challenging the governor of Georgia to a debate on fiscal responsibility then claiming victory when I am ignored.

That’s the dirty secret thought, it is hard to claim to be an authority on a subject when the newsmakers mostly ignore you. In order to combat that you have to set yourself up in such a position that even if a person ignores you, you can claim victory.

Let’s look at the reasons why the “macbook” contest was ignored.
-John Gruber’s approval means nothing in the security community.

That is pretty much it. Oh and he made the challenge after we were gagged. Nothing like waiting until someone is in handcuffs to take a swing at them. I could be childish and offer a contest to prove that they would have even understood our work. Hell, with all the Apple 0day we are sitting on I could even offer to go double or nothing on their absurd Macbook challenge. But in the end things like that are utterly stupid because they really prove nothing.

I am art

OH MY GOD, this is such a coincidence. You might not know this about me but I am an artist. I created a piece of art to remind people about our troops serving overseas. I am sure glad I saw this article before going to the airport. Boy life sure is rough on us artists.

A pic of my art:

In addition, I added a disclaimer so no one gets confused:

I would like to point out that this is a work of satire designed to point out how crazy it is somebody would walk into an airport with something that looks like plastic explosives and a detonator.

Past...Present...Future...

So I am done with my month long project and although parts of it will be public later this week, all I can say is its a 3 part research project entitled "Past...Present...Future..."

UPDATE: The "Past" portion of the 3 paper arch was just published at Uninformed.
We have "Present" and "Future" looming...

Here is a pick of the home office I have been working from, this setup is mostly duplicated everywhere else I would work from, I thought you might just want to see what the fuss is about.



Now that the project is done I gotta get back on the blogging track: I gotta post my Blackhat Vegas writeup, publish my pwnie acceptance speech, and what we are working on next.

And now...Comedy...

Friday saw the quarterly official Errata Security team building, offsite, management meeting held in at the Regal Cinemas in Atlantic Station. The Errata Security founders viewed Shoot’em Up with Clive Owen. Shoot’em Up provided an opportunity to do something I have wanted to for a while: discuss security products designed by committee. First my short review of Shoot’em Up.

Shoot’em Up as a movie exists in a place that would make Schrodinger's cat envious: it is both crap and brilliant in a constantly fluctuating state. On one hand, you have Clive Owen portraying a reluctant hero who has to shoot, stab, and generally dismember his way through a constant stream of bad people who cannot hit the broadside of a building with automatic weapons. The reluctant hero holds a special place in the hearts of action moviegoers everywhere since Bruce Willis’ iconic character, John McClane, blasted his way into the hearts, minds, lower intestines, and limbs of faux terrorists all over the world. Clive Owen keeps the basic rules of the reluctant hero alive by being able to hit what he is shooting at in ways that us mere mortals could not imagine while spending the entire time looking like who would more enjoy sitting in the waiting room at the local dentist. The movie is quiet satisfying if that is all it was but there is a strong anti-gun message throughout the entire film. The anti-gun sentiment accompanies a strong anti-company message and some good old-fashioned politician hate thrown in as well. For a movie that targets an audience of males 17-34, this is an odd choice. I do not mean to sound crass but it is almost like a porno movie preaching abstinence. I am sure what we watched was not the initial directors vision, but yet a perversion during a pitch meeting in Hollywood.

In fact, I am sure it went something like this:
Director: I wanna make a mindless action movie where a reluctant hero runs around for two hours and shoots bad guys.
Studio: That is awesome we want to make it. We have a few suggestions…
Director: Suggestions? About what, it’s a pretty straight forward movie. A guy runs around and deals death in the form of a wall of lead to bad guys. What more is there, unless you are talking about marketing tie-ins with people like Glock…
Studio: Well, we want the hero to have a heart of gold, our testing shows that most audiences like a heart of gold. In addition, mothers get upset about gun violence so we need to add a strong anti-gun message or we might be looking at protests. Also let us give our hero a sidekick, maybe a love interest, to help draw in the women. Also when I was a child a worker from a large company took my ice cream cone, so I want to add in an anti corporate message.
Director: So wait, lemme get this straight, you want to turn my 2 hours of shooting into an anti-gun campaign that also targets large companies while we just throw in sidekicks…
Studio: It is only going to be 80 minutes and it is that or we can give somebody else the money to make his or her movie…

You may be wondering what this has to do with security. I have seen some products that actually seem to get the same design by committee process.

Developer: I would like money to build the ultimate security product that everybody needs. It will work by stopping attacks by inspecting traffic into a network device and determining if its an attack.
VC: That’s awesome, we would like to give you money to do this, but we have a few suggestions…
Developer: Ok, I would love to hear them…
VC: Is there anyway you could make this product more buzzword friendly, like ASLR?
Developer: Address randomization really does not apply to network products…
VC: So we would have a great breakthrough if you made it work. We would also like you to add in stuff like anomaly detection and content filtering…
Developer: Does anybody want to buy a product like this?
VC: Sure, plus we can charge more, any way just sign on the dotted line in blo…err...ink.
Developer: Its kind of weird, its almost like you were about to say “sign in blood”…is it really necessary to tell me to sign in ink?
VC: Yes…Have a cookie.