Hackers Are Stealing Session Cookies To Bypass Multi-factor Authentication (esecurityplanet.com) 28
Slashdot reader storagedude writes: Hackers are stealing cookies from current or recent web sessions to bypass multi-factor authentication (MFA), according to an eSecurity Planet report.
The attack method, reported by Sophos researchers, is already growing in use. The "cookie-stealing cybercrime spectrum" is broad, the researchers wrote, ranging from "entry-level criminals" to advanced adversaries, using various techniques.
Cybercriminals collect cookies or buy stolen credentials "in bulk" on dark web forums. Ransomware groups also harvest cookies and "their activities may not be detected by simple anti-malware defenses because of their abuse of legitimate executables, both already present and brought along as tools," the researchers wrote.
Browsers allow users to maintain authentication, remember passwords and autofill forms. That might seem convenient, but attackers can exploit this functionality to steal credentials and skip the login challenge.
Behind the scenes, browsers use SQLite database files that contain cookies. These cookies are composed of key-value pairs, and the values often contain critical information such as tokens and expiration dates.
Adversaries know the exact name and location of these files for all major browsers such as Chrome, Firefox, and even Brave, on various operating systems. That's why the attack can be scripted. It's not uncommon to find such scripts along with other modules in info-stealing and other malware.
For example, the latest version of the Emotet botnet targets cookies and credentials stored by browsers, which include saved credit cards. According to the Sophos researchers, "Google's Chrome browser uses the same encryption method to store both multi-factor authentication cookies and credit card data."
To gain initial access, attackers can also perform phishing and spear-phishing campaigns to implant droppers that can deploy cookie-stealer malware stealthily.
The cookies are then used for post-exploitation and lateral movements. Cybercriminals can use them to change passwords and emails associated with user accounts, or trick the victims into downloading additional malware, or even deploy other exploitation tools such as Cobalt Strike and Impacket kit.
Users should not use built-in features to save passwords unless the browser encrypts them with, at least, a master password. It's recommended that users uncheck the setting called "remember passwords," and users should probably not allow persistent sessions as well.
Developers can be part of the problem if they don't secure authentication cookies properly. Such cookies must have a short expiration date. Otherwise, the persistent authentication could turn into a persistent threat. You can have great security processes and still get hacked because the cookies do not have the necessary flags (e.g., HttpOnly, Secure attribute). For example, authentication cookies must be sent using SSL/TLS channels. Otherwise the data could be sent in plain text and attackers would only have to sniff traffic to intercept credentials.
The attack method, reported by Sophos researchers, is already growing in use. The "cookie-stealing cybercrime spectrum" is broad, the researchers wrote, ranging from "entry-level criminals" to advanced adversaries, using various techniques.
Cybercriminals collect cookies or buy stolen credentials "in bulk" on dark web forums. Ransomware groups also harvest cookies and "their activities may not be detected by simple anti-malware defenses because of their abuse of legitimate executables, both already present and brought along as tools," the researchers wrote.
Browsers allow users to maintain authentication, remember passwords and autofill forms. That might seem convenient, but attackers can exploit this functionality to steal credentials and skip the login challenge.
Behind the scenes, browsers use SQLite database files that contain cookies. These cookies are composed of key-value pairs, and the values often contain critical information such as tokens and expiration dates.
Adversaries know the exact name and location of these files for all major browsers such as Chrome, Firefox, and even Brave, on various operating systems. That's why the attack can be scripted. It's not uncommon to find such scripts along with other modules in info-stealing and other malware.
For example, the latest version of the Emotet botnet targets cookies and credentials stored by browsers, which include saved credit cards. According to the Sophos researchers, "Google's Chrome browser uses the same encryption method to store both multi-factor authentication cookies and credit card data."
To gain initial access, attackers can also perform phishing and spear-phishing campaigns to implant droppers that can deploy cookie-stealer malware stealthily.
The cookies are then used for post-exploitation and lateral movements. Cybercriminals can use them to change passwords and emails associated with user accounts, or trick the victims into downloading additional malware, or even deploy other exploitation tools such as Cobalt Strike and Impacket kit.
Users should not use built-in features to save passwords unless the browser encrypts them with, at least, a master password. It's recommended that users uncheck the setting called "remember passwords," and users should probably not allow persistent sessions as well.
Developers can be part of the problem if they don't secure authentication cookies properly. Such cookies must have a short expiration date. Otherwise, the persistent authentication could turn into a persistent threat. You can have great security processes and still get hacked because the cookies do not have the necessary flags (e.g., HttpOnly, Secure attribute). For example, authentication cookies must be sent using SSL/TLS channels. Otherwise the data could be sent in plain text and attackers would only have to sniff traffic to intercept credentials.
Super Old News? (Score:4, Insightful)
Not sure why this is mentioned now, but this has been a primary source of targeted attacks for years.
Re: (Score:1)
Likely someone has just noticed there's about 3000 "legitimate" Android apps that have been bulk harvesting them for untargeted attacks too now, so they can't just blame the victims anymore.
Re: Super Old News? (Score:2)
The old news way of writing this story goes like this:
If you install mal-crap on your computer, those dog-gone hackers will steal whatever you have in the computer.
"Whatever" imcludes info kept by your browser.
I knew an, um, "lady" whose motto was "admit nothing, deny everything".
She was talking about her personal life, but her advice also applies to how you should configure your browser.
Re: (Score:3)
Oh, no. Don't you see? That was stealing session cookies to bypass boring old regular authentication. This is cookie stealing to bypass shiny new two-factor authentication.
Re:Super Old News? (Score:5, Interesting)
This has been a problem going all the way back to 1993. Geezus.
1) Stealing credentials that aren't encrypted, Remember "back oriface" ? There's been a dozen different ways to get into Windows machines until Windows Vista because of how the privilege separation was pretty much non-existance.
2) Cookie theft has been an on-going thing, and one of those problems is "game launchers" where it's been known for well over 15 years you can just straight up copy paste the "launch code" from the launcher after you play the game once, and will be able to bypass the authentication for sometimes months.
What's the solution? Well your websites that use session cookies need to adhere to one session cookie = one ip. Unfortunately mobile devices do not work this way, and every time a mobile device connects, it might be a different IP as the person on the phone moves between tween different cell points.
The real solution is one we don't want to say:
- Abandon IPv4, use only IPV6 for anything with a login, every device has it's own "semi-permanent IPv6" address, no NAT hijinks.
- Both sides of the session management verify the IP address they are using and if it changes, treat it as a separate session. This may mean that the server side may end up with 100 sessions for one identity on one device.
Re: (Score:2)
Chrome encrypts locally stored cookies. Malware needs to overcome that protection as well now. As far as I can tell, Firefox does not.
The problem with IP locking is that it barely works with home broadband, and not at all with mobile or people who switch wi-fi networks often (home/work/school/fiends). People would never accept having to log in to their accounts every few minutes, or even multiple times a day.
Re: (Score:2)
I'll give him this: tying a session to an IP makes sense sometimes. But as you make clear, it's not without its problems.
Besides, there are other, very simple, approaches that frustrate session hijacking. On some of our systems, for example, we generate a new token after each transaction, invalidating the old one. Other systems just expire tokens after some predetermined amount of time. They always expire at the end of the session, of course.
I have no idea why some people keep session cookies, o
Re: (Score:2)
I heard some rumblings about putting a limited lifespan on session cookies, forcing sites to generate new ones regularly. I think Chrome already started deleting site data if the user hadn't visited for a while, but "a while" is something daft like 6 months. As usual for Google they are rolling it out very slowly to avoid breakage, but given how many sites come with insecure warnings because they don't support HTTPS now I don't think it actually helps much.
Re: (Score:2)
Cookies without an expiration date were supposed to be considered 'session cookies'. The name is confusing, but that just means cookies that are supposed to be maintained only for the current session and deleted when the browser is closed.
I just checked and ... what the hell? Chrome isn't deleting session cookies? Firefox does, thankfully, but an awful lot of people use Chrome.
As usual for Google they are rolling it out very slowly to avoid breakage
Meh. I figure if someone makes their site dependent on Chrome's non-standard behavior, they deserve what they get.
Chrome is very
Re: (Score:2)
Re: (Score:2)
I thought about that, but if they can get into an encrypted local store of cookies then they can probably get the browser's signature too.
Re: (Score:2)
Re: (Score:1)
No no no no no, man! The important thing is that there are CYBERcriminals! They are CYBER! So, y'know, half robots, like The Six-Million Dollar Man, boop boop boop boop boop! Although the price tag needs to be adjusted for inflation. What was that show, late 1970s? So, not as cheap as it sounds. Let's see, maybe $27M? It's cheap! Elon Musk probably has a a hundred clone soldiers already in his dungeon. I mean, the local one.
The important thing is that all these CYBERcriminals are going to be walking around
Re: Super Old News? (Score:1)
O NOOZ! (Score:1)
I thought only the Cookie Monster stole em
Useful application of this vulnerability (Score:4, Interesting)
This vulnerability is often use for good, as well as for evil. Many of us dislike the lack of flexibility, limited extension opportunites, and UI fugliness of Slack, so we use WeeChat IRC with the wee-slack plugin [github.com] . In order to make it work, I and others have developed cookie extractors for Firefox [github.com] and Chrome. The WeeChat + plugin user adds the cookie to the configuration via the /slack extended command, and off to the races.
Chrome is a bit more resilient in that the database is encrypted, but since the database is local it's only a matter of sleuthing using the browser console and applying some debugging kung f00 to extract the cookies. My implementation leverages Firefox because it's SQLite DB entries are in plaintext and it's a lot easier to deal with. An earlier implementation also supported Chrome but I dropped it because friends don't let friends use that browser.
Cheers!
pr3d4t0r
Re: (Score:1)
Re: (Score:3)
Isn't a cookie extractor for an end user as easy as F12, hit Console, then type "document.cookie"?
There are two different cookies in there. You may extract the dCookie as you described, the team session token is stored in a way that you can't pull it that way, hence the need for code. In Firefox, two different databases are involved (cookies.sqlite and webstore.sqlite). The values in webstore.sqlite aren't accessible from the browser, hence the need for the extractor. Once the values are extracted it's necessary to get the right session token because Slack lists more than one (team, enterprise, etc.
Complex passwords (Score:3)
2. Then they tell me to use the app instead of the browser(Which just a browser in disguise in many cases)
3. Then they tell me to use complex passwords.
4. Then they tell me use "google suggested passwords" and have google save the password because, you know, they are too complex for a mere mortal human to type on small touchscreen
NOW they tell me to go back to #1 but use complex passwords, but don't have anything "Save them" and no cookies because you know, session hijacking etc. I wish, but they discontinued the web interface and I can ONLY use the damned app, which I have ZERO control over..Soooo, great article for making me feel like flushing the whole Internet because of lazy coderz....
TELL ME WHAT TO DO!
Re:Complex passwords (Score:4, Insightful)
Making Life Worse (Score:2)
The problem with many of these recommendations is how much they make life suck for the actual user.
As a user, you'd really like to be able to log in to a website, and have it last 10 minutes or so at least, or maybe remember who you are for days. In practice every credit card and bank website I has, shuts me out after five minutes or so and I have to log in again.
I wish more sites would let you tune this risk, basically if you are not using Windows out Android you could relax the security policy a bit. Bu
Standard precautions (Score:2)
Standard precautions for session cookies:
The value of crypto binding in MFA systems (Score:2)
If your system does not protect against authenticator impersonation and is not cryptographically bound to the session then it is insecure. It's past time for the industry to stop knowingly deploying insecure MFA systems.
Why, exactly? (Score:2)
With so many diabetic people these days, why are we still using cookies in our web browsers?