Skip navigation

Author Archives: hrbrmstr

Don't look at me…I do what he does — just slower. #rstats avuncular • ?Resistance Fighter • Cook • Christian • [Master] Chef des Données de Sécurité @ @rapid7
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.

One of my subdomains is for mail and I was using an easy DNS hack to point it to my hosted Gmail setup (just create a CNAME pointing to ghs.google.com). This stopped working for some folks this week and I’ve had no time to debug exactly why so I decided to go back to a simple HTTP 301 redirect to avoid any glitches (for whatever reason) in the future – or, at least ensure the glitches were due to any ineptness on my part. Unfortunately, this created an interesting problem that I had not foreseen.

I started playing with Strict Transport Security (HSTS) a while ago and – for kicks & some enhanced WordPress & Drupal cookie security – moved a couple domains to it. I neglected to actually pay for a cert that would give me wildcard subdomain usage and only put in a couple domains for the cert request. I neglected to put the mail one in and that caused Chrome to not honor the redirect due to the certificate not being valid for the mail domain.

I tweaked theStrict-Transport-Security header setting in my nginx config to not include subdomains, but it seems Chrome had already tucked the entry into (on OS X):

[code padlinenumbers=”false” gutter=”false”]~/Library/Application Support/Google/Chrome/Default/TransportSecurity[/code]

and was ignoring the new expiration and subdomain settings I was now sending. Again, no time to research why as I really just needed to get the mail redirect working. I guessed that removing the entry would be the easiest way to bend Chrome to my will but it turns out that it’s not that simple since the browser seems to hash the host value:

[code]"wA9USN1KVIEHgBTF9j2q0wPLlLieQoLrXKheK9lkgl8=": {
"created": 1300919611.230054,
"expiry": 1303563439.443086,
"include_subdomains": true,
"mode": "strict"
},[/code]

(I have no idea which host that is, btw.)

I ended up backing up the TransportSecurity file and removing all entries from it. Any site I visit that has the cookie will re-establish itself and it cleared up the redirect issue. I still need to get a new certificate, but that can wait for another day.

Windows and Linux folk should be able to find that file pretty easily in their home directories if they are experiencing any similar issue. If you can’t find it, drop a note in the comments and I’ll dig out the locations.

Had to modify the latimes URL in the post due to a notice from Wordfence/Google

I was reviewing the – er – highlights? – from the ninth ERM Symposium in Chicago over at Riskviews this morning and was intrigued by some of the parallels to the current situation in enterprise security risk management (the ERM symposium seemed to be laser-focused on financial risk, which is kinda sad since ERM should make security/IT compliance risk a first class citizen). Not all topics had a 1:1 parallel, but there were some interesting ones:

  • Compliance culture of risk management in banks contributed to the crisis :: While not necessarily at crisis levels yet, the compliance culture that is infecting information security is headed toward this same fate. Relying on semi-competent auditors to wade through volumes of compensating controls and point-in-time reviews to deliver ✓’s in the right boxes is not a recipe for a solid security program that will help mitigate and respond effectively to emerging threats.
  • Banks were supposed to have been sophisticated enough to control their risks :: I’ll focus on medium-to-large enterprises for this comparison, but I’m fairly confident that this is a prevalent attitude regarding information security in corporations across the globe (“We manage information risk well“). Budgets seem to be focused on three fundamental areas that non-security-folk can conceptually grasp: firewalls (stop), traditional anti-virus (block) and endpoint disk encryption (scramble). By now, with a decade of OWASP failures [PDF, pg 28], a multi-year debate about anti-virus efficacy and ample proof that vendors suck at building secure software as evidence, you’d think we’d be focusing on identifying the areas of greatest risk and designing & following roadmaps to mitigate them.

    This may be more of a failure on our part to effectively communicate the issues in a way that decision makers can understand. While not as bad as the outright lying committed by those who helped bake the financial meltdown cake, it is important to call out since I believe senior management and company boards would Do The Right Thing™ if we effectively communicated what that Right Thing is.

  • Regulators need to keep up with innovation and excessive leverage from innovation. :: The spirit of this is warning that financial regulators need to keep a sharp eye out for the tricky ways institutions come up with to get around regulations (that’s my concise summary of “innovation”). Think “residential mortgage-backed securities”. The “excessive leverage” bit is consumers borrowing way too much money for over-priced houses.

    I’m not going to try to make a raw parallel, but just focus on the first part: Regulators need to keep up with innovation. The bad guys are getting more sophisticated and clever all the time and keep up with hot trends faster than we can defend against them…due in part to our wasted time testing controls and responding to low-grade audit findings. When even the SOX compliant security giants can fall hard, you know there’s a fundamental problem in how we are managing information security risk. Regulators & legislators need to stop ( http:// articles. latimes. com /2011/feb/11/business/la-fi-0211-privacy-20110211 ) jerking knees and partner with the best and the brightest in our field to develop new approaches for prescribing and validating security programs.

  • ERM is not an EASY button from Staples :: I’m *so* using that quote in an infosec context this week
  • Many banks and insurers should be failing the use test for ERM regulation to be effective. :: More firms need to fail SOX and PCI and [insert devastating regulation acronym here] checks or SOX & PCI requirements need to change so that we see more failing. Pick one SOX and PCI compliant company at random and I’ll bet they have at least one exploitable Internet-based exposure or that custom-crafted malware can get through. If we start making real, effective, and sane regulations, we’ll start contributing to the betterment information security in organizations.
  • Stress testing is becoming a major tool for regulators. :: What if regulators did actual stress testing of our security controls versus relying on point-in-time checks? I know that the stress tests for banks end up being a paper exercise, but even those exercises have managed to find problems. Come in, pick three modern exploit vectors and walk-through how company defenses would hold up.
  • Regulators need to be able to pay competitive market salaries :: we need smarter rule-makers and examiners. There are good people doing good work in this space, just not enough of them.
  • Difficult for risk managers to operate under multiple constraints of multiple regulators, accounting systems. :: Just domestically, 42 states with separate privacy regulations, SOX for public companies, PCI compliance for those who process credit cards and independent infosec auditing standards across any third-party one needs to do business with make it almost impossible to stop spinning around low-level findings and focus on protecting critical information assets. We need to get to a small number of solid standards that we can effectively understand and design solutions to meet.
  • Nice tree/forest story: Small trees take resources from the forest. Large trees shade smaller trees making it harder for them to get sunlight. Old trees die and fall crashing through the forest taking out smaller trees. :: This made me think of the rampant consolidation of the security tech industry. Savvy, nimble & competent boutique vendors are being swallowed by giants. The smart people leave when they can and the solutions are diluted and become part of a leftover stew of offerings that don’t quite fit together well and are not nearly as effective as they once were.
  • Things that people say will never go wrong will go wrong. :: “We’ll never have a SQL injection. Our mobile devices will never get malware on them. Those users will never figure out out to do [that thing], why should we spend time and resources building it correctly?”
  • Compliance should be the easy part of ERM, not the whole thing :: So. True.
  • Asking dumb questions should be seen as good for firm. 10th dumb question might reveal something that no one else saw. :: This needs to be a requirement at everyone’s next architecture meeting or project initiation meeting. At the very least, do something similar before you let someone open up a firewall port.
  • There is a lack of imagination of adverse events. US has cultural optimism. Culture is risk seeking. :: Can be easily seen in our headstrong rush into consumerizing IT. I find that architects, engineers and application developers tend to see 1-2 “security moves” out. We need to do a better job training them to play Go or Chess in the enterprise.
  • People understand and prefer principles based regulation. But when trust is gone everything moves towards rules. :: If firms had been Doing The Right Thing™ in information security when they had the chance, we wouldn’t be in the state we are in now. I can’t see us getting [back] to principled-based regulation any time soon.
  • Supervisors need to learn to say no :: How many firewall port opens, disk-encryption exclusions, anti-virus disables and other policy exceptions have you processed just this past week? How many defenses have you had to give up during an architecture battle? Non-infosec leaders absolutely need to start learning how to say “no” when their best-and-brightest want to do the wrong thing.
  • Caveat Emptor :: Don’t believe your infosec vendors
  • A risk metric that makes you more effective makes you special. :: We have risk metrics? Seriously, tho, if we can measure and report risk effectively, our infosec programs will get better.

I may have missed some or got some wrong. I’d be interested in any similarities or differences other saw in the list or if you think that I’m overly cynical about the state of affairs in infosec risk.

I’m putting together a computer & online safety presentation for an upcoming talk at a senior center in Portsmouth (NH) and came across Support Details in my information hunting trek. This site makes it dirt simple to get basic information from whomever you are providing remote support to (a task I’m sure many of us have to do on occasion). I suspect it could also be handy to a developer who wants to double-check client settings. If you’ve ever tried asking someone what their IP address is or even what browser they are using, you know how helpful it might be if you could find out simple information quickly and painlessly.

Support Details collects data on the following system/browser elements:

  • Operating System
  • Screen Resolution
  • Web Browser
  • Browser Size
  • IP Address
  • Color Depth
  • Javascript
  • Flash Version
  • Cookies
  • User Agent

Support Details | Tech Support Management

Both Windows and OS X provide internal utilities to do full screen sharing – and more – for remote assistance if you’re on that same platform. There are third party services such as GoToAssist and Copilot that enable remote support across platforms. While Support Details does not even come close to either types of interaction it does provide basic data to help you triage where to go next…and, it’s free.