Found the error Not allowed to load local resource: file:///etc/passwd while looking at infosec.pub’s communities page. There’s a community called “ignore me” that adds a few image tags trying to steal your passwd file.
You have to be extremely poorly configured for this to work, but the red flags you see should keep you on your toes for the red flags you don’t.
If you find something, report it. Don’t experiment on the public.
https://www.bugcrowd.com/resources/guide/what-is-responsible-disclosure/
My first thought was that a Javascript library pulled from a CDN got spiked.
That harmless self retweeting tweet was pretty funny though
Link?
https://letmegooglethat.com/?q=Twitter+self+retweeting+tweet+exploit
Sorry I couldn’t resist. Here’s a Tom Scott video https://youtu.be/zv0kZKC6GAM
That’s delightful.
Is this, by any chance, originated from the sub called
ignore me? In that case is probably my bad because is set as the image of the channel. I was playing with lemmy in the previous version and forgot about it, sorry.I created that channel to investigate why the lemmy instance was hanging every time there was a symbol in the URL, added that URI as icon for fun and forgot about it.
That alert appears because your browser is trying to load an image with that path, nothing dangerous or remotely exploitable, don’t worry.
Edit: I removed it so you shouldn’t see the alert anymore.
P.S. no, it’s not trying to steal anything, it’s your browser trying to load that file as an image but instead of being let’s say this url:
https://beehaw.org/pictrs/image/c0e83ceb-b7e5-41b4-9b76-bfd152dd8d00.png(this sub icon) , it’s this onefile:///etc/passwdso you browser is doing the request to your own file. Don’t worry, nothing got compromised.But… why? Why even put that URL there? Even if it was most likely harmless for all users, this still looks like an attempt at data exfiltration.
Because I wanted to try if others URI schemas were supported instead of http / https. file:// was a valid one. Don’t worry, the day an attempt of data exfil will happen, you will not see it though your console logs.
I doubt this person ever expected anyone to find it or to read that much into it lol
Sure… that’s what they ALL say…
Holy shit this is kind of unsettling. Though I would expect ALL major browsers to reject reading any local files like this… would this kind of thing actually succeed somewhere/somehow?
If you ran your browser as root and configured your browser to load local resources on non-local domains maybe. I think you can do that in chrome://flags but you have to explicitly list the domains allowed to do it.
I’m hoping this is just a bad joke.
you don’t need to be root to read
/etc/passwdThat’s because passwd doesn’t store the password hashes. Just user names.
Are you sure? What do you get when you run
$ cat /etc/passwdin terminal? Just paste the results here 😇Edit: to anyone reading this on the future, don’t actually do this, it was a joke
yup pretty sure
$ cat /etc/passwd fox:hunter2:1000:1000::/home/fox:/usr/bin/zsh😉
Weird, all I see is *******
Not even a root user, the most secure system ever.
Since you told me not to. There isn’t a risk on most linux systems; passwords were moved to /etc/shadow a long time ago. It only leaks the names of your users and largely useless info for most attackers:
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534::/nonexistent:/usr/sbin/nologin systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin messagebus:x:999:999:System Message Bus:/:/usr/sbin/nologin systemd-timesync:x:998:998:systemd Time Synchronization:/:/usr/sbin/nologin systemd-coredump:x:997:997:systemd Core Dumper:/:/usr/sbin/nologin delial:x:1000:1000:,,,:/home/delial:/bin/bash sshd:x:103:65534::/run/sshd:/usr/sbin/nologin xrdp:x:104:110::/run/xrdp:/usr/sbin/nologin dictd:x:105:111:Dictd Server,,,:/var/lib/dictd:/usr/sbin/nologin nm-openvpn:x:106:112:NetworkManager OpenVPN,,,:/var/lib/openvpn/chroot:/usr/sbin/nologin sssd:x:107:113:SSSD system user,,,:/var/lib/sss:/usr/sbin/nologinWell it’s not completely useless. It offers some insights into the system. Which service accounts exists, what usernames are used.
If an attacker finds a valid username they can then start bruteforcing the password.
From your account list we can see you have sshd and xrdp. Do they both provide the same kind of bruteforce protection? Are there any recent exploits for either?
That’s why I said largely useless. An attacker can narrow down the attack surface by ignoring anything that can’t login, but that just leaves them with root and delial, and they already knew or could’ve guessed both of those pieces of information (in this context anyway).
And as you noted when looking at the service accounts, they might be able to login or crack their way in via xrdp or sshd. So, unless you’re port-forwarding those protocols from the internet, how useful is that really? I would say largely useless. Assuming they port-scanned your public IP, they still need either an insecure config or an unpatched, remotely exploitable bug.
That being said, you’re totally right. The average Linux user isn’t “administering” their system, so they probably aren’t following their distribution’s security mailing list, installing security patches as they’re released, and actually RTFM. It’s best for the average user to play it unbelievably safe.
In this case, the machine isn’t actually running xrdp, and sshd doesn’t accept passwords or root logins. (Although, I need to setup knockd to protect that non-standard sshd port a bit more.) All passwords used on the system are random and longer than 32 characters. My router doesn’t port-forward to this machine, either.
This has been an exercise of Cunningham’s Law for the benefit of those reading.
Sometimes I hate how well Cunningham’s Law works. 😃
My bad, I guess it just feels like a file that would be behind tighter perms.
Yeah, seems highly unlikely to ever yield any results. Even if you did manage to read a file, you have to get lucky finding a password hash in a rainbow table or the password being shit enough to crack.
Also generally the actual password (or rather its hash) is stored in /etc/shadow on most systems from the past 20 odd years.
Yeah this is a TIL for me. I didn’t realize they were separated out. It makes sense, though I grant I’ve never taken a close look at these files.
And if anybody has publicly accessible ssh on their desktop machine, that allows password login, they’re kinda asking for it.
I cracked the BMC on my workstation motherboard by binwalking the publicly available firmware and finding, to my delight and dread, that the built in root user password was laughably weak. If a top5 motherboard manufacturer is still doing shit like that, users are too.
I also work in support and have seen first hand the bananas things people do, even smart people that should know better
Can confirm it’s still there for the
ignore mecommunity.
While this is concerning, I wonder what the author(s) of this were thinking would happen. I assume it’s supposed to be an attempt at stealing the server’s passwords, since I at least know of no browser that freely allows access to local files.
FWIW,
/etc/passwditself contains no passwords (the name exists for historical reasons) but it definitely is a globally accessible file that can give you clues about the target system. Given this, it’s more likely the user is attempting to find out if arbitrary disk reads are possible by using a well known path on many servers.
Nice share, thanks for the information. Definitely need to be careful both as a server operator with Lemmy, and a user of it.
I’ve had around 20 of ‘lol exploit’ queries in my instance. Luckily none of them succeeded.
I wonder if it is a bad actor or someone is trying to pentest Lemmy. If they were a bad actor wouldn’t they be more successful posting in a more popular community than “ignore me”?
That’s why I use uMatrix, JShelter and LocalCDN (alongside a few other) plugins on Firefox. At least random scripts won’t take over your system.
First thing I did when I got an account was enabled 2FA. It was a bit of a hassle cause its a link that you need to open in a device that supports it (ie: phone) but hey at least an option.
honestly, this feels more like a proof of concept than an actual hack. passwords are almost universally encrypted and stored in /etc/shadow nowadays and when I was on the security CoP at my old job cat’ing /etc/passwd was how we proved basic read access to a system but nothing more.
It is possible that something like this could exfil the file as well, which might leak info about what daemons a given system is running. An attacker could possibly then do some research to find vulnerabilities for a given service version and try the real attack later. Generally complex kill chains like this aren’t viable for mass scanning though, much more likely that they would just automate an attempt at a few common exploits than force themselves to do actual recon.