Showing posts with label research. Show all posts
Showing posts with label research. Show all posts

Tuesday, August 20, 2019

Harnessing Stunt Hacking for Enterprise Defense

Make Sure You Understand the Root Cause of the Vulnerabilities or Attack Vectors Behind the Next Over-Hyped Stunt Hack

Every year, at least one mediocre security vulnerability surprisingly snatches global media attention, causing CISOs and security researchers to scratch their heads and sigh “who cares?”

Following a trail of overly-hyped and publicized security bugs in smart ovens, household fridges, digital teddy bears, and even multi-function toilet-bidets, the last few weeks have seen digital SLR camera vulnerabilities join to the buzz list. Yet, this latest hack boils down to a set of simple WiFi enabled file-sharing flaws in a mid-priced camera that allowed researchers to demonstrate specially crafted ransomware attacks. It is not an obvious or imminent threat to most enterprise networks.

Love it or loathe it, stunt hacking and over-hyped bugs are part of modern information security landscape. While the vast majority of such bugs represent little threat to business in reality, they stir up legitimate questions. Does marketing security hacks to a fever-pitch cause more harm than good? Are stunts a distraction or amplifier for advancing enterprise security?


There is little doubt within the security researcher community that a well-staged vulnerability disclosure can quickly advance stalled conversations with reluctant vendors. Staged demonstrations and a flare for showmanship had the healthcare industry hopping as security flaws embedded in surgically implanted insulin pumps and heart defibrillators became overnight dinner-table discussions and murder plots in TV dramas. A couple years later, prime time news stories of researchers taking control of a reporter’s car – remotely steering the vehicle and disabling breaking – opened eyes worldwide to the threats underlying autonomous vehicles, helping to create new pillars of valued cyber security research.

Novel technologies and new devices draw security researchers like moths to a flame – and that tends to benefit the community as a whole. But it is often difficult for those charged with defending the enterprise to turn awareness into meaningful actions. A CFO who’s been sitting on a proposal for managed vulnerability scanning because the ROI arguments were a little flimsy may suddenly approve it on reading news of how the latest step-tracking watch inadvertently reveals the locations of secret military bases around the world.

In a world of over-hyped bugs, stunt hacking, and branded vulnerability disclosures, my advice to CISOs is to make security lemonade by finding practical next steps to take:

  1. Look beyond the device and learn from the root cause of the security failing. Hidden under most of the past medical device hacks were fundamental security flaws involving outdated plain-text network protocols and passwords, unsigned patching and code execution, replay attacks and, perhaps most worrying, poorly thought through mechanisms to fix or patch devices in the field. The outdated and unauthenticated Picture Transfer Protocol (PTP) was the root cause of the SLR camera hack.
  2. Use threat models to assess your enterprise resilience to recently disclosed vulnerabilities. The security research community waxes and wanes on attack vectors from recent bug disclosures, so it often pays to follow which areas of research are most in vogue. The root cause vulnerabilities of the most recent hacks serve as breadcrumbs for other researchers hunting for similar vulnerabilities in related products. For this reason, build threat models for all form factors the root flaw can affect.
  3. Learn, but don’t obsess, over vulnerable device categories and practice appropriate responses. At the end of the day, a WiFi-enabled digital SLR camera is another unauthenticated removable data storage unit that can potentially attach to the corporate network. As such, the response should be similar to any other roaming exfiltration device. Apply the controls for preventing a visitor or employee roaming a datacenter with a USB key in hand to digital SLR cameras.

Regardless of how you feel about the showmanship of stunt hacking, take the time to understand and learn from their root causes. While it is highly unlikely that an attacker will attempt to infiltrate your organization with a digital SLR camera (there are far easier and more subtle hacking techniques that will achieve the same goal), it is still important to invest in appropriate policies and system controls to defend vulnerable vectors.

With more people seeking futures as security researchers, it would be reasonable to assume that more bugs (in a broader range of devices and formats) will be disclosed. What may originally present as a novel flaw in, let us say, a robotic lawnmower, may become the seed vector for uncovering and launching new 0-day exploits against smart power strips in the enterprise datacenter at a later date.

Chuckle or cringe, but make sure you understand the root cause of the vulnerabilities or attack vectors behind the next over-hyped stunt hack and don’t have similar weaknesses in your enterprise.

-- Gunter Ollmann

First Published: SecurityWeek - August 20, 2019

Thursday, April 16, 2015

Is Upping the Minimum Wage Good for the Information Security Industry?

The movement for upping the minimum wage in the US is gathering momentum. Protests and placard waving are on the increase, and the quest for $15 per hour is well underway. There are plenty of arguments as to why such a hike in minimum wage is necessary, and what the consequences could be to those businesses dependent upon the cheapest hourly labor. But, for the information security industry, upping the minimum wage will likely yield only good news.

It's hard not to be cynical, but we're already hearing how simple automation will be used to replace most basic unskilled jobs.

For technologists, hiking up the minimum wage will almost certainly be fantastic news. Why stop at $15 per hour... perhaps $25 would yield a more dramatic societal change?

In some ways its hard to fathom how significant this minimum wage movement could be in driving the next generation of technology and information security, but I'm pretty sure we're on the cusp of a new generation of technological automation and innovation.

The combination of a dramatic increase in mandatory minimum wages, the steady cost-reduction of embedded systems, and the recent advancements in robotic control logic are working together to lower the threshold with which the next generation of robotic systems become economically viable.

If you thought those self-serve payment kiosks as your local supermarket or fast-food joint were an indicator of things to come, you were right. The coming generation of self-serve and automated construction or delivery systems have been in many innovators minds for a long time - but had been shelved for economic reasons. This year - assuming minimum wages advance to $15 per hour or greater - we'll see a fundamental societal change.

The stakes have changed - and it will unlikely bode well for those occupations that the minimum wage could likely have helped.

Those store clerk, hostess, or "order taker" jobs will largely cease to exist. With a few key presses I'll be able to type my own order for a medium Big Mac combo meal with no mayo... all by myself... and get my name spelled correctly too. In many ways I'd sooner have a mechanical marvel flipping burgers and frying my fries, with a little conveyor bringing me my meal (TM) ... than the current solution of having 5 different dissatisfied "minimum wage" people assemble my meal with all the gusto and enthusiasm of a beard-net.

With the threshold for economic viability likely to fall so sharply, it doesn't take a soothsayer to predict a tsunami of automated solutions capable of not only replacing costly unskilled-labor jobs, but also increasing quality and consistency of the products delivered. Perhaps those photos of plump and enticing burgers above every fast-food counter you've ever seen will finally be representative of what your robotic (quality controlled) chef produces? Or maybe that'll remain a fantasy.

Regardless, whats good for technologists and the impending minimum-wage revolution is undoubtedly doubly good for the information security industry.

New products, new technology, new software, new flaws, and new pressures to secure them, will require a new generation of testing methodologies, automated vulnerability scanner tools, and a growing body of specialist consultancy skills.

While not yet a scholar of history (more precisely a student of history), I can see parallels with the 19th Century Luddite movement against newly developed labor-economizing technologies. Most people associate the Luddites with the mindless smashing of technology they didn't understand, but in reality it was about unemployment and retaining a way of life. This time round I think we can expect folks will know and understand the technology they and their friends will be replaced with... and that means that electronic attacks and hacking will usurp sledgehammers in the pending automated revolution.

There are certainly pros and cons to the societal change we stand at the cusp of.

As an information security professional, things a quite rosy. For those who's only skills lie in delivering platters of fast-food or processing an order from a menu, or any repetitive sales task, things are about to get pretty rough.

If there's a silver lining for everyone else, perhaps it lies in the pending demise of the US tipping culture? The arguments for tipping waitstaff making a "living wage" or the tablet on the table taking your food and drink order may quickly become mute.

-- Gunter

Monday, August 17, 2009

Dumpster Diving - XCrypt by Kazuya

For the last week or so I've been repeatedly asked "how do you find these crime-ware tools?" The answer is pretty simple really, I often just use a search engine and focus in on the hacking forums if I'm curious or after some low hanging fruit.

For example, lets take a look at a new(ish) crypter - XCrypt.

I stumbled across this particular crime-ware tool while perusing a popular Spanish hacking site - LatinoHack.com - which I originally came across when I was looking to see if there were any new (or related) updates to the DIY Octopus Keylogger tool.

Since my Spanish is pretty much non-existent, I need to rely upon one of those online Web translators for these kinds of sites - but then again, it seems that most of the "better" underground malware and hacking sites tend not to be in English anyway. These translators are good enough for my purposes though.

XCrypt caught my eye for a handful of reasons:
  1. It was a 1.0 cryptor (and I wasn't familiar with it)...
  2. It wa hosted on a Spanish site but had German instructions...
  3. It was high up on the first page of the forum.
If you're wondering what a cryptor does - well, generally, you point the tool at a malicious file (e.g. a piece of malware that you've already created - say the output from the DIY Octopus Keylogger), click start, and out pops an auto-unpacking self-encrypted version of the original malware that's (probably) going to bypass any anti-virus detection tools out there.

I was curious about XCrypt though, so I did a little more searching - this time using the keywords "xCrypt Public Kazuya" - and came across yet another hacking forum site - PortalHacker.net - which had a whole bundle of other Trojans and keyloggers for download (along with satisfied customer reviews).



PortalHacker had a bit of a discussion going on about XCrypt, including the latest anti-virus coverage (which was nothing currently detected it)...

... which isn't precisely unexpected. It's new(ish).

And, to help things along, the site (and review) also included a convenient option to download the tool from one of the free file-hosting providers out there (which is a popular way of distributing these kinds of crime-ware tools). The file was also password protected - to prevent any perimeter or host-based security products from intercepting the file and potentially flagging it as malware (the tool itself - not the output from the tool).

As for the specifics of this particular crime-ware creator tool - I'll leave that to a full-time threat analyst to do his/her stuff and provide the juicy biopsy of XCrypt - even though there were a bundle of postings on the forum congratulating the author of the tool for their skills and eliteness... as well as repeated AV evasion test results.

So, what was next? How about examining the German heritage of this particular tool?... which led to (yet another) hacking forum site - 1337-crew.to - with a thread covering the XCrypt tool, but this time the thread was started by someone called Kazuya (the author?).



And what do you know, pay dirt, there's an even newer version of the tool available...



... along with new AV test results (only one AV discovers its crypted crime-ware output), and 140 satisfied downloaders.

Most of these kinds of hacking and malware discussion forums have rating systems for contributors (and sellers), and it looks like the last stop in my search found a site that the author of this particular tool likes to hang out - 440 posts and a 5-star site reputation.

And so concludes a brief demonstration in how easy it is to uncover new crime-ware creator kits and tools, and how to get hold of samples to "play" with. This isn't really rocket science kind of stuff.

You may be asking yourself "isn't this all kind of illegal?" and "why aren't these kinds of sites shut down?". Well the answer to that is typically different laws apply in different countries. In most countries it is not illegal to create these kinds of tools, nor is it illegal to discuss their use. In some countries it may be illegal to buy/sell these tools, and in many countries it may be illegal to use them against computers you're not authorized to access - but the net result is that these kinds of information and crime-ware toolsets are out on the Internet for anyone to access (subject to Web filtering policies :-)

Thursday, March 26, 2009

Reigniting the Bugs for Cash Debate

It's like one of those magic candles people place on birthday cakes that sparkle and relight themselves each time you think they've been blown out. That's how I'd define the most recent ignition of the "bugs for cash" debate.

By now you'll have probably heard that Dino Dai Zovi, Charlie Miller and Alex Sotirov have declared "No more free bugs" (Dai Zovi affirms his position and provides insight to his side of the argument over on his blog titled "No more free bugs").

It's been picked up by several of the security media channels, and Robert Lemos over at Security Focus as a good summary "
No more bugs for free, researchers say" (although I'd debate this being anything like a "new chapter"). And then, this morning, I read Dave Goldsmith's blog posting Vulnerability Research: Times They Are A-Changin.

Perspective
Since I'm hardly a wall-flower and have been outspoken about the various aspects of the disclosure debate (particularly vulnerability purchase programs) for several years, I figured I'd better provide my perspective on this most recent disclosure storm.

While I respect the technical capabilities of
Dino Dai Zovi, Charlie Miller and Alex Sotirov in finding new vulnerabilities and weaponizing them in to exploits - I think there's a lot of show-boating going on, and it seems that the popular media is happy to go along for the ride.

Several people have pointed out that security researchers invest a lot of time in finding bugs and, since the "good" vulnerabilities are getting harder to find (i.e. taking more effort), they deserve to be paid for their work. I'd go along with that reasoning but for a simple fact, the software vendors haven't asked nor employed these particular researchers to find bugs in their products.

From a vendors perspective, their CEO and CFO have defined the companies operational budget and optimized their expenditure processes. Most have invested in to secure software development lifecycle programs and have included many security review and QA gates already. Most of the major vendors also employ professional (external) vulnerability research teams at the tail of the development lifecycle to "blackhat" their way to any bugs or vulnerabilities that may have been missed. Then, even having followed this process, the odd vulnerability still makes it through.

From the vendors perspective, vulnerabilities should have been caught within their existing processes. But, as someone with firsthand experience of this, each sub-process is operating within time and financial constraints. Take the third-party vulnerability researchers that consult for the vendor - they were probably contracted to provide 100 man-days of effort for $250k (plus expenses) - and may find anywhere between zero and a thousand vulnerabilities - WITHIN those time/financial limits. The vendor set those budget/time limits. If they were wrong, maybe some external (unaffiliated) security researcher will uncover a vulnerability that was missed. The vendor then needs to decide whether future investments in their security review processes are needed - and would be budgeted accordingly.

With a vendor-perspective-hat on, why should they be paying for more bugs? If it's a concern (i.e. affects customer confidence or damages the brand), they'll reprioritize their internal QA spending and increase budgets.

Vulnerability Worth
I've seen many security researchers debate the value of a vulnerability - and most are "dissatisfied" with the compensation paid by the commercial vulnerability purchase programs. As
Dave Goldsmith clearly states in his blog - "Defenders Buy Vulns, Attackers Buy Exploits" - and there's a big difference in uncovering a vulnerability and actually turning it in to an exploit.

Criminals (and Governments) pay a premium for weaponized vulnerabilities - so to compare the prices they're willing to pay for some new zero-day versus a security vendor who's focused on remediating the vulnerability is naive. And, as for these $5,000 (etc.) contests to be the first to break something - that has nothing to do with improving security, its a marketing exercise - and the researchers who participate in them are merely associating a small dollar value to their professional reputation.

Getting back to my point about a software vendors budget for assuring/improving security... What I've found is that many of the best security researchers are already contracting with, or working within, the major software vendors and helping to improve their products security. From a compensation perspective, those security researchers regularly earn anywhere between $150k to $250k per annum (plus benefits) - which is much more profitable than picking up $5k at a contest here and there.

Then there's the "Best of the best" security researchers out there. Not only are they smart enough to find the most important vulnerabilities and figure out how to exploit them, but they're also smart enough to set up there own businesses and really rake up the dollars (and get others to do the tedious research work!).

So, whats a bug worth in that context? That 100 man-day contract may yield 100 bugs - placing each bugs value at $2,500. On the other hand they may only find one bug - and that single bug is now worth $250k. Take your pick.

In my opinion "No more bugs for free", while headline grabbing, is old ground trodden over many times in the past. Routes already exist for legitimate/ethical security researchers to make a mint from the vulnerabilities they are capable of finding - if they're smart enough to understand the business.

Vulnerability showboating is for amateurs from a past age. The vulnerability research business has moved on.

Monday, March 2, 2009

Searching for a Phishing Spot

Phishing is one of those threats that have been around since the dark ages of the Internet and has never really gone away. It's constantly on everyone's lips, and most people know someone who's fallen victim to the scam somewhere along the line. I think that, as a threat, Phishing is on the decline (from the perspective of uncontrollable escalation like some other threats) but will likely never go away as long as we continue with Internet 1.0.

From the criminal phishing perspective, a critical component to the scam is the hosting of the counterfeit Web site. While I'd say that most security professionals have a good feel for the percentage and frequency of Web sites that are compromised and end up hosting the phishing content, I'd never really encountered any public analysis of the compromise vector and what the percentages were beyond a finger in the air.

Today I came across a very interesting paper Evil Searching: Compromise and Recompromise of Internet Hosts for Phishing, by security researchers Tyler Moore and Richard Clayton, which actually quantifies whats been going on.

Of particular interest to me was their analysis of the use of search engines by the criminals to find the vulnerable Web servers, and how repeated compromise of these vulnerable Web servers (for the purpose of Phishing) can be analyzed.

It's a very interesting paper, and I'd recommend those of you looking to protect your sites from Phishers take the time out to read through it.

Personally, I think the best defense against the Search vector is what we've been saying for decades (and has appeared in every single pentest report I can ever remember writing) - watch out for information leakage, and change/obfuscate all service banners! Yes, I know that that's not going to work in all cases, but it's a damn good place to start!

You should probably also check out the paper I wrote several years back related to Passive Information Gathering.

Monday, January 26, 2009

Attack Coordination Using Social Networking Sites

With little doubt, the fastest growing and most influential Web 2.0 technology has been that of the Social Networking site. Sure, the concepts have been around for quite some time - harking back to the first dial-up BBS' of the 1980's - but the growth of sites like Facebook and MySpace is unheralded. The amount of time people now spend "Social Networking" has even overtaken the quest for porn (see the BBC's "Porn putting on its Sunday best").

Now, if you combine the facilities of social networking sites to coordinate large groups of people incensed by another group with tools that enable members to "donate some of their computers bandwidth", you can quickly develop massive "opt-in" DDoS systems.

The first component - the groups of incensed and motivated members - are already out there. Just look at the Facebook groups that sprung up backing either Israel or Hamas in the most recent conflict, or older groups such as the animal cruelty activists like "Stop Huntingdon Life Sciences Animal Cruelty".

The future of Social Network initiated/coordinated DDoS attacks is just around the corner (if it hasn't already happened in less-than-newsworthy cases already). Welcome to the birth of SDoS - Social network Denial of Service.

I posted a longer blog on the topic, along with the tools available to activist and social conscience groups - and some future threat motivations up on the IBM Frequency-X Web site.

Take a gander at "Social Network Denial of Service (SDoS)?" for more thoughts and analysis.

Friday, January 23, 2009

Firefox Update Dynamics

Last year, along with Stefan Frei, Thomas Duebendorfer and Martin May, we published the well-received paper "Understanding the Web Browser Threat" - which looked at how the various update mechanisms of the most popular Web browsers compared, and derived the minimum estimates of how many Web browsers constantly failed to apply the latest security patches - based upon analysis of Google USER-AGENT data.

Well, as a follow up to that research, a new paper has just been published in the January edition of ACM SIGCOMM Computer Communication Review. The paper, titled "Firefox (In)Security Update Dynamics Exposed", takes a much deeper look at how Firefox is updated (for real) by Internet users.

There are many very interesting findings to be found in the paper, but I wanted to share some of the things I found most interesting from the research.

Weekend Usage
When you take a closer look at the frequency at which a particular Web browser version is used during the week, you can see a noticeable pattern that revolves around weekend usage patterns.

For example:

Here we see the usage pattern of Internet Explorer versions 6 and 7 over a year. Clearly, IE7 grows in popularity over IE6 and, by early 2008 becomes the most popular IE version in regular use.

But, looking closely at the fluctuations you'll notice something very interesting - IE7 grows in popularity over the weekends.

What this most likely means is that the newer version of IE is probably in greater use by home users. Meanwhile corporates, with greater restrictions on patch/update rollouts have stuck with IE6 for longer periods. Therefore you see IE6 getting greater use during the working week, and IE7 over the weekends.

Oddly enough, the same pattern can be seen with the latest versions of Firefox.

So, once again, we see the most recent version of a Web browser getting more use over the weekend.

The new paper also explores the effect on Safari and Opera Web browsers too.

Applying Updates
Another interesting aspect to the research is the dynamics behind the pace at which updates to the respective Web browsers are applied. By examining the minor version information contained within the USER-AGENT data, the authors were able to observe how quickly(?) users applied public patches.
For example, the graphs above show this pace of patch application and the percentage of Firefox/Opera browser users using the most current (and secure) versions.

Rest of the Paper
There is of course a lot more information contained within the paper and I'd whole heartedly recommend that any security professionals out there take some time out of the day to read it.

I think it raises the interesting angle on the dynamics of weekday vs weekend drive-by-download attacks. Going purely off the numbers, I'd be inclined to say that users are "safer" conducting their Internet browsing when they're away from work. So, if you have need of checking out your online bank balances throughout the day - wait until the weekend?

Unfortunately the BIG unknown are the plug-in's - which I suspect are a bigger problem for home users... which probably more than negates the previous paragraph.