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

data feed analysis

relatively simple data-mining is a powerful and prolly underutilized defensive asset for dynamic risk management...

this recent rw story about a fuel leak in a plane is a great starting point for this little rant...

A fuel leak on a civilian aircraft caught the attention of Staff Sgt. Bartek Bachleda, 909th Air Refueling Squadron boom operator, during a flight from Chicago to Narita airport, Japan. After alerting the pilots and aircrew, the ranking pilot made the decision to divert the flight to San Francisco.

"I noticed the leak on the left side of the aircraft right behind the wing earlier during take-off," said Sergeant Bachleda.

Sergeant Bachleda continued analyzing the outflow of fuel to be 100 percent sure it was a leak while the plane was reaching cruising altitude. Almost an hour into the flight, he told a stewardess of the possible leak [emphasis added], but was given an unconcerned response.

...

Sergeant Bachleda said the captain and the crew were trying to figure out how the aircraft was losing 6,000 pounds of fuel an hour and then they knew exactly what was going on.

...

While conversing with the captain, the sergeant said he was hesitant at first to inform them about the leak, but he knew it was abnormal. The captain said they would have never made it to Japan if it wasn't for him.

the first draft i read in my feeds said the plane diverted back to chi-town, and then they went to SF because it's the other hub to Narita (i miss you TKO!). anyway, the impression i get from this .mil news report is that it is plausible that the plane could've flown out to the pacific before anyone noticed it was running low on fuel. i'm sure (?) they'd notice in time to divert to some island airstrip, but that's not the point...

for all the complexity and information being managed through the cockpit of the modern airliner, there is nothing that analyzes real-time information and says "you're in flying-gear and your fuel is dropping x% beyond the capacity of your engines to use fuel... LEAK!!!"

if you have devices that feed data into log servers, there's a lot of good info available... don't try to make some uber system for parsing data, b/c that's just perfection being the enemy of good. just parse for simple stuff that is clearly not right, b/c it's better than doing nothing.... who is hitting that explicit deny rule for outbound smtp on the firewall (b/c ppl other than your mail servers serving mail might be interesting... right?)? the number of messages received containing the word 'alert' or 'error' or 'critical' has changed by what percent over the last hour, day, and week? user xyz has 314 denied access attempts on network shares over the last hour. etc...

you're not looking to build some uber silver bullet, just a series of flashing lights to pull your attention to a particular area... without knowing too much about data, you can still put things within reasonable boundries and alert when something spikes... a built-in regexp based tuner for false-positives, and you're all set to learn some new stuff about your environment...

i've got some horrible mangled embarassing code stuffed away in this space, and since i'm building things out for some analysis coming up (and hopefully interesting blog foo) maybe i can break this out and get things ready for release... perhaps... if nothing shiny gets in my way... ;)

effective selective near real time mass communication?

today i saw the highway being shutdown along a route that some important person would presumably soon be traveling. i was able to observe some interesting operational details, and started pseudo-red-teaming the situation in my head looking for vulns.

i tweeted about the route, and that got me thinking about how much operational real-world security benefits from obscurity.

if someone was paying attention and could act upon the information i tweeted, it could present a significant security exposure. ZOMG!!!1! twitter is a terrorist tool!!! nono, that's not what I'm saying...

the amazonfail hashtagging phenomenon shows us something about it. If a grassroots group of people want to track a topic in near-real time, they can do it. soooo, loopin back to phy sec and operational security issues, hashtagging could be used to track a number of things which traditionally have been effective in-part due to obscurity, such as:

#roadblock
#sobrietycheck
#speedtrap

these are all candidates for multi-tagging with a #city hash to make them more useful.

i guess you could track celebrity locations in near-real time too:

#bradpitt #paparazzi
#clairedanes #stalker

orrrrr how about #flashmob #city.... or #hotclub #city.... or #riot #city... waitwaitwait...

anyway, the point (if there is one) is that no single person can make twitter give them this type of information, but if certain hashtags becomes popular grassroots phenomenons, they can significantly alter the effectiveness of traditional obscurity based physical security measures. even if #roadblock is never picked up, someone looking might be able to infer things using #traffic ;)


*update* - looks like i tweeted the route taken by the presidential motorcade...