La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: corrector le 09 avril 2014 à 15:14:03
-
BULLETIN D'ALERTE DU CERT-FR
1 - Risque(s)
contournement de la politique de sécurité
atteinte à la confidentialité des données
2 - Systèmes affecté(s)
OpenSSL 1.0.1, version 1.0.1f et antérieures
OpenSSL 1.0.2-beta1
3 - Résumé
Une vulnérabilité a été découverte dans OpenSSL. Elle permet à un attaquant de provoquer un contournement de la politique de sécurité et une atteinte à la confidentialité des données.
4 - Recommandations
Le CERT-FR recommande de mettre à jour les installations d'OpenSSL vulnérables. De plus, il est nécessaire de relancer les services susceptibles d'employer une ancienne version de la bibliothèque (notamment les serveurs Web et de messagerie électronique).
Après mise à jour d'OpenSSL, pour déterminer les services à redémarrer, il est possible d'employer sous Linux la commande ci-après : lsof | grep libssl | grep DEL
Néanmoins, cette commande ne permet pas de repérer les éventuels services compilés avec OpenSSL en statique.
Il est également recommandé, en cas de suspicion de compromission, de révoquer les certificats utilisés et de générer de nouvelles clés de chiffrement.
5 - Documentation
Bulletin de sécurité OpenSSL du 07 avril 2014
https://www.openssl.org/news/secadv_20140407.txt (https://www.openssl.org/news/secadv_20140407.txt)
Référence CVE CVE-2014-0160
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160)
Description de la vulnérabilité
http://heartbleed.com/ (http://heartbleed.com/)
Source : http://www.cert.ssi.gouv.fr/site/CERTFR-2014-ALE-003/index.html (http://www.cert.ssi.gouv.fr/site/CERTFR-2014-ALE-003/index.html)
-
aptitude versions openssl
Package openssl:
p 1.0.1e-3ubuntu1 saucy 500
i 1.0.1e-3ubuntu1.1 100
p 1.0.1e-3ubuntu1.2 saucy-security 500
je pense que je suis dans la vulnérabilité donc?
ps: mint16
-
je pense que je suis dans la vulnérabilité donc?
ps: mint16
Teste avec ce site, tu seras rapidement fixé si vulnérable ou non :
http://filippo.io/Heartbleed/#lafibre.info (http://filippo.io/Heartbleed/#lafibre.info)
-
du coté de mon "serveur" sous debian weezhy après un redémarrage d'apache2 c'est bon!
et pourtant:
Paquet openssl :
p 1.0.1e-2+deb7u4 stable 500
i 1.0.1e-2+deb7u6 stable 500
-
Bonjour à tous.
Le DSM 5.0 Update 1 de Synology semble poser problème (testé en utilisant le lien proposé quelques posts plus haut). En tous cas pour le DS710+ (Processeur x86).
Sinon ça semble OK pour les serveur Ubuntu 12.04 LTS maintenus à jour.
UPDATE : Merci, OPTIX, pour le lien :)
-
Faut pas oublier de recharger les programmes qui utilisent la libssl, après la mise à jour
Utiliser lsof et grep pour savoir lesquel (ou utiliser Debian :troll:)
-
debian recharge effectivement quasiment tous les services qui l'utilisent
par contre dans la liste il manquait quand même:
apache2 et ssh
-
paquet debian-goodies --> checkrestart
-
ah c'est bien ça!
bon par contre il faut faire le redémarrage manuellement (ou alors je n'ai pas trouvé)
-
Cette faille a fait pas mal de bruit sur les réseaux.
Un exemple d'exploitation sur un gros site :
Mark Loman @markloman (https://x.com/markloman/status/453502888447586304)
Do not login to Yahoo! The OpenSSL bug #heartbleed allows extraction of usernames and plain passwords! http://pic.twitter.com/OuF3FM10GP (http://pic.twitter.com/OuF3FM10GP)
(https://pbs.twimg.com/media/BksqeV-IEAAl4i2.png)
Le xkcd (http://xkcd.com/1353/) qui vient de paraître :
(http://imgs.xkcd.com/comics/heartbleed.png)
Il y a eu des articles dans beaucoup de journaux en ligne, et pas mal de sites importants affectés (notamment banques, webmails, boutiques)...
-
ah c'est bien ça!
bon par contre il faut faire le redémarrage manuellement (ou alors je n'ai pas trouvé)
ouaip mais au moins c'est généralement fiable.
-
celle vulnérabilité touche juste les serveurs ou aussi les particuliers ?
Firefox 29 beta 6 et windows 8.1 pro ?
-
Du coup, par mesure de sécurité, il ne faut plus utiliser https ?!? :D
Ca me rappelle un débat avec un collègue sur le déploiement de ssh sur des Cisco distants sur Internet. Pour lui c'était indispensable. Pour moi non vu que j'avais mis une politique Tacacs très restrictive empechant toute re-utilisation d'un login/mdp compromis. Quelques jours passent et Cisco sort une faille affectant le service ssh de ses équipements. Le genre de grosse faille où la désactivation du service était la seule solution possible. En fait, si on avait déployé, on aurait été compromis rapidement...
Aaah les joies de la sécurité informatique...
-
celle vulnérabilité touche juste les serveurs ou aussi les particuliers ?
Firefox 29 beta 6 et windows 8.1 pro ?
openssl est une librairie utilisée principalement dans le monde linux
tous les pc linux qui ont un service ou des clients peuvent se connecter (serveur web / ftp / ssh ....) sont susceptibles d'être touché.
par contre en tant que client pour toi le risque c'est qu'un serveur non sécurisé laisse passer tes donnés (login/mdp)
donc indirectement tu es touché
-
à ok. Vivien à corriger la faille sur son serveur ?
-
Oui,
http://filippo.io/Heartbleed/#lafibre.info (http://filippo.io/Heartbleed/#lafibre.info)
-
ok merci
-
MODERATION :
Ce topic concerne les bugs d'OpenSSL.
Le début de discussion concernant l'architecture du protocole TLS et du déploiement du HTTPS, et notamment la problématique du rôle des tiers de confiance dans TLS a été déplacé :
La sécurité de TLS se base sur une assertion qui est fausse. (https://lafibre.info/cryptographie/vulnerabilite-dans-openssl-12523/msg132111/#msg132111)
(Ce qui est un thème particulièrement intéressant sur lequel il y a beaucoup à dire.)
-
Je réalise que ce souci concerne aussi Tor.
(C'est moi qui met en exergue certaines parties.)
OpenSSL bug CVE-2014-0160
Posted April 7th, 2014 by arma in openssl security advisory
A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server.
If you're using an older OpenSSL version, you're safe.
Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.
Here are our first thoughts on what Tor components are affected:
Clients: The browser part of Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But the Tor client part is: Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor.
Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. (You will need to update your MyFamily torrc lines if you run multiple relays.)
Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, this shouldn't allow an attacker to identify the location of the hidden service, but an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.
Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.
Tails is still tracking Debian oldstable, so it should not be affected by this bug.
Orbot looks vulnerable; they have some new packages available for testing.
The webservers in the https://www.torproject.org/ (https://www.torproject.org/) rotation needed (and got) upgrades. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.
https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 (https://blog.torproject.org/blog/openssl-bug-cve-2014-0160)
Conclusion : Tor est vraiment très sérieusement concerné.
Qu'en pensez-vous? Est-ce que la NSA pouvait l'ignorer? Est-ce que la NSA pouvait cacher cela? Est-ce qu'elle l'a caché à ses alliés et ses agents?
Est-ce qu'en fin de compte la NSA ne serait pas aussi nulle que les dév d'OpenSSL?
-
à ok. Vivien à corriger la faille sur son serveur ?
Le test indiquait que le site n'était pas vulnérable, je ne sais pas si c'était une erreur du test, car j'étais bien sur une version impactée.
Je viens de pousser le correctif et de faire un reboot complet, cela faisait 2 mois que je n'avais pas fait de reboot.
Désolé pour la petite coupure.
-
Aie!
Donc potentiellement les données du serveur peuvent avoir été récupérées...
Y compris :
- les cookies d'identification
- les login/mdp
- la clé TLS du serveur
...
-
aaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!!!!!!
lafibre.info est resté down 2 minutes!!!!!!!
on va tous mourir!!!!!!!!!!!
oups je crois que j'en fais un peu trop
;D
non plus sérieusement même pas vus passer la coupure!
ps: pour mon site le test indiquait bien que j'avais le bug!
-
Le test indiquait que le site n'étais pas vulnérable, je ne sais pas si c'était une erreur du test, car j'étais bien sur une version impactée.
J'ai vu deux tests différents dire que le site n'était pas vulnérable.
Il me semble que la faille dépend d'une extension d'OpenSSL, Hearbeat, qui n'est pas activée chez tout le monde ?
Quelle était la version avant la mise à jour ? Elle venait de quel dépôt ?
-
La version n'a pas changée, elle a juste été patché :
$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
C'est Ubuntu Server 13.10. Dans le monde Debian, les correctif sont généralement rétro-porté afin de ne pas entraîner de régression.
Heartbleed : 17% des sites Web utilisant SSL vulnérables ?
Selon le spécialiste Netcraft, 500.000 sites Web sont impactés par cette faille critique dans la bibliothèque logicielle de chiffrement OpenSSL.
Danger sur le Web ? Ce mardi, nous évoquions ici la découverte d'Heartbleed, une vulnérabilité critique qui touche la bibliothèque logicielle de chiffrement OpenSSL (versions 1.0.1 et la bêta de la 1.0.2 d'OpenSSL).
De quoi impacter l'implèmentation des protocoles SSL et TLS, qui sont au coeur de la sécurité sur Internet. D'autant que Heartbleed a été publiée alors que beaucoup d'entreprises et d'éditeurs logiciels n'ont pas eu le temps de pousser une version corrigée d'OpenSSL sur les systèmes de leurs clients.
Correctif 1.0.1g sur les rails
La faille peut permettre de révéler le contenu d'un message sécurisé et chiffré - une transaction par carte de crédit en HTTPS, au hasard - ainsi que les clés SSL primaire et secondaire elles-mêmes. Ce qui pourrait servir en théorie à passer outre la sécurité d'un serveur sans laisser de trace.
Heartbleed serait le résultat d'une erreur de programmation dans les dernières versions d'OpenSSL. Ce qui est finalement plutôt rassurant, la faille n'étant pas implèmentée au coeur de la bibliothèque. Un correctif est d'ailleurs disponible dans une version 1.0.1g d'OpenSSL, et devrait apparaître pour la bêta de la 1.0.2.
Pour autant, de nombreux sites Web sont aujourd'hui vulnérables et susceptibles de voir des données sensibles être détournées. Selon le spécialiste Netcraft, 17,5% des sites qui utilisent le protocole SSL sont potentiellement en danger, soit 500.000 sites environ.
Il semblerait que Google, Facebook, Microsoft, Twitter, Amazon ou Dropbox ne sont pas concernés.
Cela dit, la question des correctifs devrait être assez polémique dans les prochaines heures. Plusieurs éditeurs reprochent déjà à Cloudflare, spécialiste de la sécurité, d'avoir publié les détails de la faille dans un billet de blog alors qu'ils n'ont pas encore eu le temps de corriger le logiciel.
Et côté utilisateurs ?
Cloudflare a sauté sur l'occasion pour se faire un peu de pub, et décrit quelques méthodes de correction... Méthodes qui n'étaient pas disponibles pour un déploiement plus large. Comme le résume un spécialiste de la sécurité à ZDNet.com, "vous n'ouvrez pas la porte en agitant le drapeau rouge avant que les correctifs soient disponibles".
Red Hat, Debian, SuSE, Canonical, Oracle et d'autres sont sur le pont pour pousser des versions corrigées d'OpenSSL à leurs clients. Une opération qui pourrait prendre encore quelques heures pour certains éditeurs. Il est inutile de préciser qu'une fois les correctifs publiés, il y a tout intérêt à les installer le plus rapidement possible.
Côté utilisateurs, les mesures de prévention ne sont pas nombreuses. Cet outil permet de vérifier si un site est vulnérable mais son efficacité n'est pas garantie à 100%. Un changement de mot de passe pour vos services en ligne sera également peut-être nécessaire.
Source : ZD Net (http://www.zdnet.fr/actualites/heartbleed-17-des-sites-web-utilisant-ssl-vulnerables-39799673.htm), le 10 avril 2014
-
Bien résumé.
-
L'explication détaillée du bug :
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html (http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html)
Records have a type, a length, and data. Back to dtls1_process_heartbeat:
/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;
The first byte of the SSLv3 record is the heartbeat type. The macro n2s takes two bytes from p, and puts them in payload. This is actually the length of the payload. Note that the actual length in the SSLv3 record is not checked.
The variable pl is then the resulting heartbeat data, supplied by the requester.
Later in the function, it does this:
unsigned char *buffer, *bp;
int r;
/* Allocate memory for the response, size is 1 byte
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
So we're allocating as much memory as the requester asked for: up to 65535+1+2+16, to be precise. The variable bp is going to be the pointer used for accessing this memory. Then:
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
The macro s2n does the inverse of n2s: it takes a 16-bit value and puts it into two bytes. So it puts the same payload length requested.
Then it copies payload bytes from pl, the user supplied data, to the newly allocated bp array. After this, it sends this all back to the user. So where's the bug?
Vous le voyez le problème? (Les problèmes d'ailleurs.)
Ce code ne correspond pas du tout à ce qu'on s'attend à voir! Quand on a lu quelques codes sources de traitement de données venant du réseau, les problèmes sont évidents : il n'y a aucune validation des valeurs et de la taille des données.
Comme toujours, la proposition standard "d'écrire des tests unitaires" ne sert que si quelqu'un pense à tester le cas où le message est mal formé. Si la personne pense à cette éventualité, elle peut aussi bien lire le code source et voir que ce cas n'est pas traité. Pour moi "écrire des tests unitaires" ne résout rien dans ce genre de cas (par contre cela aurait détecté une autre faille dans un composant TLS, où un cas était géré spécialement par ce code mais pas traité correctement).
Ce genre de bugs est "code qui traite identiquement deux situations foncièrement différentes" :
- message bien formé
- message mal formé
Tout message est ici supposé bien formé. C'est une erreur de débutant (comme beaucoup de failles d'ailleurs).
Comme toujours, c'est plus facile à voir quand on nous dit "voici le bug". Cependant, je pense que si j'avais lu ce code, comme ça, sans me méfier spécialement, j'aurais tiqué sur l'absence de validation. J'en suis quasiment sûr.
-
Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)
Wednesday, April 9, 2014 9:58 AM
Posted by Matthew O'Connor, Product Manager
You may have heard of “Heartbleed,” a flaw in OpenSSL that could allow the theft of data normally protected by SSL/TLS encryption. We’ve assessed this vulnerability and applied patches to key Google services such as Search, Gmail, YouTube, Wallet, Play, Apps, App Engine, AdWords, DoubleClick, Maps, Maps Engine, Earth, Analytics and Tag Manager. Google Chrome and Chrome OS are not affected. We are still working to patch some other Google services. We regularly and proactively look for vulnerabilities like this -- and encourage others to report them -- so that that we can fix software flaws before they are exploited.
https://googleonlinesecurity.blogspot.com.au/2014/04/google-services-updated-to-address.html (https://googleonlinesecurity.blogspot.com.au/2014/04/google-services-updated-to-address.html)
Je suis assez surpris : je pensais que Google utilisait des frontaux sécurisés propriétaires pour ses services Web! ("sécurisé" dans le sens où il est impossible de copier le certificat même si on arrive à récupérer un de ces équipements)
-
Une des deux grandes questions "complotologiques" : est-ce que la NSA connaissait Heartbleed et a exploité cette information?
L'article de Bloomberg indiquant que la NSA savait :
NSA Said to Exploit Heartbleed Bug for Intelligence for Years
The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.
The agency’s reported decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government’s top computer experts. The NSA, after declining to comment on the report, subsequently denied that it was aware of Heartbleed until the vulnerability was made public by a private security report earlier this month.
“Reports that NSA or any other part of the government were aware of the so-called Heartbleed vulnerability before 2014 are wrong,” according to an e-mailed statement from the Office of the Director of National Intelligence.
Heartbleed appears to be one of the biggest flaws in the Internet’s history, affecting the basic security of as many as two-thirds of the world’s websites. Its discovery and the creation of a fix by researchers five days ago prompted consumers to change their passwords, the Canadian government to suspend electronic tax filing and computer companies including Cisco Systems Inc. to Juniper Networks Inc. to provide patches for their systems.
Putting the Heartbleed bug in its arsenal, the NSA was able to obtain passwords and other basic data that are the building blocks of the sophisticated hacking operations at the core of its mission, but at a cost. Millions of ordinary users were left vulnerable to attack from other nations’ intelligence arms and criminal hackers.
Controversial Practice
“It flies in the face of the agency’s comments that defense comes first,” said Jason Healey, director of the cyber statecraft initiative at the Atlantic Council and a former Air Force cyber officer. “They are going to be completely shredded by the computer security community for this.”
Experts say the search for flaws is central to NSA’s mission, though the practice is controversial. A presidential board reviewing the NSA’s activities after Edward Snowden’s leaks recommended the agency halt the stockpiling of software vulnerabilities.
When new vulnerabilities of the Heartbleed type are discovered, they are disclosed, the Office of the Director of National Intelligence said in response to the Bloomberg report. A clear process exists among agencies for deciding when to share vulnerabilities, the office said in a statement.
“This administration takes seriously its responsibility to help maintain an open, interoperable, secure and reliable Internet,” Shawn Turner, director of public affairs for the office, said in the statement. “Unless there is a clear national security or law enforcement need, this process is biased toward responsibly disclosing such vulnerabilities.”
Hunting Flaws
The NSA and other elite intelligence agencies devote millions of dollars to hunt for common software flaws that are critical to stealing data from secure computers. Open-source protocols like OpenSSL, where the flaw was found, are primary targets.
The Heartbleed flaw, introduced in early 2012 in a minor adjustment to the OpenSSL protocol, highlights one of the failings of open source software development.
While many Internet companies rely on the free code, its integrity depends on a small number of underfunded researchers who devote their energies to the projects.
In contrast, the NSA has more than 1,000 experts devoted to ferreting out such flaws using sophisticated analysis techniques, many of them classified. The agency found Heartbleed shortly after its introduction, according to one of the people familiar with the matter, and it became a basic part of the agency’s toolkit for stealing account passwords and other common tasks.
NSA Spying
The NSA has faced nine months of withering criticism for the breadth of its spying, documented in a rolling series of leaks from Snowden, who was a former agency contractor.
The revelations have created a clearer picture of the two roles, sometimes contradictory, played by the U.S.’s largest spy agency. The NSA protects the computers of the government and critical industry from cyber-attacks, while gathering troves of intelligence attacking the computers of others, including terrorist organizations, nuclear smugglers and other governments.
Ordinary Internet users are ill-served by the arrangement because serious flaws are not fixed, exposing their data to domestic and international spy organizations and criminals, said John Pescatore, director of emerging security trends at the SANS Institute, a Bethesda, Maryland-based cyber-security training organization.
One Agency
“If you combien the two into one government agency, which mission wins?” asked Pescatore, who formerly worked in security for the NSA and the U.S. Secret Service. “Invariably when this has happened over time, the offensive mission wins.”
When researchers uncovered the Heartbleed bug hiding in plain sight and made it public on April 7, it underscored an uncomfortable truth: The public may be placing too much trust in software and hardware developers to insure the security of our most sensitive transactions.
“We’ve never seen any quite like this,” said Michael Sutton, vice president of security research at Zscaler, a San Jose, California-based security firm. “Not only is a huge portion of the Internet impacted, but the damage that can be done, and with relative ease, is immense.”
The potential stems from a flawed implementation of protocol used to encrypt communications between users and websites protected by OpenSSL, making those supposedly secure sites an open book. The damage could be done with relatively simple scans, so that millions of machines could be hit by a single attacker.
Exploiting Flaw
Questions remain about whether anyone other than the U.S. government might have exploited the flaw before the public disclosure. Sophisticated intelligence agencies in other countries are one possibility.
If criminals found the flaw before a fix was published this week, they could have scooped up troves of passwords for bank accounts, e-commerce sites and e-mail accounts worldwide.
Evidence of that is so far lacking, and it’s possible that cybercriminals missed the potential in the same way security professionals did, suggested Tal Klein, vice president of marketing at Adallom, in Menlo Park, California.
The fact that the vulnerability existed in the transmission of ordinary data -- even if it’s the kind of data the vast majority of users are concerned about -- may have been a factor in the decision by NSA officials to keep it a secret, said James Lewis, a cybersecurity senior fellow at the Center for Strategic and International Studies.
Determining Risk
“They actually have a process when they find this stuff that goes all the way up to the director” of the agency, Lewis said. “They look at how likely it is that other guys have found it and might be using it, and they look at what’s the risk to the country.”
Lewis said the NSA has a range of options, including exploiting the vulnerability to gain intelligence for a short period of time and then discreetly contacting software makers or open source researchers to fix it.
The SSL protocol has a history of security problems, Lewis said, and is not the primary form of protection governments and others use to transmit highly sensitive information.
“I knew hackers who could break it nearly 15 years ago,” Lewis said of the SSL protocol.
That may not soothe the millions of users who were left vulnerable for so long.
Panel’s Recommendation
Following the leaks about NSA’s electronic spying, President Barack Obama convened a panel to review surveillance activities and suggest reforms. Among the dozens of changes put forward was a recommendation that the NSA quickly move to fix software flaws rather that exploit them, and that they be used only in “rare instances” and for short periods of time.
“If the NSA knows about a vulnerability, then often other nation states and even criminal organizations can exploit the same security vulnerability,” said Harley Geiger, senior counsel for the Center for Democracy & Technology in Washington. “What may be a good tool for the NSA may also turn out to be a tool for organizations that are less ethical or have no ethics at all.”
Currently, the NSA has a trove of thousands of such vulnerabilities that can be used to breach some of the world’s most sensitive computers, according to a person briefed on the matter. Intelligence chiefs have said the country’s ability to spot terrorist threats and understand the intent of hostile leaders would be vastly diminished if their use were prohibited.
To contact the reporter on this story: Michael Riley in Washington at michaelriley@bloomberg.net
To contact the editors responsible for this story: Sara Forden at sforden@bloomberg.net Winnie O’Kelley
Source : http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html (http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html)
La politique de la NSA concernant les failles :
On Saturday, the Senior Administration Officials cast light on the subject of Internet Security and said President Obama has clearly decided that whenever the U.S. Intelligence agency like NSA discovers major vulnerabilities, in most of the situations the agency should reveal them rather than exploiting for national purpose, according to The New York Times.
OBAMA's POLICY WITH LOOPHOLE FOR NSA
Yet, there is an exception to the above statement, as Mr. President carved a detailed exception to the policy “Unless there is a clear national security or law enforcement need,” which means that the policy creates a loophole for the spying agencies like NSA to sustain their surveillance programs by exploiting security vulnerabilities to create Cyber Weapons.
After three-month review of recommendations [PDF-file], the Final Report of the Review Group on Intelligence and Communications Technologies was submitted to Mr. Obama on last December, out of which one of the recommendation on page no. 37 states that, “In rare instances, US policy may briefly authorize using a Zero Day for high priority intelligence collection, following senior, interagency review involving all appropriate departments.”
Obama took this new decision in January this year, but the elements of decision disclosed just one day after the story of HeartBleed OpenSSL Security Bug broke last week and Bloomberg reported that the NSA may have known about the flaw for last two years and using it continuously to gain information instead of disclosing it.
The Office of the Director of National Intelligence (ODNI) released a statement on Friday in response to the Bloomberg report saying NSA was not aware of Heartbleed until it was made public.
The ODNI report concludes, “In response to the recommendations of the President’s Review Group on Intelligence and Communications Technologies, the White House has reviewed its policies in this area and reinvigorated an interagency process for deciding when to share vulnerabilities. This process is called the Vulnerabilities Equities Process. Unless there is a clear national security or law enforcement need, this process is biased toward responsibly disclosing such vulnerabilities,” that coincides with above stated recommendation.
PURCHASED ZERO DAYS, AGAINST ANYONE-ANYTIME
As we already know, U.S. government is the biggest buyer of cyber weapons and Zero-Day exploits, those NSA and FBI are using from last many years to compromise the Internet for spying on the whole world.
In NSA’s exploit archive there could be more than 50 percent of purchased exploits, and without any doubt we can label it as 'National Security or Law Enforcement Needs'. Thanks for above exceptional recommendation, the use of Zero-day exploits are now enough legal against anyone-anytime.
Review Group report also mentions, “US policy should generally move to ensure that Zero Days are quickly blocked, so that the underlying vulnerabilities are patched on US Government and other networks.”
In March, Edward Snowden files revealed that the National Security Agency conducted a major offensive cyber operation called "Operation Shotgiant" against the Chinese government and networking company Huawei, in early 2009 and also accused for stealing the source codes for certain products.
Will U.S also responsibly disclose zero-day flaws to foreign vendors (like Huawei and ZTE) as well, rather than exploiting their products for Cyber espionage on other Countries?
Source : http://thehackernews.com/2014/04/Obama-NSA-Review-policy-Zero-day-Exploit.html (http://thehackernews.com/2014/04/Obama-NSA-Review-policy-Zero-day-Exploit.html)
Je pense que personne ne croira jamais plus les dénégations de la NSA!
-
Une explication de la faille en vidéo très bien réalisée par Arrêt sur Image et Next INpact :
14h42 #12 : Heartbleed, faille de la décennie ? (https://www.youtube.com/watch?v=ARD_R2D9j1o#ws)
-
Merci mais 43 minutes c'est juste pour la faille ?
-
C'est quand des failles graves de la couche de sécurisation apparaissent que je me dis que c'est sympa qu'il y ait une petite sécurité supplèmentaire sur certaines Webapp, comme lafibre, qui évite que le mot de passe entré par l'utilisation et l'authentificateur (le secret dérivé du mot de passe utilisateur stocké en BdD) soient échangés en clair sur le lien sécurisé.
Le mot de passe de votre compte bancaire a peut être été récupéré, mais le mot de passe de lafibre, non.
-
Le mot de passe de votre compte bancaire a peut être été récupéré, mais le mot de passe de lafibre, non.
Avec au moins une bonne partie des banques, il y a un système à base de clavier numérique qui fait que non, les identifiants ne sont pas échangés en clair sur le lien sécurisé. Ce qui est transmis, c'est alors l'emplacement de la touche virtuelle sur laquelle le client a cliqué. La vraie valeur ne peut alors normalement pas être connue, à moins que le pirate n'ait aussi intercepté l'image de pavé numérique qui a été téléchargée précédemment par le client, et la lise avec un OCR (ou avec ses yeux). Ça ne vaut pas un bon système de hash + salt, mais ça peut déjà compliquer grandement la tâche du pirate avec une faille comme Heartbleed.
Il peut également y avoir un peu de « chiffrement » ajouté côté JavaScript, par exemple pour LCL de mémoire il y a un xor bidon à partir des données de formulaires. Mais ça, c'est plus facilement réversible.
Là je parle des interfaces de gestion des comptes bancaires, quand il faut rentrer le code confidentiel, mais c'est vrai que c'est généralement plus pauvre sur les interfaces de paiement en ligne.