Skip navigation

Sam Ransbotham
Sabayasachi Mitra

Presentation [PDF]

Twitter transcript

#weis2011 Does immediate disclosure of vulns affect exploitation attempts? Looking at impact on risk/diffusion/volume

#weis2011 speaker is presenting standard attack process & security processes timelines (slides will be in the blog post)

#weis2011 the fundamental question is when from the vulnerability discovery to patch development is disclosure appropriate

#weis2011 immediate disclosure places a significant amount of pressure on defenders while aiding attackers < yep. #weis2011 penalty for MSSP, IDS/IDP/malware vendors for not doing nigh daily "software updates" is huge. a very high pressure industry. #weis2011 IDS systems produce tons of records which needs to be analyzed and understood. results may or may not be actionable. #weis2011 *Tons* of neat data on analysis of NVD data. Very data rich slides (some of them). Lots of math. #good #stuff #weis2011 immediate disclosure has significant increase in acceleration of exploit devel only slight increase in penetration #weis2011 the window may open faster, but defenders are reacting really quickly. this has effect of causing attackers to stop attacks sooner #weis2011 vendors patch vulnerabilities that have been immediately disclosed faster than "traditional" ones. #weiss answer to a q: "the data does not support immediate disclosure for all vulns. no way to extrapolate that information"

Dr Greer [cgreer at ostp.eop.gov] is Assistant Director, Information Technology R&D, Office of Science & Technology Policy, The White House

Opening: “The expertise of the attendees is greatly needed.”

He provided a broad overview of the goals & initiatives of the federal government as they relate to domestic & international cybersecurity. Greer went through the responsibilities of various agencies and made it clear that this is a highly distributed effort across all sectors of government.

He emphasized the need for a close partnership with private sector to accomplish these goals and also the criticality of not just coming up with plans but also implementing those plans.

It really was a high-level overview and – as I point out in the twitter transcript – would have been cooler if Dr Greer did a deep-dive on 2-3 items vs do a survey. He did set the tone pretty well – we are in challenging times that are changing rapidly. We’re still fighting the fights of 5-10 years ago but are working to provide a framework for keeping pace with cybercrimminals. The government is “doing stuff”, but it’s all useless without translating thousands of pages of legal mumbo jumbo into practical, actionable activities.

The 10 minute post-talk Q&A was far better than the actual preso.

Twitter transcript:

#weis2011 Obama: "America's economic prosperity in 21st cent will depend on cybersecurity" :: sec begets growth but underscores threats, too

#weis2011 one time we never expected every individual to need an IP address, now even refrigerators have one.

#weis2011 IPv6 need exacerbated by mobile, mobile apps themselves have great benefit, but also introduces new threat vector.

#weis2011 OSTP runs phishing tests 3x year #spiffy

#weis2011 POTUS Strategy: Catalyze brkthrus for natnl priorities, promote mkt-based innov; invest in building blocks of american innovation

#weis2011 policy review (2009) themes: lead frm top;build cap for dig natin;share resp for cybersec;effective info sharing/irp; encrge innov

#weis2011 pimping the International Strategy For Cyberspace release recently http://1.usa.gov/jZXIdE

#weis2011 key "norms" in ISC report: upholding fundamental freedoms (esp speech), global interoperability & cybersecurity due diligence

#weis2011 Greer shifting to talking about legis; OSTP has been wrkng to promote good bills esp for natnl data breach rprting & penalties

#weis2011 computer fraud & abuse act is *25 years old*. We need new regulations to help fight 21st century crime < 25 years! yikes! #weis2011 FISMA shifting from compliance-based to proactive protection-based; mentioned EINSTEIN IDS/ISP #wes2011 pimping http://csrc.nist.gov/nice/ education & awareness efforts #weis2011 pimping fed trusted ID initiative http://www.nist.gov/nstic/ ; password are $ & failing; multiple accts are real & problematic #weis2011 (pers comment) the audience knows much of what Greer is saying, surprised he's giving such a broad overview vs 2/3 deep dives #weis2011 (pers comment) the efforts for fed cybesec seem waaay to disjoint & distributed to truly be effective. #weis2011 pimping fed trusted ID initiative http://www.nist.gov/nstic ; password are $ & failing; multiple accts are real & problematic #weis2011 pimping http://www.nitrd.gov/ CSIA, SSG & SCORE < much alphabet soup in fed cybersec…the letters didn't help senate.gov today #weis2011 results of many research efforts are both near & just over the horizon, but all useless if not put into effective practice #weiss2011 impt to work with priv sector on economics of legis&policy choices (immunity/liability/safe hrbr/incentives/disclosure/audit) #weis2011 need to understand market factors incentivizing hackers (valuation/cost-ben/risk-decision making/criminal markets) #weis2011 (pers comment) another poke at Microsoft when talking about server security. Major hacks of late were linux/apache/solaris. #lame #weis2011 Cyber insurance is a possibility if we can develop good quant-based risk assessment/management frameworks #weis2011 cgreer@ostp.eop.gov #weis2011 q:"where will cybersec be in 10yrs?" -cyberspace will be more resilient & trustworthy; hardening sys&nets useless w/o educatng ppl #weis2011 by 2021 we will have solved all the cybersecurity issues of 2005 < wise man #weis2011 q:"the US spends > than rest of wrld combined on cybersec but it's still just pennies. will this change?" :: it's in the proposals

If you are concerned about the Dropbox design flaw exposed by the dbClone attack, then have we got a link for you!

The intrepid DB devs have tossed up a forum release which purports to fix all the thorny security issues. You can no longer just copy a config file to a separate machine to clone a filesystem and the file itself is now also encrypted. (Forum builds do not automagically download like standard Dropbox updates)

Given the fact that Dropbox did not prompt me for any credentials when I started the new version, I’m still a bit skeptical that it has truly fixed the problem. Given my schedule today, I doubt I’ll have time to poke at it before someone else does, but the thoroughness of this fix does need to be independently validated. The local Dropbox client has to be getting the encryption key/passphrase from *somewhere*, and if it’s not prompting me on start, then it’s stored online or locally and that’s a recipe for another hack.

There is nothing overt in the application bundle (looking on OS X) or quickly discernable from a dump of a few of the app’s .pyc files. Granted, a bit of obfuscation will stop the current hack and dissuade some other sophomoric attempts, but I can almost guarantee that the passphrase (or the algorithm one needs to discern the passphrase) will be found by folks.

The new build replaces your local configuration file with a new, encrypted one (now named config.dbx). I didn’t see signs of either SQLiteEncrypt, SEE, SQLCipher or SQLiteCrypt but haven’t had time to dig more thoroughly. It’s completely possible the Dropbox devs just built an encryption layer over the Dropbox calls themselves (which is not a difficult task).

Please note that forum builds are not necessarily stable and that this is a pretty major architecture change. I had no issues on OS X, but I suspect that any micro-errors in your SQLite config.db may cause some heartache if you do attempt the upgrade. Best to wait for a full production release if you do not have your Dropbox backed up somewhere.

UPDATE: I have intentionally cross-posted this to my SIRA blog since the combined wit & intelligence of the folks there trumps anything I could do alone here.

All the following newly-minted risk assessment types have been inspired by actual situations. Hopefully you get to stick to just the proper OCTAVE/FAIR/NIST/etc. ones where you practice.

  • HARA :: Half-Assed Risk Assessment — When you are not provided any semblance of potential impact data and a woefully incomplete list of assets, but are still expected to return a valid risk rating.
  • CRA :: Cardassian Risk Assessment — When you are provided the resultant risk rating prior to beginning your risk assessment. (It’s a Star Trek reference for those with actual lives)

    We’re going to do x anyway because we don’t believe it’s a high risk, but go ahead and do your assessment since the Policy mandates that you do one.

  • IRA :: Immediate Risk Assessment — This one has been showcased well by our own Mr. DBIR himself on the SIRA podcasts. A risk assessment question by a senior executive who wants an answer *now* (dammit)! It is often phrased as “Which is more secure, x or y?” or “We need to do z. What’s the worst that can happen?“. You literally have no time to research and – if you don’t know the answer – then “Security” must not be very smart.
  • IRAVA :: In Reality, A Vulnerability Assessment — When you’re asked to determine risk when what they are *really* asking for what the vulnerabilities are in a particular system/app. Think Tenable/Qualys scan results vs FAIR or OCTAVE.
  • IOCAL :: I Only Care About Likelihood — This is when the requester is absolutely fixated on likelihood and believes wholeheartedly that a low likelihood immediately means low risk. Any answer you give is also followed up with “have we ever had anything like x happen in the past?” and/or “have our competitors been hit with y yet?
  • AD3RA :: Architecture Design Document Disguised As A Risk Assessment — When you are given all (and decent) inputs necessary to complete a pretty comprehensive risk assessment but are then asked to include a full architecture design document on how to mitigate them all. The sad truth is, the project team couldn’t get the enterprise architects (EA) to the table for the first project commit stage, but since you know enough about the technologies in play to fix the major problems, why not just make you do the EA dept’s job while you are just wasting time cranking out the mandatory risk assessment.
  • WDRA :: Wikipedia Deflected Risk Assessment — When you perform a risk assessment, but a manager or senior manager finds data on Wikipedia that they use to negate your findings. (Since – as we all know – Wikipedia is the sum of all correct human knowledge).

If you are also coerced into performing an insane risk assessment that doesn’t fit these models, feel free to share them in the comments.

Spent some time today updating the missing bits of the OS X version of the Dropbox cloner I uploaded last night. You can just grab the executable or grab the whole project from the github repository.

The app can now backup/restore of local config, clone dropbox configs to a URL/file and also impersonate a captured Dropbox config.

Use it all at your own risk. As stated in the original post, all comments, bugs, additions, fixes etc. are welcome either here or at github.

UPDATE: Check out the newer post on additional features.

There has been much ado of late about Dropbox security with one of the most egregious issues being how easy it is to surreptitiously “clone” someone else’s Dropbox by obtaining just one piece of data – the host id – from the Dropbox SQLite config.db.

Moloch built a Windows & Linux impersonation/cloning utility in Python that was/is meant to be used from a USB/external volume. The utility can save the cloned host id to a local file and also has the capability to use a simple HTTP GET request to log data to a “mothership” web site.

Since many Dropbox users use OS X (including me) I didn’t want them to feel left out or smugly more secure. So, I set about creating a native version of the utility.

This release is not as feature-rich as Moloch’s Python script but it won’t take much more effort to crank out a version that duplicates all of the functionality. “Release early. Release often.” as the kids these days are wont to say.

You can find the source at its github repository. When building it or just downloading & running the executable (see below), you should heed the repo’s README and take care to change the following items in the application’s Info.plist property list:

  • MothershipURL – this is the URL of the remote host you want to store the cloned info to. It defaults to somesite.domain/mothership.php to avoid accidentally sending your own Dropbox data to a remote host. PLEASE NOTE that you will need to get the mothership.php script from the original Windows/Linux code distribution as I have not asked for permission to distribute it here. You can grab the original dbClone.rar directly from here: dl.dropbox.com/u/341940/dbClone.rar (I love the irony of it being hosted on Dropbox itself).

    ALSO NOTE that there’s no need to modify the application’s property list if you don’t mind typing in a URL each run. I eventually plan on making this a separate property list file that allows for multiple URLs so you can select it from a drop-down (and still type a new one if you like).

  • LogFilenamejust include the filename you want to use when storing the cloned info locally if you do not like the default (it’s the same as Moloch’s – "GroceryList.txt"). It defaults to the top-level of the mounted volume (the original Linux & Windows dbClone was meant to be run from a USB/external volume) or "~/" if running it on your boot drive.

You can use the property list editor(s) that come with Apple’s Developer Tools or use vim, TextEdit, TextWrangler (or your favorite text editor) and modify these lines appropriately:

[code]
<key>LogFilename</key>
<string>GroceryList.txt</string>
<key>MothershipURL</key>
<string>http://somesite.domain/mothership.php</string>
[/code]

If you do use the “backup” option, the current naming scheme is "backup-config.db" and it”s important to note that the program will not attempt to overwrite the file. I may change that behaviour in an upcoming release.

I tested the build on OS X 10.6.7 but the Xcode project is set to build for compatibility with 10.5.x or 10.6.x. Feedback on behaviour on other systems would be most welcome.

If you just want the executable, grab the zip’d app and give it a go.

Any and all feedback is welcome (via github or in the comments).

One of my most popular blog posts — 24,000 reads — in the old, co-mingled site was a short snippet on how to strip HTML tags from a block of content in Objective-C. It’s been used by many-an-iOS developer (which was the original intent).

An intrepid reader & user (“Brian” – no other attribution available) found a memory leak that really rears it’s ugly head when parsing large-content blocks. The updated code is below (with the original post text) and also in the comments on the old site. If Brian reads this, please post full attribution info in the comments or to @hrbrmstr so I can give you proper credit.

I needed to strip the tags from some HTML that was embedded in an XML feed so I could display a short summary from the full content in a UITableView. Rather than go through the effort of parsing HTML on the iPhone (as I already parsed the XML file) I built this simple method from some half-finished snippets I found. It has worked in all of the cases I have needed, but your mileage may vary. It is at least a working method (which cannot be said about most of the other examples). It works both in iOS (iPhone/iPad) and in plain-old OS X code, too.

– (NSString *) stripTags:(NSString *)str {

NSMutableString *html = [NSMutableString stringWithCapacity:[str length]];

NSScanner *scanner = [NSScanner scannerWithString:str];
NSString *tempText = nil;

while (![scanner isAtEnd]) {

[scanner scanUpToString:@"<" intoString:&tempText];

if (tempText != nil)
[html appendString:tempText];

[scanner scanUpToString:@">" intoString:NULL];

if (![scanner isAtEnd])
[scanner setScanLocation:[scanner scanLocation] + 1];

tempText = nil;

}

return html ;

}

I tweeted a quick note about the 2010 Maine Department of Conservation state park pass ordering system breach. The brief AP story indicated that the breach itself was caused by a malware infection on systems at their SasS provider InfoSpherix.

While the article claims notices were sent to ~1,000 impacted card holders, there is no mention of the breach on the InfoSpherix news page and the only bit of information on the Maine DoC site is pitiful and uninformative:

Click image for larger version

Both organizations may have met the bare minimum legal requirements for beach notifications, but I find it shameful that they have not made the information more public. How are other companies supposed to learn from the mistakes of others and how will lack of open disclosure help consumers ask tougher questions prior to giving away they keys that unlock their finances?

It’s also pretty sad (but not uncommon) that the actual breach occurred on March 21st last year but wasn’t discovered until February of this year and that it took them over a month to report it out.

While there is the claim that the breach only impacted the park pass ordering system, InfoSpherix is a division of a larger organization that provides a plethora of services for recreational facilities. I’m actually a bit concerned that other systems may have been impacted (hey, if they didn’t detect it on these for almost a year…) and – if you’ve registered for a campground online – you have most likely used one of them. Not. Cool.

Oh yeah, before I forget, I wanted to ask InfoSpherix how that PCI compliance is working out for them? Perhaps checkbox stickers on the equipment would have helped stave off the intruders. #protip

You can at least read a few more details of the breach over at DataLossDB.