countermeasures for command & control

~irl blue skies sec post~

been sittin on this for a bit, and the recent predator security issue is a great place to start.

[recap]
a year ago militant gear was discovered with predator video feeds. aquire satellite dish, point up, download software, and *poof* record yourself some killcam videos... kinda like snoopin on webcams... ;)

turns out the vuln was known for about a decade. (incidentally, in bosnia in 1998 seals reportedly used a remote controlled plane with recon gear to hunt their quarry. this is the earliest squad level military uav activity afaik, and the dates lines up pretty nice... can you imagine what toys those guys use today?)

oh, and the vuln exists in tons of military devices, including many items which have been mass produced and widely deployed... whoops...


[erm, wot?]

well, lots of "similar" civilian devices have similar utter failure in the network security realm (voip phones or printers anyone?)... some people feel that fixing vulns like this is paranoid, and they aren't likely to be exploited. well i guess someone trying to blow you up is pretty damn motivating...


[lesson learned?]

rapid prototyping software without a clean upgrade path for fixing these potentials issues is a recipe for failure. also, desperation drives innovation (evolution in action in this case). and fix it in the field can bite you in the ass...


[back to the point]

there are lots more remote controlled and automated devices nowadays... some are pretty wicked in kinetic situations, and others are more passive... some are pretty small, or tiny, some are big, and some have guns. some can jump... some are being used in civilian areas as well (some people protest in humorous ways). some just keep on going.

oh, and militants use them too...

yea, researchers are growing remote controlled bugs... and they mimic bugs and nature too...

so clearly there's a lot of activity and nifty/scary tech in the space...


[attack surface update]

pulling the operator physically out of the loop means that network comms are somewhat more critical and vulnerable than before.


.:location:.
jamming a gps bomb doesn't make tons of sense because the military and spooks have plenty of options in that space. but do smaller and widely deployed surveillance devices and attack platforms using gps utilize anti-jam gps technology?


.:communication:.
how many smaller drones are vulnerable to standard RF interference and jamming? small powerful jamming devices might be able to create a small null zone where remote operated devices are unable to maintain comms with their operators.


.:sight:.
drones generally rely on digital cameras, which begs the question if they can be dazzled and disabled by lasers or strong infrared light sources, a la michael westen

also, thermal cameras seem very common, so i wonder if there are any effective thermal countermeasures? that seems difficult, but who knows...


.:detection:.
can the c&c comm traffic be detected in general? is it possible to cheaply monitor likely radio bands for encrypted (or not) network traffic to alert on a suspected drone presence? or is background RF too much here? if you can detect the c&c traffic, can you get directional information similar to passive radar?

and can the cameras used by visual surveillance platforms be detected (trivially?) like sniper rifle lenses?


.:destruction:.
at least one drone killed itself when a transmission triggered an auto-shutdown procedure, which sounds like there was no authentication on that particularly vital command option... (different than the reported russian take on self-destruct mechanisms...)

and can effective small (and safe) EMP generators be used to knock out nearby drone and surveillance devices? no idea on ranging, or directional vs bubble... no idea if a pulsing emp could be used to maintain a safety zone (and would it be practical considering you'd be frying any nearby electronics of your own, right?)


[anywho]

ultimately, it seems likely that smaller drones will have cost and power-utilization pressures which increase their vulnerability to attacks on their comms...

kinda rambled a bit, but hope you enjoyed it...

xss introduced by an intermediate security device

during a web app assessment there were some apache HTTP Host and Expect header XSS vulns reported, but the version of apache running on the server was newer than the affected versions and shouldn't be vulnerable.

looking closer at the data i realized there were security devices inline during the assessment (*my bad*)... hrmmmmm....

so i found an unfiltered connection, and sure enough the web server was properly output encoding the responses:

GET / HTTP/1.1
Host: www.someserver.tld
Expect: <script>alert('XSS');</script>

=-=-=-=-=-=-=-=-=-=-

HTTP/1.1 417 Expectation Failed
Date: Sun, 01 Nov 2009 03:03:03 GMT
Server: Apache/2.x.x
Content-Length: 488
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>417 Expectation Failed</title>
</head><body>
<h1>Expectation Failed</h1>
<p>The expectation given in the Expect request-header field could not be met by this server.</p>
<p>The client sent<pre>
Expect: &lt;script&gt;alert('XSS');&lt;/script&gt;
</pre>
but we only allow the 100-continue expectation.</p>
<hr>
<address>Apache/2.x.x Server at www.someserver.tld Port 80</address>
</body></html>

so back to the filtered connection. here the intermediate security device examines the request, sees the unexpected / error condition, and informs the user. but in the error page they are reflecting user controlled content without output encoding it... doh:


HTTP/1.1 500 Unknown Host
Date: Sun, 01 Nov 2009 19:19:19 GMT
Connection: close
Via: HTTP/1.1 sec-device-hostname (********-Content_Gateway/7.x.x [x x x ])
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Content-Length: 463

<HEAD><TITLE>Unknown Host</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black"><H1>Unknown Host</H1><HR>
<FONT FACE="Helvetica,Arial"><B>
Description: Unable to locate the server named "<em><script>alert('XSS')</script></em>" --- the server does not have a DNS entry. Perhaps there is a misspelling in the server name, or the server no longer exists. Double-check the name and try again.</B></FONT>
<HR>
<!-- default "Unknown Host" response (500) -->
</BODY>

=-=-=-=-=-=-=-=-=-


HTTP/1.1 417 Expectation Failed
Date: Sun, 01 Nov 2009 19:19:19 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>417 Expectation Failed</TITLE>
</HEAD><BODY>
<H1>Expectation Failed</H1>
The expectation given in the Expect request-header
field could not be met by this server.<P>
The client sent<PRE>
Expect: <script>alert('XSS');</script>
</PRE>
but we only allow the 100-continue expectation.
</BODY></HTML>


we all make mistakes i guess :(

so there's nothing earth shattering here. i don't think there's a risk of wide spread issues, but maybe targetted attacks. and all from installing a security device. bleh...


***update: more of the same - http://rwnin.blogspot.com/2010/03/more-xss-introduced-by-security-devices.html***

web app sec dev guidelines

Here's a list of guidelines to help developers create more secure web applications. This info was based around the OWASP WASS project and the app sec STIG.

The general idea is to set the expectation on what gets audited during a web application security assessment and help developers code things up better the first time around...

http://sites.google.com/site/rwninsecurity/webappsec_dev_guide

Feedback/suggestions welcome!

tiered architecture revisited

[background]

recently "bob" told me about a situation which seemed simple: a dmz web server with a back end db on the trusted network was being upgraded. the IT staff started loading the new db software on the web server, breaking the tiered architecture model.

bob and i initially agreed this was bad, but let's play devils advocate for a minute.


[the tiered model]

the tiered model separates presentation, app logic, and db roles onto different hosts, and *is often implemented as*:



if the exposed front-end web server suffers a host compromise, the business-logic and data aren't immediately compromised, and the attacker will have trouble attacking these systems further because of tight fw policies between the dmz and trusted zones. well, that's the theory...


[problems?]

so why is this maybe silly? ask a pen-tester how they feel when they get an external network assessment where webapp and soc-eng are off limits... they groan and cuss, because many/most organizations today have gotten pretty good at limiting inet facing services and keeping inet facing hosts patched and up to date.

but those same inet facing web apps have logical ties back to systems which often reside on the internal network. application layer attacks like sql injection tunnel through the firewall on the back of trusted application functionality.

the tiered model defends against host vulns, but not app vulns. and are host vulns really more prevelant than app vulns today?

plus, how much protection do you actual get from the tiered model if a host level compromise occurs? the web server can be defaced, credentials can be stolen, and all the back-end data presented to users flows back and forth through the presentation layer. so is there a substantial security gain here?

maybe one can look at apps and equate parameters to listening services on hosts? they accept input and process it, and are vulnerable to attack. if you equate parameters to listeners (i know it's not a perfect comparision) then the attack surface on a web application is larger and more vulnerable than host services on the average inet facing segment.


[well we have WAFs, right?]

srsly? rly? i donno... i haven't seen these devices work in real-world environments yet, so i don't have much faith. they are either 'self-learning' models which prevent mainly simplistic automated attacks, or they are manually configured models which are nearly impossible to keep properly tuned. maybe some orgs have highly effective WAF deployments, but i haven't seen or heard about it...


[sooooo?]

isolating a presentation server in a high-security zone but letting it connect back to other machines in the trusted zone just isn't a good idea. there are at least a couple ways to improve this model.

if the tiered model is used, then all of the tiers should reside in their own DMZs. that way, when the database server gets owned via sqli and the attacker is pivoting to the next target, he'll be isolated in the db DMZ. maybe this is what the tiered model was always intended to be, but it isn't something i've seen very often on real-world networks. plus, an org willing to put in the time and effort to run 2 or 3 DMZs, they will probably also parameterize their queries, validate their inputs, encode their outputs, and make sure that the db app user isn't over-privileged.



a simplier alternative for some applications is to abandon the overhead of running multiple tiers and go back to a single-machine model. the machine can be isolated on a DMZ, and the content served by the application can be managed through a one-way push from the trusted network (trust -> DMZ only). this model has an advantage that the exposed machine has no connection back to the internal network. plus you have an on-site backup on your trusted network.



but if the apps gets a lot of input from users which is stored to be used in near-real-time by other applications or processes, the isolated push model fails because that data needs to be read back into the trusted network and the same injection vulns apply.


[anywho]

is there something obvious i'm missing? there's nothing amazing here, but it seems like the common implementation of the tiered model buys you very little in terms of security...?

looking in the mirror

just came across a tidbit of info that i'd forgotten, and it got me thinking about my op-sec

i use my handle for fun, and there are a few places where i choose to tie it to my IRL info. at cons i tell people my real name and my handle, and there are obvious places where my IRL geogrophy is publicly revealed. i'm not out there commiting crimes or tryin to be an uber-reet hax0r, so i'm not too worried about that.

but i recently started re-doing my home network, and although i do a lot of good defensive foo, there's definately some stuff i noticed that wasn't right. some things pointing to my home network that didn't really need to be there. there were gaps in visibility and logs. some files and directories that i dropped on my box but never moved into the right cryptographic containers. tracking down inet accounts that aren't often used, i realized there are a number of passwords which aren't strong enough and/or haven't been rotated recently enough. machines which were not hardened.

it's easy to let things slip when you're doin sec from 9-5 and just wanna hang out w/ the fam and/or veg-out w/ hulu when you get home. it's not always easy step up and take the extra steps that need to be done to track down the details and stay on top of your environment.

i've got friends who have awesome op-sec and go the extra mile. i need to keep them in mind when i make decisions about my environment...

yea, i've seen people get popped who made bigger mistakes than me. but that doesn't matter if it's my mailspool and / or my filesystem.

a buddy of mine commented that it sux there are ppl out there makin us scared of teh pwnage. i agreed at the time, but really i donno. attackers are a reminder... a buzz in our ear, the angel and the devil on our shoulders reminding us that we do this stuff full time. if we can't run our own houses, why should anyone trust us to help them?

sometimes it's tough to look deeply in the mirror, but ultimately it only helps. it's painful to see the truth with warts and all, but you can't make something better until you understand what it really is.

quick vmware perf foo (lameeee non sec post)

i was sick of my win VM running sooo slowwwww, so i defragged the 'drive' using the windows defrag utility. then every time i booted my win vm my lptp hdd thrashed and thrashed and performance was worse than before...

so i found out there's a defrag util for VMs... anyway, after a few pitfalls here's a concise description of the tasks:

vmware-mount /path/to/file.vmdk /mnt/
vmware-vdiskmanager -p /mnt/
[kill some time while the vmdk preps]
vmware-mount -d /mnt/
vmware-vdiskmanager -k /path/to/file.vmdk
[kill some time while the vmdk shrinks]
vmware-vdiskmanager -d /path/to/file.vmdk
[kill some time while the vmdk is defragged]


so i ended up w/ a free 30 gig of space after shrinking the disk, and everything is running pretty snappy again. you need at least as much free space on your disk as the size of your vmdk in order to perform the shrink and defrag operations...

time to go write some reports... >sigh<

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...

quick misc blurbage

sqlmap: the new version sounds pretty niftified... reading the whitepaper atm.

GreenSQL: on the other side, this tool sounds potentially nifty... a reverse proxy for SQL connections which uses positive and negative security models. perhaps granular proxies like this can be combined with WAFs to provide reasonable app-layer protection, or perhaps you'll just end up with a huge blog of false-negatives and false-positives and an unmanageable nightmare ;)

Joint Strike Fighter theft: so add another tally for china i guess (unverified). the bit that stands out to me is that the volume of information stolen was "several terabytes". gonna take a step back from the hype and just point out that very low-tech things like a human watching network flows and trends based on protocol and destination might've been helpful here. maybe some lost-cost common sense defensive controls will come out of the DoD hiring hackers... it'd be an interesting network to try to defend...

vapor client sec app, and futher ramblings...

now that it's CFP time, i'll revisit an idea from years past.

everyone pretty much accepts that AV blacklisting fails. modern behavioral AV appears to be hit and miss. imo, whitelisting is the way to go.

a while back i thought it'd be interesting to leverage the features of rootkits into a defensive security device. the crux of it was to have a rootkit that examined every program prior to execution or during execution, and if it isn't an approved and signed app, it can't run.

whitelisting is a challenge on a couple of levels:

• how do you stay up to date with releases, patches, etc
  
• how can you decide programs aren't malicious?
  
• surely more...?
  

staying up to date will require some dedicated cycles or service for evaluating new apps, accepting requests for missing apps, etc. i've been thinking that there might be value in starting an OSS community project to identify and sign non-malicious apps.

that leads into how do you decide an app isn't malicious? the basic idea i had was for a service to run software on VMs for a period of time, and examine the traits of the software and how it has updated, impacted, and utilized the system. using AIDE HIDS style examination of the filesystem changes, watch for network traffic, watch for changes to the OS in memory, etc. you may even be able to write an algorithm to try to take a human analyst out of the picture, but it'd probably be tricky.

if you do this, one other concern is malware which sleeps for a time-delay before becoming overtly malicious. maybe you could do static analysis on the executable and enumerate all the functionality. or you could run it in a vm over time, and instead of reporting something as secure/insecure, maybe you give it a security rating based on the length of time it's been analyzed (say in a VM out in the cloud in some SaaS AV whitelisting business model). the customer gets a portal which lets them see the trust rating of given apps, and can assume the risk of running any given app in their environment.

i found out that a company called fireeye does some really interesting heuristic AV work which does a similar HIDS type analysis of executables. i was pretty impressed with their presentation, if only from the standpoint of doing AV out of the box, but i haven't had a chance to see the product in action yet.

anyway, some people get down on whitelisting because it's too difficult to admin, and isn't perfect, etc etc. personally, looking at enterprise endpoint management, the tradeoffs make sense to me. an imperfect whitelisting solution which has administrative overhead should pay for itself in reduced malware cleanup, os reloads, incidents, etc.

since windows is a reality in enterprise environments, i'm looking forward to spending some time with AppLocker in Windows 7 to see if there's a chance to roll out a whitelisted set of apps along with the OS in the coming future... seems like a huge chance for a security win, if the project can be designed and implemented properly....

that's all, for now...

rw sec blurb

the overlaps in rw-sec and infosec tempt me into running astray w/ my blog posts from time to time... here is one of those times...

ran across this article about how obama is using the 'state secrets' bit to block lawsuits fighting the warrantless wiretapping program. rather than delving into any political bs, i want to try to examine motives here...

why would obama, who is generally seen as far opposite of bush, support one of the single most controversial programs and legal positions of the bush administration?

• lack of moral character: he betrays key asserted ideals once he assumes the throne
  
  
• pressure from hidden powers: intel agencies (et al) force his hand in some political thriller type scenario
  
  
• executive power precedent: now that the executive branch has asserted such broad authority under the premise of national security, it would be moronic to give that power up (i blogged supporting this position earlier)
  
  
• sources & methods: there is significant intel value in this program, or in a related undisclosed program
  

at the moment i hate to learn towards the 4th option, but i am. i think executive power is still a compelling argument ("oh, i won't use this great power for evil!"), but maybe once he got briefed in he found out that there is value here. no matter if they ID'd Atta or not, it's clear that Abel Danger demonstrated a continued commitment to generate info from data for signals intel... perhaps the next generation programs are bearing fruit...

so pointless to speculate about really... anywho, maybe infosec posts again someday?

quick quotage

wow, it's been a long time since i posted... been really busy w/ work, life, etc... anywho, i was catching up on feeds, and felt like this quote from joanna is worth sharing:

does the fact we can easily compromise the SMM today, and write SMM-based malware, does that mean the sky is falling for the average computer user?

No! The sky has actually fallen many years ago… Default users with admin privileges, monolithic kernels everywhere, most software unsigned and downloadable over plaintext HTTP — these are the main reasons we cannot trust our systems today. And those pathetic attempts to fix it, e.g. via restricting admin users on Vista, but still requiring full admin rights to install any piece of stupid software. Or selling people illusion of security via A/V programs, that cannot even protect themselves properly…

;)

hittin the hash | yet again

hashes and collisions have been on the back-burner for a bit now w/ recent hullabaloo...

so the thought that keeps coming back (reminder: /me != math guy) came from my experiences w/ gentoo... either the kernel or portage (but not both ;) used .sig files which contained multiple hashes for verification of the download integrity.

so say you've got a 1/x chance of collision in md5 and a 1/y chance of collision in sha1 (assuming that x & y are both reasonably large numbers), then isn't the likelihood of getting a collision of *both* hashes on the same file exponentially larger than getting a collision on x or y individually?

so if we're really worried about the apparently real weaknesses in some md5 and the up and coming realistic weaknesses in sha1 (via that chinese-professor-ninja-woman & her math students iirc), why not just start checking multiple hashes each time we verify integrity?

no new technology needed, just parse more than 1 value before you evaluate that if/then to true, right?

the birds n the bees

i've heard that nature repeats itself at different scales. seems reasonable to me. i know that nature has a lot to teach us (and if you don't, then sry but you're not paying attention)... so let's play around w/ analysing some attack and defence in nature and see where we end up..,

source article about bee's which may or may not be getting completely pwnt

beekeepers that didn't suffer from Colony Collapse Disorder, or had only a touch of the plague, made changes too, and they are still around and in fact are doing well and growing. Those changes have been huge in terms of what they have managed to do with the number of colonies they have, and even more so in terms of the paradigm shift in colony management techniques.

wait... orgs are supposed to adapt?

the major shift has been in how beekeepers monitor for, and control varroa mites in their colonies.

monitor the health and activity of network participants? what?!?

Better techniques are being used to find and count mite populations, and safer and kinder techniques are being used to control those mites.

are you one of those managers who told a motivated employee that dedicating time to review logs doesn't matter? for shame! for shame!!

This is good because mite populations don't build up to lethal numbers, lots of mites aren't able to pass along destructive viruses, and the control agents previously used are no longer building up inside the colony.

in my experience, manual intrusions seem to involve a period of time where the intruder evaluates and probes prior to executing whatever plan they have to help themselves at your expense. looking for signs of intrusion (logs!) is vital...

Beekeepers are feeding their bees more food when food is scarce, feeding them at a more appropriate time in the season, and feeding them better food. All have contributed to better wintering, better buildup, and healthier colonies.

what? support and nurture the business?!? crazy-talk!!! (lol)

flags aren't always true

srsly, we know this....

anyway, so the official story is that (an) al-qaeda cell(s) in Algeria are dying because they caught the black death... unfortunate side-effect which occurs when attempting to kill the american devil w/ biological hazards...

forgive me, but while the whole 'omfg terrorists w/ bio-agents' story is quite striking, i kinda expected red threat levels and all of that.

but you could consider an alternate view-point... the black death is highly curable. so if you infected hostile covert operatives with it they would spread it to their allies (your enemies!) who would be faced with either death or treatment at a hospital (oh, the black death you say? i'm sure the security services aren't interested in anyone with *that* old disease).

just a random thought...

noscript feature

ok, so peeps around me might've heard me blabbing on and on about my exciting noscript 'discovery'... i stumbled upon functionality i thought was weird while searching for sharpening stones for my katana (ironic but true).

anyway, i procrastinated research for a month or so, and when i realized i wasn't going to fuzz each html tag for js execution i emailed giorgio... that deflating sound is my ego:

many thanks for the PoC.

Is it just about links going back and forth in history working?
If so, fortunately that's a feature, not a bug: NoScript Options|Advanced|Untrusted|Attempt to fix JavaScript links.
In order to make user's life easier, NoScript tries to detect JavaScript links used for navigation purposes (e.g. containing an URL or resembling a back/forth history navigation) and "emulate" them on the fly *by design*.
If you want, you can disable this feature from the aforementioned configuration option.

Please let me know if I'm missing something more malicious.

Thank you again
--
Giorgio

i respond:

oh wow! rtfm & bad on me! ;) ok, well the things that seem malicious are all subtle imo.

the fact that .go() can be used for arbitrary navigation kinda seems dangerous. even though you'll be running noscript wherever you end up, it could be used to exploit a vuln that noscript doesn't protect against (possibly flash, pdf, etc).
...

and giorgio disagrees:

no "automatic navigation" can be triggered, because of the way this feature works: it reacts on *user click*, checks if the clicked item is a link (either an anchor or a map or a button) and tries to "guess" the destination by simple string parsing, then emulates the navigation.

Cheers

well, i'm not going to get into an infosec pissing match w/ a guy who's contributed more to protect end-users than i prolly ever will... sigh...

i was really surprised to find script execution when i had ns set to not allow scripts globally.

for the navigation feature, i've got no click generating foo atm. iirc there are things that can be done to overlay pages and catch clicks.

for the sandbox fun, nursing my bruised ego kept me away from coming up w/ a way to smuggle the information back to the attacker. but my understanding of infosec suggests that giving someone a way to discover information about a system (file exists, exists but you don't have perms, exists and is executable, and doesn't exist) is not optimal. also, prompting a user w/ a download dialogue seems dangerous, even for local files.

anyway, i've put up a quick PoC for the stuff i was playing with...

winter cleaning time

was out in cali visiting my folks, and got into an infosec discussion w/ dad (who sat patiently while i ranted for a *while*).

on the topic of best practices i was talking about password rotation and pushed an idea i've been kickin around (but which has roots w/ @shawnmoyer)... i've been thinking of doing a livecd experiment (really, someday soon), and for a less extreme suggestion i brought up treating your OS install as a replaceable session. do quarterly rotations, or whatever.

doing this limits the lifetime of a lot of compromises, ensures that recent (restorable) backups exist, and pushes you towards a core set of applications which are being kept up to date.

he asked if i was doing this myself, and i owed up and said no. so now i am. bleh, me and my big mouth... ;)

anywho, i'll be linking up interesting docs and stuff here when i find em...