jjarmoc

I don't know.. Google confirms they covered my area. I really don't look for house cleaning services, so maybe I just didn't get targeted for ads.

When I hear about companies like this going under, I always think how odd it is that I've never previously heard about them.

Then I realize, that may have been part of the problem.

He never 'got a lawsuit.' Instead, he got some comments from the contact to whom he reported it that criticized his approach. It's not even clear just who this person was. It seems he had trouble locating a contact to report security issues to, so this may as well have just been a low level support rep who was in over his head and saying things he shouldn't have.

"The hardest part - responsible disclosure. Support guy honestly answered there’s absolutely no way to get in touch with technical department and he’s sorry I feel this way. Emailing InformationSecurityServices@starbucks.com on March 23 was futile (and it only was answered on Apr 29). After trying really hard to find anyone who cares, I managed to get this bug fixed in like 10 days.

The unpleasant part is a guy from Starbucks calling me with nothing like “thanks” but mentioning “fraud” and “malicious actions” instead. Sweet!" http://sakurity.com/blog/2015/05/21/starbucks.html

So far as I know (this is sort of my profession), there's no federal "burglars tools" law regarding malware.

To be fair, many "burglars tools" laws require possession of the tools WITH INTENT to perform a criminal action. The intent piece is key. Merely possessing lock picks is usually fine. But sulking around masked in bushes outside an office building with a pickset, rope, and an empty duffel bag might get you in trouble.

A good list of Lockpick laws collected and indexed state-by-state at http://toool.us/laws.html. You see that in most jurisdictions intent is required.

While malware laws are still much less mature, I would hope that similarly there'd be an intent requirement. Possessing malware for purposes of reverse engineering to develop protections is obviously important, and clearly an activity we would want to remain lawful (and hopefully unlicensed/regulated).

Conspiracy is probably the easier route to a conviction.

I feel like that's a reasonable timeframe from 'hmm, something is odd' to 'we're pretty sure we fully understand the impact, time to notify users.'

There's a balance between early notification and misstating the impact.

In the comments, they indicate that they're in the process of sending out emails to users. Sending lots of emails takes some amount of time; hopefully those are arriving in inboxes now.

It's low key given the impacts as they understand them now, but seems reasonable unless there's more to it than it currently known. We'll see how things develop in the coming days - just being forthcoming days after it was detected and providing guidance on how to respond is commendable though.

No, I don't think you did. I certainly haven't seen anything about the root cause. Let's hope it comes in time.

This is one of the things that scares me. If an attacker had access to dump their credential digests, could they also have modified the site to silently log credentials upon entry?

From their statements so far, it doesn't seem that happened, but it seems likely that it could.

I just write down my passwords.

People may laugh, but for many people that's a huge step up. I've tried explaining password managers to family members, and I've failed. The usability just isn't there for many classes of user, and as noted elsewhere in this thread losing access to that database is catastrophic.

Getting them to use unique passwords per-site, even if those passwords are written down and stored in their desk drawer, can be an improvement.

I'm far less worried about someone breaking into my (grand)?parent's house and stealing their password diary then compromises their bank account than I am someone popping some random site and re-using the compromised password.

Now for enterprise credentials where the (physically) stored credential and the service to which it's applicable have a closer proximity there's a higher change of this kind of meatspace targeting. But then, the 'common local admin password across all domain-joined machines' problem persists too.

"Answer unclear, ask again later"

I would also appreciate more detail, but that shouldn't be their first priority.

They note that they discovered the breach on 'Friday' so I imagine they have an ongoing Incident Response right now. They may not have or be ready to share this information at this time, and that's fine. They might be working with law enforcement, further hardening systems, and continuing to confirm their findings to date to ensure they've mitigated the full impacts.

What's important now is conveying how users are impacted and what steps they should take to protect themselves; hopefully the rest comes in time.

Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.

Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords.

I'm certainly happy to accept a bit more inconvenience than most. I only do banking on one device, and one device only. I set up per-device passwords for things like Gmail (and MFA for my primary password), I authorize mobile apps via API keys, and try to avoid services that require I use my password on multiple devices in the first place.

For the most part, devices I use frequently can access things I use frequently without passwords. For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.

So the choice once more, for me, becomes cloud-based password manager or no password manager at all.

If those are you're options, you're probably right to go with the cloud option. For many people, even a physical notebook of single-service passwords would be an improvement.

(Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)

Not really. It's largely the magic of cloud synching that I don't like. A lot of people run standalone password managers like Keepass or 1Password and store the database in some sort of file synchronization service like Dropbox. I guess that's workable, but it's still not something I'm going to be doing.

I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.

While LastPass seems to be responding well, I find their entire service exceeds my tolerance for risk.

If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one.

Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which you have no control seems inherently risky. Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database. Use a password manager, please, but keep it offline and don't aggregate it with loads of other people's databases.

This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.

Thanks!

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

NCC Group

Atlanta. Austin. Chicago. New York. San Francisco. Seattle. Sunnyvale.

Application Security Consultant

Full-Time, work visa sponsorship available

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

Long-time Hacker News readers will be familiar with Matasano Security, and will expect to see us post in this thread. This month, there will not be a post from Matasano Security. Effective today, there will no longer be a Matasano Security. Instead, we're officially rebranding as NCC Group.

In late 2012, Matasano was acquired by NCC Group joining iSEC Partners and later Intrepidus Group. Since that time, we've been working together, cross staffing projects and benefiting from each other’s expertise. It's been a slow, steady process of increasing cohesion. We've reached the point where we need to assume a single identity, that of NCC Group.

Being a part of this process as it unfolds reminds me a bit of watching the Voltron cartoon series as a child in the '80s. The show featured pilots each commanding their own robot lions. Robot lions are fierce, powerful beings. But when they came together they'd form Voltron - a giant humanoid robot with the lions compromising each of it's parts. I like to think this is what's happening at NCC Group. What were previously separate companies each well accomplished in computer security are becoming a single even more formidable entity. "Form arms and body! And, I'll form the head!"

So, what does this have to do with hiring?

Growing a larger company requires a larger number of individuals. We still need candidates with the same skills as always; programming, reverse engineering, protocol analysis, web application building/breaking, adversarial thinking. We need people who understand technology and can identify flaws in how it's implemented. We need those who can look at a security weakness, and accurately gauge it's relative risk to the organization. And we need folks who can communicate that risk to multiple audiences, in varying levels of detail.

There's no better time than now to join us. Our integration effort has opened up opportunity within the company to focus on areas of specialization, advance skills, and take on ever more complex projects and challenges. If you've always wanted to be part of something new, but found yourself averse to the risk of early stage start ups, joining us now might be a way to do both. We're stable but we're evolving and changing, and our employees will shape what we become.

If you want to learn more about us check out our: Blog - https://www.nccgroup.trust/us/blog/ Cryptopals - http://cryptopals.com/ Microcorruption - http://microcorruption.com/

If you're ready to apply, contact us at: https://www.nccgroup.trust/us/careers/

Please, bear with us on the sites above. We've migrated a boatload of content, and it's likely there will be some website wrinkles. We'll iron them out as soon as we can (mostly we'll just keep breaking interesting software).

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

Any interview process that requires a substantial time investment by the candidate pre-interview is broken.

I disagree, but accept that this depends largely on the desired outcomes. If the candidates goal is to spray-and-pray by applying at dozens of companies and hoping one makes them an offer they can accept, I'll grant that requiring more time may be a hindrance. If, however, the candidate's goal is to learn something, improve their skills, and demonstrate to the potential employer that they're capable of doing this on a short time cycle, they may welcome the opportunity, and many have.

Why would I spend some time learning the security niche just for one interview? I could instead work on Android development, Python, Scala, or a whole bunch of other things. Those would be useful for many jobs, and not just 1-3 employers.

Because you want to work in security generally, and for us specifically? I fully accept that not everyone shares career goals which align with our needs, and encourage them to pursue other avenues. If you're dream in life is to be a broadway actor, we're unlikely to be able to help. That doesn't make this goal less important to you or valuable to the world at large, it just differs from what we do and offer.

That said, if you think that security skills (and web app security specifically, which is the typical path for those learning for the interview) are relevant only to "1-3 employers" I fear you drastically underestimate the size of the market both within security consultancies and enterprises that have a security team (or just appreciate security-minded developers).

Why is putting in a lot of time researching security for your interview a better use of my time than learning more widely applicable skills?

It may not be. There's a lot of paths to self improvement, and their suitability to a specific individual will vary, depending on that individuals goals, desires, and learning style. I don't think anyone is trying to prescribe 'the one true path to self improvement' but rather one that we've found to work, and one that we help our candidates advanced down.

What if I put in all the time, pass the pre-screening, and then when I meet you, it turns out you aren't the type of people I'd want to work with?

Then we shake hands and each go our own ways, hopefully having learned something about each other and ourselves in the process. Maybe we've made contacts that'll be mutually valuable in the future whether it be for future employment, a business relationship, or simply someone to chat with at some developer meetup, conference, etc. and bounce ideas off of. Choosing not to continue a relationship is a perfectly viable outcome of any interview process.

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

MATASANO SECURITY - Chicago. New York City. Sunnyvale.

Application Security Consultant

Full-Time, work visa sponsorship available

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

The security of computer systems has increasingly become an everyday concern. The news all too often brings word of yet another compromise, exposing financial information, personal details, or simply salacious pictures. Whatever the impact, it's clear the technology industry has a problem, and there are few easy solutions.

Some seek legislation to impose harsher penalties on the responsible parties. This ignores the fact that many of those responsible are outside the jurisdictions which seek to punish them. In some cases, they may have tacit approval of their own government, or even be operating on their government's behalf. Others turn to established security products looking for antivirus and network filtering technologies to add protection. This is an also an imperfect solution. It places the defender in a reactive posture, responding only to those threats which have been previously detected, and for which countermeasures have been developed. There's no perfect solutions.

At Matasano, we believe the best way to combat security weaknesses is at their source; by discovering and remediating software vulnerabilities before others leverage them for ill effect. Our clients see the value in this approach. We're engaged to work on some of the most interesting and important software on the planet. Aside from identifying vulnerabilities, we help our clients identify the root cause. Through this, they can adjust processes to reduce the likelihood of similar problems in the future, while increasing their ability to identify and correct them. The goal is more resilient software.

We've assessed hot startup web applications, low level device firmware, mobile platforms, and everything in between. With this breadth, we have need for employees skilled in frameworks like Node, Rails, Django, and Spring. We need people comfortable with x86 and ARM assembly, reverse engineering, and binary protocol analysis. If you're skilled in a programming language with the letter 'C' in it, that's desirable. Newer safer languages like Rust and Golang are in demand. In short if you share our focus on helping secure our software ecosystem one piece at a time and want a chance to do something about it, we should talk.

Learn about our hiring process at http://www.matasano.com/careers or contact us at careers@matasano.com Get a taste for some of what we do at http://www.microcorruption.com and http://www.cryptopals.com Check out our blog at http://chargen.matasano.com

Next month, you'll notice a change in these posts. Since being acquired by NCC Group in 2012, Matasano has been working increasingly closely with our peers at iSEC Partners and Intrepidus Group. The time has come to formalize this, by adopting a common name; next month I'll be posting under that name.

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

Yes, it likely will. That's probably why the article mentions a deprecation of "Non-Secure HTTP" rather than prescribing a specific TLS version. It's the sort of language that will stand the test of time as newer protocols become deprecated. The comments here, however, largely encourage "SSL" which is poor advice.

BEAST can be mitigated through ciphersuite selections and other measures. This makes it somewhat different than POODLE which is a protocol design flaw for which no reliable mitigation exists.

Suggesting folks not deploy SSLv3 is hardly a controversial statement. It's not just a difference in version number, it's a difference in protocol specification and name. When we say 'Use SSL' a well intentioned reader may follow that guidance and implement SSLv3, or worse disable support for TLS. Words mean things.

The differences are significant when it comes to the security of the underlying protocol, and the downgrade is why it's important you refuse to support SSL entirely. SSL of any version (v2 or v3.. the v1 you refer to was never publicly in use) comes with security problems that are resolved in TLS.

I won't bore you with the details, they're well explained at http://disablessl3.com/ among other places. All major browsers have ended support for SSL, and more secure alternatives have been available for years.

It's not a high risk; attacks require scenarios that may not be common, but it remains true that there's no reason to deploy SSL today.

Please, can we stop calling it SSL?

SSL means something very specific; something that people should no longer be deploying. The article notably uses the term 'Non-secure HTTP' which at this point in time means HTTPS leveraging TLS (probably at least 1.2) but leaves some room for future interpretation as newer versions or entirely different standards arise.

No one is advocating for 'SSL' here, and continuing to use the term 'SSL' or 'SSL/TLS' when we really mean 'TLS' further confuses the situation.

I can work either from home or from my office. My office is fine but I'm usually more productive in the comfort of my home because I'm less likely to be distracted.

This is definitely different for each individual. For me, I'm more likely to be distracted at home.

An other good thing is that I have more options if I want to take a break. I can pick up the guitar for 10 minutes, enjoy the sun outside, relax on the bed and so on... better than browsing the web where you don't even leave your desk.

See above, re: distractions.

I’m curious exactly how many times a candidate gets to apply to Matasano.

Undefined. Personally, I applied twice, ended up coming to work here the second time through.

Do I have to do the microcorruption.com and the cryptopals.com and The Web Application Hackers Handbook before even trying the technical screens and challenges?

Nope. But they might help, and you may want to anyhow; they're fun :)

He seems to see anything that doesn't include pitchforks and torches as apologetic.

There's no way to tell for sure if something like this is intentional or not.

Right, so the simplest explanation is that it's an unintentional bug. The absence of evidence that it was unintentional isn't evidence that it was intentional. If there were some magic string or default password or something, that'd be an obvious backdoor, but to me this looks like a pretty typical privesc bug, albeit in an undocumented api.

It was found through a chain of events that started with looking at the patch related to another privilege escalation vulnerability, one which no one seems to be claiming was a backdoor.

Also, waiting to fix it until a researcher makes it public may have been intentional.

I'm guessing it's more likely the the researcher waiting to go public until it was fixed.

This is evidenced both by the fact that it was patched alongside other vulns (ie. not a rushed out one-off patch) and from the article's disclosure timeline, which shows 'Full disclosure' occurring 04/09, while the 'Release of OS X 10.10.3' occurred 04/08. This is a pretty typical disclosure timeline; they couldn't begin to fix it until it was tracked as a bug, after all.

So, it's my comment you quoted questioning whether this can be called a backdoor.

I don't intend that to be apologetic for Apple. I called it a 'significant vulnerability' but at the end of the day, it's a privilege escalation like those that have come before and will likely continue to be found occasionally, regardless of OS. I don't see what's apologetic about acknowledging a significant vulnerable while questioning whether it should be called a backdoor.

If you want to talk about Apple's response - I find it concerning that they aren't backporting the fix.

While this is a significant vulnerability, I don't think the article is correct when it calls it a 'backdoor.' The term backdoor typically implies something that was intentionally left to allow illicit access, and while this is a significant bug, I don't see anything to indicate that's the case here.

... and where do the tools come from?

Tools are either made by expensive humans, or forged by the Dark Lord Sauron in the fires of Mount Doom.

There's also the matter of who will run those tools. It's not like fuzzers output exploit.sh or something.

Automation and tooling are great, but they aren't replacements for human ingenuity.

Right, just rung strings on the demo and you'll see the custom PNG chunk:

``` jawh<img onload=with(document.createElement('canvas'))p=width=4968,(c=getContext('2d')).drawImage(this,e='',0);while(p)e+=String.fromCharCode(c.getImageData(0,0,p,1).data[p-=4]);(t=top).eval(e) src=#> ```

I first learned about this technique from Cody Brocious' post (http://daeken.com/superpacking-js-demos) about his WebGL demo 'Magister' (http://demoseen.com/windowpane/magister.html). That file has a .html extension, but it's also a valid PNG. In his post, he discusses this technique as well as others.

Cody's goal was to compress already minified WebGL code and achieve some pretty impressive results from a ridiculously small file for a demo contest. He also put the JS loader (which is much smaller than the linked decoder) in a custom chunk on the PNG itself. By doing it that way, you can have a PNG that when renamed also contains a web page and/or more Javascript.

It's an interesting technique, for sure, but I've never been able to find a real use for it beyond the compression. With a content-type sniffing vulnerability or something, it could be an interesting way to deliver content to browsers, but otherwise it's really just a curiosity as best I can tell.

What if on April 1st they announced something that was so drastic that people thought it was an April 1st joke but it wasn't?

I've been surprised lately how few people seem to recall Google's launch of Gmail on 04/01/2004. There was a lot of back and forth debate about whether or not it was a joke. What they promised was pretty incredible for the day. Adding to this was the tone of the announcement...

http://googlepress.blogspot.com/2004/04/google-gets-message-...