Still I insist about the story told by Facebook because I see that nobody wants …
The problem is that in the absence of a clear standard on how to break the news of a security problem, there are two major thrusts to dis-inform the public.
– Vanity Announce: the researcher to the complaint renowned research a “flaw” in the most catastrophic possible, in the most striking possible, when it comes to a problem that is NOT about the program that had the flaw, but a bad practice implemented by users.
– Reputation Management: a series of strategies implemented by companies impacted by a flaw in order to let underestimate, undervalue, saving the reputation of the company.
On the first, the example of PGP is more than enough. A German PhD student decides to become famous revealing to the masses that “PGP is insecure.” It respects neither the time nor the announcement mode that normally allow those who fixed the bug to be in the lead against anyone who exploits him, leaving several weeks to phishing experts to exploit the flaw.
After a few hours the announcement will clearly find that PGP has no problem, and if anything, it all depends on a series of very bad practices implemented in e-mail clients that use PGP. In return, the researcher has had his 15 minutes of fame.
The Reputation Management practices instead are much more insidious. These experts intervene when the company has a quality full-blown problem of the product to the end user, and are to save the customer’s face. They are based on building a storytelling which aims to:
– Reduce the perception of the damage, possibly preventing that such damage is associated with other events. (For example, a few hours before the announcement there had been a facebookdown rather heard) If these outages are allowed, are not associated with the attack, but the measures taken to combat it. In short, all the smoke is due to the fire that we hanged by putting out the fire.
– To attribute the damage to a known bug, just solved better if, instead of attributing it to something to analyze, difficult to resolve, especially not completely set. Then you take an old bug that was already being resolved in the DevOps process, and it blames, just as you are deployando the patch. And so: the problem was, but it has already been resolved.
– Restricting scope of the problem: it is said that that credential was stolen, but does not explain all possible uses. If this credential facebook is also used by third-party applications, for example, he has never been explained. If the hijacked accounts were protected or not, and then it is a violation of existing content public or content that the authors did not show.
This is what I have seen from Facebook in the last event of the hack. As you realize you have in front of a storytelling?
– The criminal stupidino. When you realize that, the criminal mastermind entered the vault, he prevented 345 alarms, has fallen asleep on guard cheetah, but then stealing the diamonds he got hungry and filled with snacks bag, leaving 90% the diamond in place.
This is the theory of those who say they have noticed a “spike in traffic on some servers”, that peak was due to the fact that reading “the page as another user”, it caused a lot of traffic. The criminal stupidino, in short, is not able to download the evidanto credentials to download all the content. The criminal stupidino, even if it needs to download the page to avoid creating suspicion of outliers does not seem capable of doing tarpitting of its own program, and after obtaining the credentials slowly download pages (that you do not need)
– The unlikely alarm. Facebook gives an anomaly detection alarm its ability to detect the attack. Apparently, since they used the “see as a different user,” then consumed more bandwidth than expected.
Sure. In practice, discharging 90 million users in 8 days, downloaded 10 million pages in the preview day. We are talking about a social network that has two billion users. And these 10 million pages in preview, to make matters worse, in terms of content are mostly downloaded from the CDN. This alarm is unlikely he would have noticed a tremendous increase in traffic related to the content of non ~ CDN 10 million users per day, equal to the beauty of ~ 115 profiles per second. … ..sseriously?
– The unexplained coincidences. While the brilliant thief entered the vault, explosions were heard in the surrounding buildings and the police switchboard went afuoco.Ma no one asks if things are related.
Just in the time when there was the attack, he suffered a facebook facebook down for several hours.
In that way 115 profiles previev per second can impensierire facebook to the point of causing the down, it is unclear. How do these two events are not connected. Why would the change of credentials (that Facebook claims to have done) must lead to a down, either.
The two things have happened, but no one dares to ask whether there were relationships.
– Abstract target. When it’s not clear what the hell he wanted the striker. The superladro penetrates into the vault, but it is unclear if it aims to diamonds or distributor of snacks staff.
Why we were affected 90 million accounts on 2000000000. They were chosen at random? And even if (as seems to say Facebook) The purpose of this attack were the profiles, profiles WHAT? We’re talking about profiles that are already public? In that case just a crawler. We’re talking about profiles who chose to NOT be visible and have been opened? Ok.
So they were carefully chosen. On what criteria? It was Putin’s political opponents? They were Chinese? Italian? Germans? Gay? Activists? Who were they? Boh. No analysis of the victims was made.
– The likely remedy. The criminal is entranto into the vault using a weakness, just happened and we knew we would have fixed tomorrow.
Interesting. So the bug has been known for years, and no one before him had used. Just happened, they did it when the solution had been written, the patch had finished his DevOps process and we put it down, it happens immediately. Of course, in a few seconds we also did the analysis of the impacts of this patch, and also did all of the non-regression tests than previous existing bugs.
Aha. I believe it. Really.
– Failure crisis impact on third parties. Our brilliant thief stole all the diamonds in the collection, but no one dares to say that insurance and police chief are in a difficult situation.
So these have downloaded credentials, but no one is analyzing which and how many third-party services we did use. Apart from the fact that facebook can offer different authentication systems, many third-party systems were using facebook authentication, and those credentials stolen?
No analysis of this type is being proposed. And this is serious, for another reason:
– The fix of action entrusted to reviewers. The thief breaks into the vault and steal all the credit cards. For current account holders is given the task to check if their credit card is among those rubate.Se someone does not read the newspapers, we so sorry for her bank account.
Okay, okay. Facebook has invalidated the credentials of these utenti.Ma what was the duration of credentials at third-party services? How long the suppliers of API basasi on the credentials of others held in October cached credentials? Unknown. In practice, it is hoped that all remind users to have used a facebook token, to have had an account on facebook, they go to check, and reminding all Erze party sites where they used this token, and it is hoped that this token is not in the cache. In which case, the stolen credentials still work.
When these symptoms occur, typically you are dealing with a deluge of tall tales told by the experts of Reputation Management.
Ultimately, that is, the message is simple: do not trust Facebook, and do not use your Facebook account to register on third-party services.
This story shows, if proof were needed, that the security issues are NOT addressed to protect YOU; but to protect the shareholders. search Brands 
(RSS generated with FetchRss )
(Source: post on the Facebook page Kein Supporters Pfusch / Uriel Fanelli )