Archive for the 'Hacking' Category

Apr 05 2014

Hack my ride

Published by under Hacking,Risk,Security Advisories

Important:  Read the stuff at the end of this post.  I got a lot of feedback and I’ve added it there.  Unlike some people, I actually want to be told when I’m wrong and learn from the experience.

I don’t own a Tesla S and probably never will.  They’re beautiful cars, they’re (sort of) ecologically friendly, and they show that you have more money than common sense.  I use a car to get my family from point A to point B and showing off my wealth (or lack there of) has never actually been part of the equation in buying a car.  And one more reason I don’t think I’ll ever buy a Tesla is that I’m beginning to think they’re as insecure as all get out, at least from the network perspective.

Last week hacker* Nitesh Dhanjani wrote his experience with exploring the remote control possibilities of the Tesla Model S P85+.  It starts with being able to unlock the doors, check the location, etc.  And it ends with a total lack of security for the site and tools needed to control the car.  The web site for controling your new Tesla has minimal password complexity controls, six characters with at least one letter and one number.  I have no idea if it’ll even let you use symbols, but I’m guessing that’s either not supported or only a minimal subset of symbols are available.  Which means password complexity is very low by almost any standard.  Then there’s the fact that Tesla doesn’t have rudimentary controls around the web site, such as rate limits on password guesses or account lock out, which they’ve hopefully changed by now.  Which gives you an easily guessed password combined with a site that allows unlimited guesses, making the possibility of brute forcing the password very real.  That’s not even including the fact that so many people reuse account names and passwords, so there’s a good chance you can find a compromised account database with the owner’s details if you search for a little while.

That’s great so far.  Now let’s add to this the fact that your Tesla S has wifi/4G wireless access.  And there’s also a 4-pin connector in the dashboard that leads to the network inside your car.  It’s running all sorts of wonderful things in that network too, none of which could possibly be vulnerable to outside attacks, right?  SSH? Check.  DNS? Check.  Web Server? Check. Telnet?  Check.  Wait, telnet?  Seriously?  Oh, and “1050/tcp open java or OTGfileshare”.  Yes, I really want either java or an open file share running in my car.  At least one person was able to get Firefox running on the console of their Tesla, [Correction: x-11 forwarding misconfiguration, not running on the Tesla]  even if was flipped on its head for some odd reason.  Any or all of these services running on the car’s internal network could have vulnerabilities that allow configuration change, remote code execution or even full root access to the system.  Or maybe they just allow for the systems to be rebooted, not something you really want when your driving on the winding coastal roads of California. [I've been told it's just the displays that would be affected, none of the handling characteristics would change. Still disconcerting]

So now we’ve got two fairly egregious methods of connecting to your Tesla with minimal security standards.  The first is remote and allows for control of doors, sunroofs, braking and suspension profiles.  The last two should concern everyone.  While there are probably physical controls in place to keep the profiles of brakes and suspension from getting too far outside of the range of acceptable usage, I wouldn’t be willing to bet on it, given the otherwise lax security measures on the remote controls for the car.  The second method of connecting to the Tesla does require physical access, but it sounds like this is built for the engineers and technicians who work on Teslas [Correction:  The connection only allows for access to the entertainment system and there is an airgap between that and the CANBUS systems.  However, I don't trust airgaps], and is likely to allow much greater control of the car and the various parameters of its design.  Even less technologically advanced cars have the ability to make fairly advanced modification of the functioning of a car once you have access to the software, so Tesla probably has extremely advanced configuration capabilities.  Meaning everything from how the car charges when plugged in to what shows up on the dash as you’re driving to manipulating acceleration and braking are within the realm of possibility.

As the Internet of Things becomes our daily reality, this sort of lax security on something as potentially deadly as an automobile is inexcusable.   It wouldn’t take much of a tweak to the normal operation of a car to make it uncontrollable in the wrong situation.  We haven’t seen anyone killed by having their car hacked yet, but it’s only a matter of time if companies aren’t willing to take the time to properly secure the systems that go into making the car run.  While it’s important in the current marketing environment to make every device as configurable from you phone as possible, there have to be sufficient controls in place to make that configurability safe and secure as well.  Yes, it might mean that you, Tesla, have to make your users go through two or three more steps in order to set up their systems for control, but it’s worth the effort.  After all, who will be liable, who will be in the courts for years when the first person claims that their car was hacked, which is what caused the accident?  Even if having a car hacked isn’t the cause of an accident, it can’t be too long before someone uses that as their defense and still costs the company millions in legal defense.

Let’s end this with a little thought experiment.  The four pin connector in the Tesla has a full TCP stack and runs on a known set of IP’s, 192.168.90.100-102.  Say I grabbed a Teensy 3.1, with built in wi-fi capabilities, and added an ethernet shield.  With the current arduino libraries, I can create a wi-fi receiver that takes my traffic and routes it to the wired network, which just happens to have an accessible network inside the Tesla.  Now I have a device that’s a small portal directly into your car that I can connect to from several hundred feet away, farther if I want to make myself a high gain pringles can yagi antenna.  We’re not talking high technology spy gear, we’re talking about a weekend project I could do with my kids that would result in a package no bigger than a pack of cards.  I could put this in the glove box with a single cable leading to the car’s ethernet port.  Anything a Tesla engineer could control on the car, I could control remotely.  Suddenly I have the biggest remote control car on the block, which just happens to be the Tesla you’re sitting in.

This is why we have to secure the Internet of things.  If I can imagine it, you better believe there’s already someone else out there working on it.

* Hacker == someone who makes technology do things the engineers who designed it didn’t intend it to do.

Added, 9:15 GMT:  So I got some feedback very quickly after posting this.  And I admit a lot of what I’m saying here is based on guesswork, assumptions and third party statements.  It’s my blog, I get to do that.  Both Beau and the Kos have a lot more to say about why many of my assumptions are wrong.  And they probably know more about cars than I do.  So teach me.  There will be follow up.

Thanks to @chriseng for basic spell checking.  I do indeed know the difference between ‘break’ and ‘brake’, just not before breakfast.

@beauwoods: “Infotainment network and CANBUS are separate. The other issue is the equivalent threat model of a big rock to a window.” In other words, there’s a very real airgap between the two systems and it’d be impossible to control one from the other.

@theKos called my statement about the password limitations silly, stated that running Firefox on the system was a x-forward misconfiguration, that rebooting the displays won’t affect the running of the car, and that all products have vulnerabilities.  I really have to challenge the last statement as a fallacy: knowing that all products have vulnerabilities doesn’t make them more acceptable in any way.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

3 responses so far

Mar 18 2014

NSP Microcast – RSAC2014 – Utimaco

I spent a few minutes with the CEO of Utimaco, Malte Pollman at RSAC this year.  Malte explains why Hardware Security Modules are important to the web of trust of the Internet, why lawful interception is a not in conflict with that web of trust.  As with all my interviews at RSAC, I asked Malte how the last year’s worth of spying revelations have affected his company and him personally.  Also, I have a problem pronouncing the company name, which for the record is you-tee-make-oh.

NSPMicrocast-RSAC2014-Utimaco

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Mar 15 2014

NSP Microcast – BSidesSF with Trey Ford

I caught Trey Ford right after his talk at the BSides Conference in San Francisco last month to talk about the efforts he’s making on behalf of Rapid7 and the security community.  It may be a sign that we’re a maturing industry when we’ve got folks like Trey traveling to Washington, DC in order to talk to lawmakers about how what they’re doing affects our lives.  And, as with all my interviews this year, I ask Trey how revelations about our government has affected his personal as well as professional life.  Check out his site at Password123.org.

NSPMicrocast – BSidesSF – Trey Ford

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Mar 09 2014

Mt. Gox Doxed

I’ve never owned a bitcoin, I’ve never mined a bitcoin, in fact I’ve never really talked to anyone who’s used them extensively.  I have kept half an eye on the larger bitcoin stories though, and the recent disclosures that bitcoin exchange Mt. Gox was victim of hackers who stole the entire of the content in their vault, worth hundreds of millions of dollars (or pounds) have kept my interest.  I know I’m not the only one who’s smelled something more than a little off about the whole story and I’m sure I’m not the only one.  Apparently a hacker, or hackers, who also felt something wasn’t right on the mountain decided to do something about it: they doxed* Mt. Gox and it’s CEO, Mark Karpeles.

We don’t know yet if the files that hackers exposed to the internet were actually legitimate files from Mt. Gox and Mr. Karpeles yet, but this isn’t the only disclosure the company is potentially facing.  Another hacker has claimed to have about 20Gigs of information about the company, their users and plenty of interesting documents.  Between the two, if even a little of the data is valid, it’ll spell out a lot of trouble for Mt. Gox and it’s users.  If I were a prosecutor who had any remote possiblity of being involved in this case, I’d be collecting every piece of information and disclosed file I could, with big plans for using them in court at a later date.  

In any case, I occasionally read articles that say the Mt. Gox experience shows that bitcoins are an unusable and ultimately doomed form of currency because they’re a digital only medium and that they’ll always be open to fraud and theft because of it.  I laugh at those people.  Have they looked at our modern banking system and realized that 99% of the money in the world now only exists in digital format somewhere, sometimes with hard copy, but generally not?  Yes, we’ve had more time to figure out how to secure the banking systems, but they’re still mostly digital.  And eventually someone will do the same to a bank as was done to Mt. Gox.

*Doxed:  to have your personal information discovered or stolen and published on the Internet.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

3 responses so far

Mar 05 2014

DDoS becoming a bigger pain in the …

Published by under Cloud,General,Hacking,Risk

I’m in the middle of writing the DDoS section of the 2013 State of the Internet Report, which is something that makes me spend a lot of time thinking about how DDoS is affecting the Internet (Wouldn’t be all that valuable if I didn’t put some thought into it, now would it?).  Plus I just got back from RSA where I intereviewed DOSarrest’s Jag Bains and talked to our competitors at the show. Akamai finally closed the deal on Prolexic about three weeks ago, so my new co-workers are starting to get more involved and being more available.  All of which means that there’s a ton of DDoS information available at my fingertips right now and the story it tells doesn’t look good.  From what I’m seeing, things are only going to get worse as 2014 progresses.

This Reuters story captures the majority of my concerns with DDoS.  As a tool, it’s becoming cheaper and easier to use almost daily.  The recent NTP reflection attacks show that the sheer volume of traffic is becoming a major issue.  And even if volumetric attacks weren’t growing, the attack surface for application layer attacks grows daily, since more applications come on line every day and there’s no evidence anywhere I’ve ever looked that developers are becoming at securing them (yes, a small subset of developers are, but they’re the exception).  Meetup.com is only the latest victim of a DDoS extortion scam, and while they didn’t pay, I’m sure there are plenty of other companies who’ve paid simply to make the problem go away without a fuss.  After all, $300 is almost nothing compared to the cost of a sustained DDoS on your infrastructure, not to mention the reputational cost when you’re offline.

I’d hate to say anything like “2014 is the Year of DDoS!”  I’ll leave that sort of hyperbole to the marketing departments, whether it’s mine or someone else’s.  But we’ve seen a definite trend that the number of attacks are growing year over year at an alarming rate.  And it’s not only the number of attacks that are growing, it’s the size of the volumetric attacks and the complexity of the application layer attacks.  Sure, the majority of them are still relatively small and simple, but the outliers are getting better and better at attacking, Those of us building out infrastructure to defend against these attacks are also getting better, but the majority of companies still have little or no defense against such attacks and they’re not the sort of defenses you can put in quickly or easily without a lot of help.

I need to get back to other writing, but I am concerned about this trend.  My data agrees with most of my competitors; DDoS is going to continue to be a growing problem.  Yes, that’s good for business, but as a security professional, I don’t like to see trends like this.  I think the biggest reason this will continue to grow is that it’s an incredibly difficult crime to track back to the source; law enforcement generally doesn’t have the time or skills needed to find the attackers and no business I know of has the authority or inclination to do the same.  Which means the attackers can continue to DDoS with impunity.  At least the one’s who’re smart enough to not attack directly from their own home network, that is.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 04 2013

Attacking the weakest link

Published by under Cloud,Government,Hacking,Privacy,Risk

I spend far too much time reading about governmental spying on citizens, both US and abroad.  It’s a job hazard, since it impacts my role at work, but it’s also what I would be researching and reading about even if it wasn’t.  The natural paranoia that makes me a good security professional also feeds the desire to know as much as possible about the people who really are spying on us.  You could almost say it’s a healthy paranoia, since even things I never would have guessed have come to pass.  

But every time I hear about someone who’s come up with a ‘solution’ that protects businesses and consumers from spying, I have to take it with a grain of salt.  A really big grain of salt.  The latest scheme is by Swisscom, a telecommunications company in Switzerland that wants to build a datacenter in that country to offer up cloud services in an environment that would be safe from the US and other countries’ spying.  The theory is that Swiss law offers many more protections than other countries in the EU and the rest of the world and that these legal protections would be enough to stop the data at rest (ie. while stored on a hard drive in the cloud) from being captured by spies.  The only problem is that even the Swisscom representatives admit that it’s only the data at rest that would be protected, not the data in transit.  In other words, the data would be safe while sitting still, but when it enters or leaves Swiss space, it would be open to interception.  

It was recently revealed that the NSA doesn’t need to get to the data at rest, since they simply tap into the major fiber optic cables and capture the information as it traverses the Internet.  Their counterparts here in the UK do the same thing and the two organizations are constantly sharing information in order to ‘protect us from terrorists’.  Both spy organizations have been very careful to state that they don’t get information from cloud providers without court orders, but they haven’t addressed the issue of data in motion. 

So while the idea of a Swiss datacenter built to protect your data is a bit appealing, the reality is that it wouldn’t do much to help anyone keep their data safe, unless you’re willing to move to Switzerland.  And even then, this solution wouldn’t help much; this is the Internet and you never know exactly where your data is going to route through to get to your target.  If it left Swiss ‘airspace’ for even one hop, that might be enough for spy agencies to grab it.  And history has proven that at least GCHQ is willing to compromise the data centers of their allies if it’ll help them get the data they believe they need.  

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Oct 24 2013

LinkedIn Outro

“I know!  Let’s build a man in the middle (MITM) attack into our iPhone app so that we can inject small bits of information into their email that show how useful our site and service are.  At the same time we’ll now have access to every piece of email our users send, and even if we only have the metadata, well, that’s good enough for the NSA and other national spying agencies, isn’t it?  Let’s do it!”

I have to imagine the thinking was nothing like that when LinkedIn decided to create Intro, but that’s basically what the decided to do anyway.  If you read the LinkedIn blog post, you can see that they knew that what they were doing is a MITM attack against your email, even if they are calling it a proxy.  They’ve broken the trusted, or semi-trusted, link between you and your IMAP provider in order to get access to your email so they could insert a piece of HTML code into each and every email you receive.  Additionally, they’ve figured out how to make it so that this code is executable directly in you’re email.

Basically, what LinkedIn is asking you to do is create a new profile that makes them the proxy for all your email.  This is similar to what you do for your corporate email when setting it up on a new phone, but rather than having something that’s finely tuned for that corporation, LinkedIn makes the new profile on the fly by probing your phone’s configuration and basing it on the settings it finds.  

I have a hard time believing that someone at LinkedIn didn’t wave a red flag when this was brought up.  You’re asking users to install a new profile making you their new trusted source for all email, you’re asking that they trust you with their configuration and you’re capturing, or at least having access to the stream of all authentication data for their email.  Didn’t anyone at LinkedIn see a problem with that?  I have to imagine there are plenty of corporate email administrators who’ll have a problem with it.

Given recent history and the revelations that metadata about a person’s communications, LinkedIn is  audacious to say the least.  They know what they have, or at least want to have: information similar to what Google and Facebook have about your daily contacts and habits.  This is a huge data mining operation for them, aimed at learning everything they can about their users and applying that to advertising.  But I think they have overreached in their their desire to have this information and are going to get shut down hard by Apple.  And this doesn’t even take into account the fact that they’ve already had data breaches and are being sued for reaching into consumers’ calendars and contact information.

I don’t think LinkedIn has been a good steward of the information they’ve had before, and there’s no way I’d install Intro onto one of my iDevices if I was a heavy user.  The fact is, I have an account that I mostly keep open out of habit and this is nearly enough to make me shut it down for good.  If I wanted my every move tracked, I’d just keep open a Facebook tab in my browser. And while they may not be much of an example when it comes to privacy, I guess Facebook is a great example when it comes to profitability.  Way to go LI.

 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Oct 13 2013

Time to change DNS methods

I’m going to ignore the whole question of whether or not social engineering is ‘hacking’ for now.  The difference between the two is mostly academic, since the effect of having your site hacked due to a weakness in the code and having all your traffic redirected to a site that the bad guys own is immaterial.  Either way, your company is effectively serving up something other than the page you intended, which is what really matters.

There have been a number of high profile sites that have recently been attacked through their DNS registrar.  Registrars are the companies who are responsible for keeping track of who owns which domains and providing the base DNS information for where to find the systems associated with a domain.  In theory, they’re supposed to be some of the most heavily defended type of enterprise on the Internet.  But the practice is different from theory, and even registrars have their weaknesses.  In the case of Register.com, this appears to be social engineering attacks.

The latest victims of social engineering attacks were Rapid7 and the Metasploit project, as were AVG Antivirus, Avira and WhatsApp.  What’s almost funny about the latest attack is that the attackers had to send a fax in as part of the change request to make the changes.  To think that a technology that had it’s heyday in the 80’s would be the method used to attack companies in the second decade of the 21st century is amusing.  Hopefully Register.com has already begun reviewing their processes to prevent a similar event from happening again in the future.  And, again hopefully, other registrars are learning from the mistakes of Register.com and reevaluating their own processes.

There is something companies can do to lessen the chance of a similar attack happening to them, called a registrar lock. This isn’t a step a lot of companies have taken yet, since it slows down the change process by requiring the administrator to first unlock the domain before making any changes, a step that has varying complexity depending on the registrar.  Also, not all registrars support locking, so this isn’t always an available option.  If your registrar doesn’t support registrar locking, it’s time to push for it or consider a new registrar.  That last part usually gets their attention.

I do understand the pressure the registrars are under; on one hand they have to secure their clients’ DNS records, but on the other they have to be flexible for clients who have a hard time understanding the basics of DNS.  It’s not an enviable position to be in.  Which is why registrars have to work harder to prepare for social engineering attacks than most other businesses out there.  But understanding the pressure doesn’t mean I cut them any slack for failing in their duty.

Update: Add two more to the compromised list, Bitdefender and ESET.  And again Register.com is the common point of weakness.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Oct 07 2013

Explain it to me

Published by under General,Hacking,Humor

I’ve never hidden the fact that I’m a bit of a rebel.  Okay, to be honest, I’m proud of being a stubborn contrarian who’s going to do what he thinks necessary, despite what it might cost in the future.  Part of the reason is that I’ve always been smarter than average and I feel that I see and understand things in ways many others don’t or can’t.  And as long as I’m being honest, I also enjoy the chaos this engenders and the ability to thumb my nose at convention and authority.  I like upsetting people’s preconceived notions and making them think about things they might normally shy away from contemplating.  I want improvement over the present and I despise the status quo.  And I don’t think I’m at all unique amongst security professionals; we’re almost all rebels to one degree or another.

I believe people who love security as a career are similar to me in large part.  We’re people who see a problem that needs to be solved, puzzles that need to be unlocked and mysteries begging to be revealed.  Constant learning is something that is the hallmark of a good security professional.  If you look at the most successful hackers, they got to the top because they can’t pick up a piece of electrical equipment or software without trying to see how it works.  We want to understand, to unlock and hopefully to gain just a little more knowledge about how the world around us works.  And yes, I include ‘hackers’ in the continuum of security professionals, as a subgroup who tends to embrace the chaos more than the more corporate professional.

Let me give you an example.  Over the summer at a small conference in Las Vegas, a select group of us met at a restaurant for dinner, a not uncommon occurrence for that time of year.  What was a little unusual was that when we sat down, the waitress handed the group a set of iPads with the drink and food menus on them.  Apparently we were meant to place our orders through these devices and the waitress would magically bring them out several minutes later.  But you should have seen eyes light up around the table as everyone started considering how to break out of the menu app and make the system do things the restaurant had never meant for their app to do.  It was like Christmas in July!  Needless to say, it was only a few minutes before we had to hand one of the iPads back to the waitress with an explanation of “Umm, we think this one is broken, it shows another restaurant’s menu.”  They’d figured out how the tool worked, unlocked the puzzle and had some fun, all in one fell swoop.  This curiosity is the core of who we are.

This need to understand is one of the things that makes many security professionals hard to work with.  We don’t take orders well, or at least I don’t.  We want to understand the underlying logic of a decision; we want to understand the thought process that went into making the decision and why it’s the best decision.  “Because it’s always been done this way” is the bane of our existence; when was the last time anyone examined why of that way?  Does doing it that way still make sense?  Is there a better way of doing it?  Does doing this actually accomplish our goal, or is it just busy work?  Managers don’t want to explain, they just want to get the task done, despite the fact that the task might not be leading towards the actual goal, but away from it instead.  And sometimes that’s the right thing to do.

We, as security professionals and hackers of the reality around us, have to be aware of this need to understand and unlock within ourselves and take steps to counteract it when appropriate.  Personally, it’s hard for me to accept “this is just the way it needs to be done”, but sometimes that’s the correct path.  Those moments are relatively rare; I prefer to have the people giving me direction to explain what it is they hope to accomplish and let me figure out how to do it best.  In the main, we have the time to discuss, to understand and to come to an optimal solution for the problem, and often if we take the time to do so, we realize the problem we were really trying to solve is not the problem we thought we were trying to solve.

It’s always important to understand your own motivations in decision making.  It’s also important to understand the motivations of the people around you in that same process.  I don’t claim that every security professional is driven by chaos and curiosity, but most of the ones I gravitate towards are.  We see chaos as a method to drive improvement.  But being aware of that motivation and how it influences the decisions we make will help us not only make the right decisions, it will help make those decisions in a way that is less stressful for us and those around us.

So let your coworkers know that you’re not challenging them, you’re challenging the decision making process and seeking to understand why a decision was made.  You want to understand what the goal was and how the decision leads to that goal.  But also understand that sometimes the analysis of a decision is not a luxury that can be afforded at a particular point in time.  There are times where we just have to take orders and shut up.  It seems to go against the grain of who we are, but it’s an unfortunate necessity in some cases.

I’m lucky in that I’m at a point in my career, in my life and in my role that I’m not only accepted as someone who’s supposed to question the decision making processes, it’s expected of me.  You can’t be a ‘thought leader’ if you never question authority, never question the status quo, never  question the reasoning that brought us to this point.  But I also have to be cognizant of the fact that what is generally one of my strengths can also be one of my greatest weaknesses if I’m not careful.  Giving into the desire to understand when things just need to get done leads to frustration for everyone involved, and harmful to the mission when done at the wrong time.

I may be grossly generalizing my own rebellion onto the entire security and hacker community.  I know a lot of people are going to say, “I’m not at all like that”, and they may be right.  Each of us have our own unique set of motivators that push us into the decisions we make.  But this is a set of motivators I see as a commonality in the community I live in.  Understanding your own motivations is one of the best ways to combat the frustration we often feel when dealing with people who don’t see the world as a puzzle like we do.  And knowing they don’t see it the same way might help us communicate in ways that settle some of their frustrations as well.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

5 responses so far

Jun 19 2013

Microsoft Bounty Program: Katie Moussouris at FIRST

When Katie Moussouris is so excited about something she’s almost vibrating, you know it has to be big.  So when she came Chris John Riley and I earlier this week and said she had news from Microsoft, we had to make time to talk to her.  Katie’s been working on the Microsoft Bug Bounty program for over three years and it’s no wonder; getting a company like Microsoft to recognize the importance of working with the researcher community as early in the process as possible, and getting the funding to make it happen is no small feat.

The basics of the three programs are like this:  Researchers who develop novel, new exploitation techniques (not just bugs, but new techniques) can receive $100,000 for the technique.  If they also come up with a mitigation technique for the exploitation, they can receive another $50,000.  The third program is specific to IE 11 which gives researchers the opportunity to earn $11,000 per bug for the first month of the beta for IE 11.

It’ll be interesting to see how other companies respond to Microsoft’s move.  Rather than simply wait for the vulnerability pimps resellers to bring up exploitation techniques and vulnerabilities to Microsoft once the product has been released, this encourages them to do the same during the development lifecycle, and at a healthy rate.  Will other vendors be able to do the same, will they cast aspersions on Microsoft’s efforts, or will they simply pretend it never happened?  Only time will tell.

FIRST 2013 – Katie Moussouris of Microsoft on the Bug Bounty Program

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

« Prev - Next »