81–89 of 89 posts
Earlier quoted context omitted.
So how is an attacker going to access the machine?
If a certain account is present then the attacker might know a certain service is running and then target that. Might also reveal the purpose of the machine (oh, this is probably the build server) or who is managing it.
Earlier quoted context omitted.
If a certain account is present then the attacker might know a certain service is running and then target that. Might also reveal the purpose of the machine (oh, this is probably the build server) or who is managing it.
Nothing crucial should be directly accessible from the Internet.
It is information leakage, not the end of the world but it can potentially be helpful for an attacker.
Earlier quoted context omitted.
I had a server that used password authentication for the root user (on the standard port). After a few months of uptime it was hacked. I suppose even minimal extra security would've helped (no root user, only allow x login attempts in y time, changing the port for ssh), but I was still surprised someone got in so soon by simply guessing a 20+ string of gibberish (I still wonder if maybe something else happened). All…
It was something else. Nothing or no one brute-forced a 20+ random string pass. More likely some service (Wordpress, phpbb etc) got owned. I’ve had multiple servers running for years with < 15 char non random root pass (stupid as it is to do so) with no problems.
The only alternative that I can think of is that one of the two other users' machines was compromised, but AFAIK I didn't give them root access. Plus, the logs show an extreme number of login attempts (tens of thousands of entries in auth.log) with an eventually successful root login.
Any other ideas of what might've been an alternative cause?
Earlier quoted context omitted.
Exactly - it also works for non-SSH accounts, thus allowing software enumeration by testing for default/common/known default service users. For instance, an OpenBSD box running Tor may have a user "_tor", a Debian-based box (e.g. Ubuntu) may have a user "debian-tor", and so on (depending on how Tor was installed, in my case via pkg_add & apt-get; usernames might vary for different OS/repo versions). I have tested thi…
...and apparently the same issue exists in Dropbear up until current version (2018.76 / Feb 2018), which has an entirely different code base. A comment on /r/blackhat [0] led a colleague and me to look at Dropbear's sources, and it happens to have logic that is sufficiently similar [1] for the same PoC to work; tests against v2018.76 and a couple of earlier versions (e.g. v2013.58) are successful. Shodan shows some 6…
Earlier quoted context omitted.
It was something else. Nothing or no one brute-forced a 20+ random string pass. More likely some service (Wordpress, phpbb etc) got owned. I’ve had multiple servers running for years with < 15 char non random root pass (stupid as it is to do so) with no problems.
I'd be inclined to think the same, if not for the fact that this server wasn't running anything particularly 'ownable' that I can think of. The only alternative that I can think of is that one of the two other users' machines was compromised, but AFAIK I didn't give them root access. Plus, the logs show an extreme number of login attempts (tens of thousands of entries in auth.log) with an eventually successful root l…
Maybe you’re right though.
Earlier quoted context omitted.
I'd be inclined to think the same, if not for the fact that this server wasn't running anything particularly 'ownable' that I can think of. The only alternative that I can think of is that one of the two other users' machines was compromised, but AFAIK I didn't give them root access. Plus, the logs show an extreme number of login attempts (tens of thousands of entries in auth.log) with an eventually successful root l…
From the logs it sounds like maybe the password was in some lookup file or something. i.e. somehow that password was leaked and added to some list somehow. Maybe you’re right though.
EDIT: to be clear, I am pretty sure was the only person who used the root password to log in, and the single other user used a similarly long and random password with a different username. if I'd been compromised my problems would be quite a bit bigger. All I know is that right before the 'fatal' root login, there are 40.000+ lines of login attempts from ip's that originated from shady places (at least based on entering them in various GeoIP sites).
Earlier quoted context omitted.
A correct sshd_config includes: PasswordAuthentication no
To disable logging in with password you also need: ChallengeResponseAuthentication no
Earlier quoted context omitted.
To disable logging in with password you also need: ChallengeResponseAuthentication no
I got a chill up my spine when I read this but fortunately it looks like this is the default on Ubuntu 16.04 and 18.04 (at least).
openssh (1:4.1p1-1) experimental; urgency=low
[…]
* Disable ChallengeResponseAuthentication in new installations, returning
to PasswordAuthentication by default, since it now supports PAM and
apparently works better with a non-threaded sshd (closes: #247521).
[…]
-- Colin Watson Tue, 31 May 2005 01:33:33 +0100