secalex

This is a great example of security nihilism. "This tool can't protect against every possible attack from every possible adversary, therefore it is useless."

Building safe, secure products at scale for real populations is a process of balancing multiple equities and addressing the most pressing and realistic threat scenarios. This always means building security protections that have theoretical failure modes. The real art is in trying to make those failures as graceful as possible while educating your huge, diverse set of users on the security properties of the product and in what situations they can rely upon it.

Doing this well is still something the entire industry needs to work on, but giving it a shot and building practical protections for real people is always a better option than throwing up your hands and giving up.

Different key, dude. We rotated what was exposed.

Thank you to everybody who cautioned against judgment before hearing the whole story. Here is my response: https://www.facebook.com/notes/alex-stamos/bug-bounty-ethics...

Probably because this post was getting lots of links for a domain that is otherwise rarely seen on FB? You can read about the challenges of spam-fighting at scale (and people actually getting paid to write Haskell) here: http://www.wired.com/2015/09/facebooks-new-anti-spam-system-...

This was a mistake due to this specific blog post sharing some design elements as some spammy blogspot posts and it was fixed. If we really wanted to censor this story wouldn't we block all criticism of Facebook and not a pretty straightforward and well-reasoned analysis of Safe Harbor? Wouldn't we block the "I declare that I am a wizard and Facebook can't use my content blah blah" memes?

I filed a bug. I don't know why the spam filters picked this up but it was not intentional. EDIT: Fixed

Me too.

To be clear I'm not claiming that firewalls are irrelevant in the enterprise campus scenario, especially if they have DPI functions that are effective in discovering outbound control channels. Even huge corporate environments rarely have more than 10Gb/s of transit and those Palo Alto devices I talked about work fine in that scenario.

What I am saying is that hardware firewalls are not an option at scale and that Layer 3/4 protections are being pushed into the host for scale-out operators. Note that "into the host" does not necessarily mean "in the operating system". There has been great work by some operators to push these controls into the Ethernet firmware, although I'm unaware of a standards-based open way of doing such.

I'm enjoying this HN discussion, where people are disagreeing with a response to a misquote of a incorrect summary made by somebody who didn't watch the talk. :)

So you clean your clothes in the stream out back using a washboard and lye you made from white ash?

"The dream of the 1890's is alive in Portland..."

> I haven't heard many alternatives (in general).

These problems don't call for a general solution. We should respect the fundamental truth behind the end-to-end principle and solve these problems as close to the application as possible. The likely threats, appropriate default choices and trust model are all best understood by each application developer and building these solutions into Layer-3/4 is bound to cause short-term pain and reduce our long-term flexibility to meet new risks.

For example, EFF's STARTTLS Everywhere project takes into account the fact that a huge percentage of the world's mail moves between a small enough number of providers that human verification of announcements is possible. It also recognizes that the MX configuration for these providers is reasonably static, meaning that changes that propagate in minutes do not need to be accommodated. Small specific solutions like this can be rolled out and provide a real, tangible benefit to users much faster than we can upgrade the entire DNS system to provide a more general solution.

I agree that we need a DNS privacy solution, one that hopefully doesn't eliminate the existence of caching infrastructure.

A bunch of us who were "open" applicants for new TLDs (my company applied for .secure) tried our best to fight this in ICANN. The "closed generic" was not something properly anticipated by ICANN when they created the nTLD process (it's an insult to Byzantium to call the rules byzantine) and several large companies, Google and Amazon most brazenly, shoved themselves through some loopholes and created a category that was never supposed to exist.

The unfortunate fact is that the ICANN board is pretty spineless, and had no desire to restate the rules to prevent the private domination of generic terms (for example, Amazon wants to control the Chinese word for book, which is pretty aggressive for a company from Seattle when the Chinese invented moveable type). The board was so completely dedicated to moving forward that they endorsed the idea of the winner takes all auction and punted all of their responsibility for choosing which applicants would actually provide the most value to the world. Open small applicants have to win the auction using funds drawn from a business model of selling domains. These closed generic applicants can throw tens of millions of dollars at the auctions based upon the value of having a monopoly on a term like .app, .search or .secure.

In the end a bunch of us made pretty speeches and got a bit of traction with the EU government representatives in the ICANN GAC (but not the US, critically) but in the end we were steamrolled by the dozens of lobbyists and lawyers these companies send to every ICANN meeting.

Too late for outrage now. The whole process made me highly cynical towards the future of the name system as overseen by ICANN. At least I'm done getting food poisoning in exotic locations three times a year at ICANN meetings.

Free filing is going to increase fraud since $10 means the attackers need enough credit card numbers to not set off Intuit's or the payment networks' fraud systems. That probably means almost a 1:1 ratio between returns and working CCs, with Intuit having the obvious option of checking zip codes against the returns.

I once had an interesting discussion with a tech-savvy criminal attorney about whether security researchers could trade public equities using early indicators of compromise or private knowledge of 0-day (gained from outside the company, not under NDA). She thought about it a bit and said "The insider trading laws are so broad that if the US Attorney didn't like it they would make it illegal, and if you had talked to anybody about it they would go down for conspiracy."

My interactions with the criminal legal system as an expert witness since then have only reinforced my belief in Harry Silverglate's axiom that pretty much every US adult is merely an un-indicted Federal felon living their lives at the mercy of the thousands of AUSAs who could plunge them into a living hell.

The well-meaning but naive people behind this and other ad-disrupting extensions are doing more than anybody to end the era of general purpose computing. These products (several of which are created by for-profit companies that then extort the ad networks) are slowly killing the desktop web as a viable distribution channel for professionally created content. This is pushing publishers to put more and more of their focus on the mobile space, where their content is trapped in a mobile app that can gather way more data and show unblockable ads.

We'll look back at the 2000's and 2010's as the golden age of the web, when it was economical to publish content for free without relying upon the DRMish guarantees of the major mobile OSes. In five years the desktop web available to general-purpose browsers will be dominated by pay services (Netflix), micro-payment supported sites, NPR-like fund drives (Wikipedia, Internet Archive), academics who don't need to raise revenue, and sites with super-low cost structures due to their reliance on user-generated content (Reddit).

Yes, the systems with the log parsing bug are part of an internal subnet. As with most web scale companies HTTPS requests are terminated on a unified edge and load-balanced to web service hosts in internal clusters. In this case the malicious header was maintained in the backend requests and ended up in the application log, which triggered the command injection. Everything I wrote above is correct and is in no way incompatible with the fact that the affected machines have RFC1918 addresses.

I appreciate you reporting expired certs, which unfortunately happen from time to time. That canned reply for is not appropriate and not a reflection of how we approach TLS and I will get it changed.

We have several participants in our program who are making a pretty decent living, especially the ones for whom a US$5000 reward is comparable to their nation's per-capita GDP. We are hoping to highlight some of these people in a future talk.

I personally think that the opening created for those without the educational or economic opportunities available to developed world researchers is the best side effects of bug bounties.

Twice means once for the initial bug on Wednesday, the second time with one of the "nuke the attack surface from orbit, it's the only way to be sure" patches that became available that Thursday.

This is no guarantee, of course, which is why the pen-test team that Chris Rohlf runs has to stay abreast of and continuously test the latest available exploits as well as the attempts that we see in our logs.

Howdy, Hacker News. I’m the CISO of Yahoo and I wanted to clear up some misconceptions.

Earlier today, we reported that we isolated a handful of servers that were detected to have been impacted by a security flaw. After investigating the situation fully, it turns out that the servers were in fact not affected by Shellshock.

Three of our Sports API servers had malicious code executed on them this weekend by attackers looking for vulnerable Shellshock servers. These attackers had mutated their exploit, likely with the goal of bypassing IDS/IDP or WAF filters. This mutation happened to exactly fit a command injection bug in a monitoring script our Sports team was using at that moment to parse and debug their web logs.

Regardless of the cause our course of action remained the same: to isolate the servers at risk and protect our users' data. The affected API servers are used to provide live game streaming data to our Sports front-end and do not store user data. At this time we have found no evidence that the attackers compromised any other machines or that any user data was affected. This flaw was specific to a small number of machines and has been fixed, and we have added this pattern to our CI/CD code scanners to catch future issues.

As you can imagine this episode caused some confusion in our team, since the servers in question had been successfully patched (twice!!) immediately after the Bash issue became public. Once we ensured that the impacted servers were isolated from the network, we conducted a comprehensive trace of the attack code through our entire stack which revealed the root cause: not Shellshock. Let this be a lesson to defenders and attackers alike: just because exploit code works doesn’t mean it triggered the bug you expected!

I also want to address another issue: Yahoo takes external security reports seriously and we strive to respond immediately to credible tips. We monitor our Bug Bounty (bugbounty.yahoo.com) and security aliases (security@yahoo.com) 24x7, and our records show no attempt by this researcher to contact us using those means. Within an hour of our CEO being emailed directly we had isolated these systems and begun our investigation. We run one of the most successful Bug Bounty programs in the world and I hope everybody here will participate and help us keep our users safe.

We’re always looking for people who want to keep nearly a billion users safe at scale. paranoids-hiring@yahoo-inc.com

Although I'm an AGL fanboy (I have his rookie card) I have to agree with Matthew here. Pushing the transition this fast, just when the world is on the verge of accepting HTTPS as the default, is reckless and will overall reduce the safety of the Internet.

FYI, we are deploying in the same manner as Cloudflare, with RSA/SHA1 and ECDSA/SHA256 side-by-side. We are committing our changes to the public ATS repository and hopefully those changes are useful to other projects. Unfortunately this is dependent on OpenSSL 1.0.2, so we might have to deploy beta code into production if the OpenSSL project can't beat Chrome's arbitrary deadline.

I gotta back Matt here. While none of the three of us would endorse the iMessage key exchange model, the truth is that the team that implemented iMessage crypto have kept more communications safe from dragnet surveillance than everybody commenting on this HN article combined.

I personally think there is a good middle ground where identity management is invisible to most users and customizable by users with more challenging threat models. That is what we are aiming for.

I did not miss that, nor did I make any comparisons to car dealers. In fact, I've been to seven ICANN meetings and have participated in the debate on the proper role of law enforcement and civil seizure in policing the namespace.

Microsoft presented evidence to the court that No-IP domains were being used to facilitate real crimes against real people, and the court acted. I think there is an interesting debate to be had on venue and the level of malicious activity that needs to happen before a domain is seized, but instead all I see is standard HN smashing of the keyboard and "Microsoft Bad!"

The Microsoft hate here is unfounded and ill informed.

Those of us working defense at large organizations have known for a while that No-IP domains are wretched hives of scum and villainy. Any company with a threat model that includes at least one of a diverse set of characters ranging from malware authors to organized crime to nation state teams should be logging all DNS requests and treating any request to a No-IP domain as an indicator of compromise.

Microsoft has a successful history of disrupting botnet C&C and distribution channels via domain seizures, which is why this request probably sailed through Federal Court. The only difference in this situation is that there are innocent bystanders affected, which generally doesn't happen since the other domains they have seized have been 100% used for fraud.

I feel bad for those folks and the people at No-IP who maybe meant well, but the truth is that the fight to keep normal people safe is bigger than just technological, and needs to include civil legal actions like this.

Android botnets are very valuable because they use mobile network IPs that confuse fraud and login classifiers that use ASN or GeoIP.

Thank you for your data. I'm hoping to do a talk this fall with detailed stats after we have a whole year on this platform, but to a first order approximation your ratios do not look far off from our experience.

Hey, HN, CISO of Yahoo here, typing on a phone at a kid's birthday, so excuse the formatting.

We run a very progressive bug bounty program that allows bugs like this to be posted publicly. Every once in a while we might miss something out of the thousands of invalid reports we receive every month, and we made a mistake in the triage of this bug. The bug is fixed and we won't make the same mistake again. We definitely consider info disclosure to be a class of issue that needs to be addressed and to infer otherwise from one mistake is incorrect.

There are a handful of companies experimenting with this kind of open bounty model, and if we want it to survive (I certainly do) then we are going to all have to be willing to iterate to fix the problem, and move on.

Almost certainly this means they are supporting ARMv8: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf

From the deck: -32bit RISC Instructions -64bit GP registers -64bit operands -64bit pointers

Thank you for catching the spelling mistakes.

The point of that slide is that trade secret theft is a very old problem, and that there is a long history of criminal and civil case law to look to when punishing that kind of action. Those individuals were all charged under the Economic Espionage Act and face extreme penalties. I see this as another version of overcharging under the CFAA; the Federal Government has one standard for doing something on paper and a much harsher one for the same activities while using an SVN repo.

I am not defending the actions of those men, I just feel that the civil remedies that have been used for decades are more appropriate than having the soul-destroying power of the US DOJ turned against them on behalf of their employers.

The ethical dilemma exists for the technologist who performs the investigation and testifies against her former co-worker. What responsibility does she have to see justice done? I don't have an answer, but that was the question posed by the slides on justice.

Tom,

I missed you at Defcon for multiple reasons, not the least being the opportunity to get your feedback on the talk as delivered. Maybe we can run a pan-NCC internal conference this fall and see what everybody else is working on. Chicago is nice and central between SF and Manchester.

A big part of the talk was my theory that our industry can no longer claim neutrality; like medicine or law, our actions have become innately entwined with ethical dilemmas that I feel to be better dealt with explicitly and ahead of the moment of decision. I don't think you necessarily disagree, since you lay out two lines you are not willing to cross even if you do not specify your reasoning.

I expect somebody as seasoned and experienced as you can make these decisions subconsciously without violating your basic principles. Younger, less experienced individuals may find this to be a greater challenge and they were the real target of my talk.

In my eyes your actions definitely make you a white hat, even if you avoid the label.

I don't remember what I got the first couple of times I answered honestly. I do remember manipulating the system to become a Paladin, which perhaps negates the entire point of the morality system and makes me a rogue in real life.