fragile software systems & risks in homogeny

well there are some things which reportedly do not belong on blogs... grrr... so here's some more of the drivel you've come to expect ;)

this here is one of those 'not sure if i should laugh or cry' links:

the most advanced fighter in the world ... was able to rack up an impressive 241-to-2 kill ratio [during war-games] ... [but] was felled by the International Date Line (IDL) ...

When the group of Raptors crossed over the IDL, multiple computer systems crashed on the planes. Everything from fuel subsystems, to navigation and partial communications were completely taken offline. Numerous attempts were made to "reboot" the systems to no avail ... the Raptors had their refueling tankers as guide dogs to "carry" them back to safety ... They had no communications or navigation

summarized pseudo misquote: "aircraft which cost $125+ million USD apiece were [disabled by] a few lines of computer code"

the F22 IDL story made me wonder if the F/A-18G that 'killed' an F-22 was able to do so particularly because of electronic warfare capabilities...? no idea, but i'd love to ask that Grizzly driver ;)

there might be a couple of take-aways here...

#1 - increasing reliance on critical computerized systems which are not backed by redundant systems and are fragile will present significant new risks. think about the F-22 design philosophy versus my favorite airborne weapons platform: the hawg!

the A-10 has "triple redundancy in its flight systems, with mechanical systems to back up double-redundant hydraulic systems ... [and] is designed to fly with one engine, one tail, one elevator and half a wing torn off." you don't have to google far on the A-10 to find a variety of stories about how well it performs under the stress of combat operations. reportedly, "the 165 Warthogs that flew in Desert Storm [had a] 95.7% mission capable rate ... the highest sortie rate of any USAF aircraft ... [while] roughly half of the total A-10 force supporting Desert Storm suffered some type of battle damage ... [just] five A-10s were lost in action".

yes, physical survivability is very different than electron system fragility, but there may be parallels. if the F-22 is tough to target with traditional weapon systems, maybe a better approach is a big ass radio antenna and a decent fuzzer ;)

#2 - highly homogeneous systems deployed into production can fail spectacularly. relatively survivable critical systems like DNS root servers are deployed on varying hardware and software to avoid this issue. once the JSF becomes the mainstay fighter of western nations, then a similar 'vulnerability' could theoretically disable entire air forces. don't worry, all JSF code is written in C++ (wikipedia) so there won't be *any* software induced failure points... lulz...


ps: speaking of crappy code and fragile software, i recently discovered that the back-end of sslvis is b0rked. i'll be getting it fixed up, getting features added to the back-end, and moving it out of beta as soon as i can... sorry!!

why it sucks to be an infosec defense guy & an example of real-world cyberwar

i got a chance to listen to Richard Clarke talk w/ Terry Gross on Fresh Air today, and while it was full of a lot of the things that suck about listening to mass-media talk about infosec, there were definately some gems...

i'd say it's worth a listen... anywho, onto the content:


[why it sucks to be an infosec defense guy]

@ 02:20

"somehow from a thumb-drive, a virus a worm got into the classified network, which is supposed to be a closed loop network, of CENTCOM and attacked compromised thousands of computers of our warfighters in Iraq and Afghanistan and probably exfiltrated large amounts of information to someplace in the internet [in December 2008]"

ok, so this blurb says two things to me.

1) "it attacked an infected thousands of computers on a closed-loop network" - here's a lot of assumption, but when i hear about worms spreading in closed networks, it makes me say 'oh you didn't apply security patches to those machines because you thought they were safe'. unless this thumb-drive was full of 0day, this incident is classic failure to follow best-practices because you assumed some other layer of defense would keep you safe.

2) and wait, was this "closed-loop" network airgapped? well, clearly it wasn't if you were able to exfiltrate any data out of it to the internet. and even if it wasn't an airgapped network, why the #@%(*@#%* are you letting this classified military network which supports men & women with guns TALK TO THE INTERNET?!?! srsly guys, you know firewall policies can be set to block traffic leaving your network too, right?

this kind of stuff just sucks. here you have a network which should be one of the most secured in the world, and has tons of resources dedicated to protecting it, and it falls flat on it's face w/ two well known best practices. when .mils aren't doin this stuff, you know that corp networks are probably worse. how can you tell me to help protect you if you're unwilling to patch and control your network? and you're surprised when bad things happen to you? srsly?

we know how to do so much good defensive stuff, but it's a lot of mundane process and procedure. it takes cycles and people, and it takes some documentation and training, some audit and enforcement, and it takes some effort and work. and it seems like no one is doing it... booo :(

oh well... c'est la vie


[an example of real-world cyberwar]

as a bonus...

remember when Israel bombed some secret facility in Syria? well, according to Clarke, that attack was performed by Israeli F-15s and F-16s which are very not-stealthy fighters. so a reasonable question is why weren't these planes shot at/down by Syrian air-defense networks?

according to Clarke, the Syrians saw nothing on their radar at the time and after the fact because "the Israelis had used cyberwar as part of a traditional attack. They had taken control of the Syrian air-defense system, and made all of the radars look like there was nothing in the sky, even though the sky was filled with Israeli fighter-bombers."

anyway, just wanted to include this because so many people in the infosec game seem to think that cyberwar can only be a digital-pearl-harbor type catastrophic attack. as if the entire attack will be encompassed by bytes on a wire. in my opinion cyberwar capabilities can be used effectively as a small part of larger tactical engagements. dismissing cyberwar as a fantasy ignores real-world realities and capabilities which are apparently being put to use today by state actors, and possibly others...

snail-mail-fail

hey lookit, important tax-return document in the mail... wazzat w/ the top of the envelope?



erm... umm... wot?



sighhhhh.... yea, those current number fields aren't blank... fuggin wonderful...



so there's an IRL infosec attack in motion... i'll speculate local postal carriers couldn't harvest enough numbers to make it worthwhile... maybe a USPS mail distribution worker, or someone in the mail or finance dept of Chase or whoever produces their mailers...?

from the blackhat reject bin

so maybe this is obvious, i donno...

the talk started when i told my buddy (@zenfosec) that i had this password for the firewall for this big .com site... it was one of those "it's always been that" passwords... pure speculation, anyway...

so at the end of the gig while presenting my report, i suggested they rotate the password, since they gave it to an external party. the admin laughs, and he's like "you can only get to the box from inside once i pull the rule for you".

i'm a big advocate of dropping the whole "inside" / "outside" terminology for substantial networks. the fundamental protection measures are so cheap in true cost, and the risk/benefit is clear. anywho...

so my buddy says "yea, until you client side him" ;)

so that was the crux of the talk. when you get client-sided by xss or flash vulns or whatever, your internal network can be attacked.

this idea really built off the nifty modem csrf pointed out by nathan... so let's just extend it. what if there's auth required on the device? can we attack it when we're XSSing and/or CSRFing?

blah blah, slides about xss and csrf history, and traditional distinctions, etc...

so anyway, the hostile code can blindly assume gateways are .1 or .254 on the local /24 (re: the timely rsnake comments on the pervasive homogenous rfc 1918 networks) or you can do a little work and find them.

once found, gateways can be attacked w/ a csrf via the client-side. if the gateway requires auth, it can be brute forced. i didn't do much with forms based because i was really curious about http basic auth. this lead me to realize you can pass http basic auth creds to the gateway:

<img src="https://username:password@u.r.gate.way/known/path/img.gif">

***update*** - i thought this auth method was really nifty when i thought about it and tested it, and just two days ago realized that the gnucitizen crew used the same method in their AttackAPI.. mb others did before that too. anywho, just wanted to give credit

generate tons of code brute the passwords with known usernames and image paths for common gateway models. you are auth'd, you detect it and initiate a second stage which leaks out the creds and/or performs a csrf to enable wan management.

bruting will work because people feel like inside is safe and they don't take reasonable precautions like password rotation, password complexity, and human monitoring of interesting log events like days of failed password attempts on the firewall.

i haven't come across similar ramblings on the web yet, so i wanted to share :)

thanks for stickin w/ me if you read this far ;)