Uther (./55852) :Rhooo c'était en gras, pourtant
Tu trolle même plus les URL, maintenant tu trolle dans les citations.
Je précise, parce qu'on dirais que certains ont encore mordu.
Uther (./55852) :Rhooo c'était en gras, pourtant
Tu trolle même plus les URL, maintenant tu trolle dans les citations.
Je précise, parce qu'on dirais que certains ont encore mordu.
flanker (./55857) :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.
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).
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.
Zerosquare (./55865) :La ministre de la justice a dit qu'il irait de gré ou de force...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".
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.
Meowcate (./55874) :Ç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 !)
Conclusion : c'est la merde parce que les devs du site n'ont pas vérifié les (certains ?) champs de formulaire contre des injections.
Folco (./55877) :Je te donne un exemple simple. Imagine que yN ne soit pas protégé contre les failles XSS.
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 ?
Zerosquare (./55881) :Il y a souvent des commentaires des clients un peu partout ^^
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.
Warpten (./55887) :D'autres ont fait des injections SQL sur un site et se sont aussi faits bannir en conséquence
J'avais trouve une XSS sur un site et j'me suis fait bannir en consequence