New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
That seems the issue.
But really main issue is it should never be shared VLAN. It does not take a propulsion scientist to setup customer VPN with different VLAN for segmented access.
Should never have been public in the first place, it was not your fault.
So many drive by exploit on Supermicro IPMI, we know to segregate it to far away. Your provider wishfully should have done same, but they are forthcoming and I am sure will improve the strategic defenses in the future.
Isn’t admin mean administrator? 🤔
I suspect they are referring to 2 unique usernames both of which have admin roles.
Not in this case. ASRock firmware comes with 2 separate users other than admin. Administrator and anonymous. The attacker is using the administrator user to brute force the IPMI.
That's right.
Thanks for the heads-up. Double checked the IPMI. It is only reachable by the IP-addresses I whitelisted. All the other connections are dropped. Maybe that’s an idea? We are not using ASRock, by the way.
Given the known vulns for IPMI in the past, having publicly accessible IPMI (or any OOB management) interfaces is incredibly irresponsible. How bizarre.
Wait... Is the changeme password asrock hardcodded default?
Edit because I didn't see the above, but my guess this is as simple as people not setting BOTH the "admin:admin" and "Administrator:superuser" accounts properly by default lol
You can't login to the IPMI without changing admin user password.
It's the administrator user that is being used to get access to the IPMI.
The attacker shared a part of his logs as an example that only had administrator user along with IP and passwords on it.
Edit: ASRock never told us anything about administrator user. Or did they?
No not in the individual motherboard manual, only the "admin" user.
There is a separate document about the management utility that mentions the "Administrator" user here:
https://download.asrock.com/TSD/SMU/Manual/ASRock Rack Server Management_v1.0.2.pdf
Which to me seems like ASRock overlooked and forgot about this duplicate user. The normal consumer manual means people will forget to set the Administrator password since it only tells you to use admin.
Are you sure about this hardcoded password? Do you have link of the firmware, I can confirm for you folks.
None of mine have that as a hard password, so surely not.
I copied it from the attacker's given logs. My IPMI had that as Administrator password.
All the passwords that I have seen from his log for Administrator user is very easy, short and crackable.
Which ASRR boards are affected by this? We run IPMI on local IPs only, but I've noticed in the past that they come with the 'Administrator' user. However, that user is always set to 'enabled = false'. I've tested on a few with this 'superuser123!' password using both ipmitool and web UI and can't seem to login to any of them with it.
Update, the default password is actually 'superuser'. Just tried on one of my boards and verified that you are able to access via ipmitool using those credentials.
Proxmox VE is fairly robust and secure, but in general, you should try to reduce the number of publicly exposed interfaces that you have. If there happens to be a login exploit or RCE, then your entire infrastructure can be gone (just like what happened to CyberPanel).
IPMI is just especially vulnerable because the software is typically outdated on most motherboards. For example, X570D4U boards haven’t received an updated IPMI since 2021. However, a vulnerability could happen to any software.
That's right. Mine had ******** So probably it took a bit more time to crack.
I have seen superuser and some other easy passwords on his logs.
Just start deleting Administrator user from your IPMIs.
I tried an bruteforce is working like charm.
If anyone of you want to audit this, let me know, I'll try test and give you results. at No cost.
L0L. If I start giving out more of those passwords here we are going to have an apocalypse.
Please don't bruteforce anyone's IPMI.
Avoid it sure, but it isn't always practical to never do.
If there is a vulnerability, that is on the vendor, if there is an undeployed patch, that is on the owner.
A malicious user could get access to an internal VLAN, even if your VPN solution limits x user to y IP, user x could use y as a proxy to attack the internal network of other IPMIs, if they can't be secured, that is on the vendor.
Not giving out-of-band management hosts public IPs helps with exposure, but they should be secure and be able to survive on their own.
cock.li
Dude! I've lab to test
Its my job to secure hosting and our customers.
so you're a professional but couldn't come up with your own password list to test?
hibp downloader been around for years, password list that being used in wpa2 cracking / rainbow table been around for decades and you still ask for this. really?
Did anyone here manage to get response from ASRock yet?
@NDTN did you had any responses to the same thing you reported to them earlier?
You're misunderstanding this, @Shakib Said. The password is hardcoded in the firmware, and I’m not interested in doing some random brute-force using password lists like RockYou or SecLists. Our job is to dig deeper into the issue by reversing the firmware and finding the root problem. This will benefit the entire community. That’s why I’m asking for the firmware, not password.
Anyone using ASRock mobo server should look out for
/usr/bin/systemd-hostIt's a JungleSec remote shell/backdoor. Even if your server isn't encrypted/compromised yet, the attacker might have already got into your server and put this shell/backdoor for his future ransomware attack. Just securing your IPMI with new password, removing Administrator user etc means nothing if it's already there!
cat /usr/bin/systemd-hostIf there is no such file or directory, you're probably fine. If he did got into your server, your IPMI and server root password will not work anymore. There is a chance that all of your data will be encrypted as soon as you reboot your server for changing your IPMI & root password.
If you do find /usr/bin/systemd-host on your server, backup your data first and then delete it. (At your sole risk)
Calling out @fiberstate to notify all of their clients about this JungleSec remote shell/backdoor as it's their obligation and I know for fact a lot of their IPMI was compromised. I want something nice for my sleepless nights and credit for all my findings, shared information.
Maybe also set a bios password so even if ipmi is compromised the attacker cannot change the boot order? Not sure if that would help since I don't provide server hosting so ignore if it doesn't.
Not really. They only single boot in linux kernel to change root pwd.
Would help if you encrypt the root drive.