cloud security redux

short and sweet post.... tons of talk about the cloud over the last 6-12 months...

so the cloud is a bunch of boxes offering a service out there on inet. all the security discussion i've seen has focused basically on confidentiality of your data once it enters the cloud, but mb there's another way to look at it.

clouds are potentially massive environments of resources which are allocated and partitioned to paying customers. instead of focusing on the risk posed to cloud customers, why not look a little at the risk to the cloud operators?

clouds are big business networks, and big networks are often under-monitored. attacking cloud allocation schemes could result in resources being allocated to an attacker off-the-record. "ghost" resources in the cloud controlled by an attacker who isn't paying for service and isn't abiding by the ToS. these ghost resources could be used for all kinds of illegitimate purposes with significant value for the attacker who controls them.

if you are subtle, you could probably operate under the radar within the cloud for quite some time...

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 ;)

dr horrible ftw

okok, so i just heard that there are ppl who haven't enjoyed this yet. soooo:



enjoy :D

(ps - this is 1/3)

props

quick note to say...

spent the weekend doing ctf quals w/ a bunch of peeps who are smart and cool... appreciate the chance to play w/ peeps who know what's up, and lookin fwd to applying some new knowledge next year...

oh, and btw, i didn't watch the new burn notice till just now, so you know i thought quals were cool as hell ;P

peace!

quick strongwebmail blurb

so strongwebmail got pwnt, and mb some hacker peeps are gettin paid... gratz all around!

it's interesting that strongwebmail focused so strongly on authentication (at least in the media reports i read prior to the pwnage)... they must've felt very secure that no one was going to find a way to read the PIN sent via SMS to a cell phone...

it's a beautiful hack (imo) to ignore that aspect entirely, sign up for an account, and subvert the system from the inside on the application layer.

seems like mb strongwebmail got some tunnel-vision about their uber 2-factor auth and forgot some simple stuff like input validation and output encoding ;)