Les meilleures news - Page 1863

flanker (./55857) :
Plus exactement un overflow lié au fait qu'il s'agissait d'un accéléromètre repris d'Ariane 4. Il fonctionnait bien sur Ariane 4, mais sur Ariane 5 qui accélérait davantage, cela occasionnait un overflow, donc un système qui croit avoir une accélération négative et qui s'autodétruit (alors que tout allait bien).

Plus exactement, il s'agissait de code porté d'un microcontrôleur vers un autre, pour un autre usage, sans refaire intégralement la validation, et en faisant l'impasse sur la gestion des erreurs, entraînant un overflow qui n'était pas originellement possible.

Bref, validez votre code.

Dans le même genre, il y a récemment eu Schiaparelli qui a raté son arrivée sur Mars car le dimensionnement de la centrale inertielle était trop faible, et que les conditions environnementales avaient été sous-estimées, avec pour conséquence la saturation des calculateurs et un scénario proche d'Ariane 5.

Merci pour les précisions

squalyl (./55850) :
en orga ouais, faut comprendre le coup des mouvements d'électons dans les mécanismes et le role des solvants, puis apres on voit un peu ou ca va... au debut apprendre par coeur aide, puis apres on voit que y'a des fondamentaux qui s'appliquent partout.

Rajoute les organometalliques et ca devient le bordel, t'as des trucs qui sont actives par leur environnement, des conformeres inactifs, etc.... tres peu pour mon pauvre petit cerveau

TL;DR : Benalla est convoqué devant le Sénat, il répond "j'irai, mais quand je voudrai, na".

Dur dur, le mec était le roi du monde dans l'ombre à ne prendre d'ordres de quasiment personne, et on le jette dans la lumière pour le détruire.

Le pauvre

tout un environnement se sent largement au dessus des lois, vers la bas...

Zerosquare (./55865) :

Benalla accepte à reculons de se rendre à une audition au SénatFIGARODOCUMENT - L'avocat de l'ex-collaborateur d'Emmanuel Macron a reçu un courriel le 6 septembre, en vue d'une convocation de son client le 19 septembre. S'il a, dans un premier temps, refusé de s'y rendre, Alexandre Benalla a fini par s'y résoudre, mardi soir, si une convocation officielle lui est...

TL;DR : Benalla est convoqué devant le Sénat, il répond "j'irai, mais quand je voudrai, na".

La ministre de la justice a dit qu'il irait de gré ou de force...



...mais qu'il pourrait ne pas parler des sujets actuellement en cours de traitement par la justice.

Bah ouais, ça avait été mentionné dès le début des auditions que la séparation des pouvoirs entraînerait ce genre de conséquence.

Javascript c'est chouette quand même !

On Friday, British Airways disclosed a data breach impacting customer information from roughly 380,000 booking transactions made between August 21 and September 5 of this year. The company said that names, addresses, email addresses, and sensitive payment card details were all compromised. Now, researchers from the threat detection firm RiskIQ have shed new light on how the attackers pulled off the heist.

RiskIQ published details tracking the British Airways hackers' strategy on Tuesday, also linking the intrusion to a criminal hacking gang that has been active since 2015. The group, which RiskIQ calls Magecart, is known for web-based credit card skimming—finding websites that don't secure payment data entry forms, and vacuuming up everything that gets submitted. But while Magecart has previously been known to use the same broadly targeted code to scoop up data from various third-party processors, RiskIQ found that the attack on British Airways was much more tailored to the company's specific infrastructure.

"We’ve been tracking the Magecart actors for a long time and one of the developments in 2017 was ... they started to invest time into targets to find ways to breach specific high-profile companies, like Ticketmaster," says RiskIQ threat researcher Yonathan Klijnsma. "The British Airways attack we see as an extension of this campaign where they’ve set up specialized infrastructure mimicking the victim site."

In its initial disclosure, British Airways said that the breach didn't impact passport numbers or other travel data. But the company later clarified that the compromised data included payment card expiration dates and Card Verification Value codes—the extra three or four-digit numbers that authenticate a card—even though British Airways has said it does not store CVVs. British Airways further noted that the breach only impacted customers who completed transactions during a specific timeframe—22:58 BST on August 21 through 21:45 BST on September 5.

These details served as clues, leading analysts at RiskIQ and elsewhere to suspect that the British Airways hackers likely used a "cross-site scripting" attack, in which bad actors identify a poorly secured web page component and inject their own code into it to alter a victim site's behavior. The attack doesn't necessarily involve penetrating an organization's network or servers, which would explain how hackers only accessed information submitted during a very specific timeframe, and compromised data that British Airways itself doesn't store.

Klijnsma, who pinned the recent Ticketmaster breach on Magecart and saw similarities with the British Airways situation, started looking through RiskIQ's catalog of public web data; the company crawls more than two billion pages per day. He identified all the unique scripts on the British Airways website, which would be targeted in a cross-site scripting attack, and then tracked them through time until he found one JavaScript component that had been modified right around the time the airline said the attack began.

'The British Airways attack we see as an extension of this campaign where they’ve set up specialized infrastructure mimicking the victim site.'

Yonathan Klijnsma, RiskIQ

The script is connected to the British Airways baggage claim information page; the last time it had been modified prior to the breach was December 2012. Klijnsma quickly noticed that attackers revised the component to include code—just 22 lines of it—often used in clandestine manipulations. The malicious code grabbed data that customers entered into a payment form, and sent it to an attacker-controlled server when a user clicked or tapped a submission button. The attackers even paid to set up a Secure Socket Layer certificate for their server, a credential that confirms a server has web encryption enabled to protect data in transit. Attackers of all sorts have increasingly used these certificates to help create an air of legitimacy—even though an encrypted site is not necessarily safe.

The airline also said in its disclosure that the attack impacted its mobile users. Klijnsma found a part of the British Airways Android app built off of the same code as the compromised portion of the airline's website. It's normal for an app's functionality to be based in part on existing web infrastructure, but the practice can also create shared risk. In the case of the British Airways Android app, the malicious JavaScript component the attackers injected on the main site hit the mobile app as well. Attackers seem to have designed the script with this in mind by accommodating touchscreen inputs.

While the attack wasn't elaborate, it was effective, because it was tailored to the specific scripting and data flow weaknesses of the British Airways site.

British Airways said in a statement to WIRED on Tuesday, "As this is a criminal investigation, we are unable to comment on speculation."1 RiskIQ says it gave the findings to the UK's National Crime Agency and National Cyber Security Centre, which are investigating the breach with British Airways. "We are working with partners to better understand this incident and how it has affected customers," an NCSC spokesperson said of the breach on Friday.

RiskIQ says it is attributing the incident to Magecart because the skimmer code injected into the British Airways website is a modified version of the group's hallmark script. RiskIQ also views the attack as an evolution of the techniques used in the recent Ticketmaster breach, which RiskIQ linked to Magecart, though with the added innovation of directly targeting a victim's site rather than compromising a third party. And some of the attack infrastructure, like the web server hosting and domain name, point to the group as well.

So far British Airways and law enforcement haven't publicly commented on this attribution, but Klijnsma says the other takeaway for now is the prevalence of tiny website vulnerabilities that can quickly turn into huge exposures.

"It comes down to knowing your web-facing assets," Klijnsma says. "Don’t overexpose—only expose what you need. The consequences, as seen in this incident, can be really, really bad."

1Update 9/11/18 10:15am ET to include a statement from British Airways.

C'est bizarre quand-même qu'il n'y ait pas eu de blocage au niveau du navigateur, non ? Après, il faut voir comment exactement ont été injectés les scripts...

tl;dr : des pirates ont injecté du JS sur le site de British Airways via un XSS, leur permettant de récupérer les infos de soumission du formulaire de commande (nom, adresse, etc).
Les pirates ont bien fait les choses en récupérant aussi les infos complètes de CB de paiement, via un serveur équipé d'un certificat SSL pour avoir la petite serrure qui fait propre, et se sont assurés que leur montage est tout aussi efficace sur mobile.
De cette façon, ils ont pu récupérer des infos que même British Airways ne stocke pas sur ses serveurs.

Conclusion : c'est la merde parce que les devs du site n'ont pas vérifié les (certains ?) champs de formulaire contre des injections.

Meowcate (./55874) :
Conclusion : c'est la merde parce que les devs du site n'ont pas vérifié les (certains ?) champs de formulaire contre des injections.

Ça n'explique pas comment ont été faites les injections pour que les navigateurs ne les bloquent pas ^^ (enfin, le navigateur libertaire de Kevin est une exception, bien sûr !)

C'est en fait mal expliqué. Un moment à lire, j'ai l'impression que c'est une faille XSS classique (les navigateurs n'ont pas de raison de la bloquer, c'est au site de le faire. De plus la délocalisation des libs JS comme jQuery & consorts fait que les navigateurs ne cherchent pas à bloquer les 3rd party). Mais un autre moment, j'ai l'impression qu'ils ont modifié (du genre un commit sur un vieux repo que BA utilisait dont ils ont réussi à avoir le contrôle) un 3rd party, ce qui est une attaque dont la possibilité est plus rare mais bien plus efficace.

Comment peut-on exploiter une faille XSS ? Si je comprends bien, ça conssite à faire exécuter par un site un script hébergé sur un autre. Mais ça demande dans un premier temps un accès au site cible pour faire une première modification du code, permettant ensuite l'appel d'un script externe, non ?

si j'ai bien compris en général des données de formulaires mal filtrées se retrouvent dans le html d'une page?

Le truc c'est que le terme XSS est utilisé pour beaucoup de choses qui ne sont pas forcément du cross-site. Le plus souvent on utilise ce terme dès qu'on exécute du code d'origine externe qui peut provenir d'une injection de code (javascript, php, sql, ...) souvent au moyen de saisies formulaires ou de paramètres de requete mal sécurisées.

Folco (./55877) :
Comment peut-on exploiter une faille XSS ? Si je comprends bien, ça conssite à faire exécuter par un site un script hébergé sur un autre. Mais ça demande dans un premier temps un accès au site cible pour faire une première modification du code, permettant ensuite l'appel d'un script externe, non ?

Je te donne un exemple simple. Imagine que yN ne soit pas protégé contre les failles XSS.
À ce moment, je vais écrire dans mon message par exemple <script>alert("Hello World")</script>. Ce qui fait que chaque fois que quelqu'un chargera une page où se trouve mon message, il aura une alerte JS.
Maintenant, si je la mets plutôt dans ma signature, c'est sur toutes les pages où j'aurais déjà posté par le passé. Le but de la faille XSS est de faire entrer des données non-filtrées.
Partant de là, oublions le alert et insérons plutôt du code distant. Cela me permet de contrôler l'insertion via le code distant (le vider pour rester discret, l'updater sans avoir à exploiter de nouveau la faille...).

C'est pour cela qu'on parle de faille XSS : la majeure partie du temps, c'est fait pour appeler un code distant. Mais la racine de la faille, c'est l'insertion du code qui permet d'appeler le code distant.
Ceci étant, ça reste du coup cantonné ici à Javascript, à HTML (si au lieu d'un <script> on insère un <iframe>), à du CSS, du média, etc, mais pas au serveur. À moins que les devs soient vraiment très cons pour avoir demandé à leur code serveur d'evaluer ce que retourne leur JS. Autrement dit, il faut qu'il y ait un espace où les victimes puissent voir la section où les données pirates apparaissent.
Ceci étant au final, si tu arrives à insérer du code via XSS, tu peux virtuellement tout te permettre envers le client tant qu'il est sur ce site, jusqu'à le faire naviguer dans une iframe totale sur une fausse copie du site pour enregistrer la moindre action, la moindre info tapée.

J'ai souvenir, il y a longtemps (sur un forum FR dédié à l'éditeur de cartes de Warcraft 3, pour donner une idée), un des membres s'est amusé à tester une faille XSS en modifiant sa signature pour... déclencher des commandes ActiveX. Grâce à la magie de IE 6, pour les fous qui l'utilisaient, afficher la signature de ce membre appelait ActiveX, qui enclenchait alors une action Windows... qui rebootait la machine cliente. C'est en parti pour ce genre de conneries que ActiveX était très décrié.
Ce n'était pas un connard, il a rapidement modifié sa sign, c'était plus une POC, et ça a poussé du monde à passer à Firefox.

C'est une bonne explication du principe de base. Mais il y a un point obscur : autant yN permet aux utilisateurs d'injecter du contenu lisible par tous (normal pour un forum), autant un site comme British Airways n'a pas de raison de le faire.

Je mise sur la négligence, "on a sécurisé partout à la sortie du site, et au fil des updates on a fini par oublier un ou deux trucs".
Mais comme j'ai proposé plus tôt, l'article est un peu flou et il peut s'agir de l'infection d'une lib JS externe, cela reste par définition du XSS. Il est facile pour ces sites ayant parfois des centaines (oui !) de scripts externes chargés à chaque page qu'un ou deux soit si vieux que quelqu'un en prenne facilement le contrôle, et zou !
Les 3rd party nécessitent toujours d'avoir une absolue confiance dans le maintien du code à long terme.

Le problème est tout aussi présent pour les systèmes de packages comme Composer. On a parlé il n'y a pas si longtemps d'un dev qui se l'est joué "He mad" et a viré son code de github, mettant à genoux quantité de projets qui s'en servaient. Maintenant il suffit d'imaginer qu'au lieu de retirer son code, il y insère du code malveillant (après tout il a le contrôle du dépôt) et boum, champagne !

Je dirais bien qu'avoir une centaine de scripts externes est déjà cinglé, et que ça l'est encore plus sur un site qui manipule des informations personnelles et bancaires, mais on m'accuserait de radoter.

Zerosquare (./55881) :
C'est une bonne explication du principe de base. Mais il y a un point obscur : autant yN permet aux utilisateurs d'injecter du contenu lisible par tous (normal pour un forum), autant un site comme British Airways n'a pas de raison de le faire.

Il y a souvent des commentaires des clients un peu partout ^^

Le plus fun (façon de parler) des failles XSS, c'est qu'elles sont potentiellement auto-réplicantes. Il suffit d'imaginer par ex que ma sign yN ait un bloc de code qui fait que toute personne la chargeant se voit ajouté automatiquement le code de la faille, de façon masqué, dans son formulaire de nouveau message : si la page était à son maximum de messages, ce nouveau message propagera la faille à la page suivante sans avoir besoin de la présence de ma signature, youhou !

Flan > certes, je n'avais pas pensé à ça.

Meowcate > Veux-tu bien arrêter de peupler le sommeil de Zeph de cauchemars ?

J'avais trouve une XSS sur un site et j'me suis fait bannir en consequence

Ok, merci bien

Warpten (./55887) :
J'avais trouve une XSS sur un site et j'me suis fait bannir en consequence

D'autres ont fait des injections SQL sur un site et se sont aussi faits bannir en conséquence

Les 3 prochaines injections trouvées sur yN seront récompensées ! par... heu... je sais pas, une banane à côté du pseudo pendant 3 mois