I wish…

Nichts geht über große Zahlen, die hier zum Beispiel:

3028 marius 20 0 82,805g 197924 106164 S 3,0 1,2 1:24.88 /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 2 20
2505 marius 20 0 98,788g 129688 60080 S 2,6 0,8 1:08.40 liferea

Reine Fiktion, weil mein Rechner nur 16 GB RAM hat. Was soll der Unsinn und vorallem, für was würde Liferea 100 GB Ram brauchen können ?

Vorallem, das wächst nicht über die Zeit an, es wird gleich beim Start fällig :

19657 marius 20 0 98,601g 127636 58256 S 1,0 0,8 0:03.26 /usr/bin/liferea –gapplication-service

Mit „pmem 19657“ sieht man dann auch den Batzen an RAM, der für nichts bestimmtes allociert zu sein scheint. Naja, ich hab den Maintainer mal angemailt, da es ja kein „Problem“ mit dem VMem gibt, es kann meiner Meinung nach keine Absicht gewesen sein, soviel RAM benutzen zu wollen, für einen RSS Feedreader!

Supermicro IPMI mit Remote-Exploit < FW 3.8

Posted on by

WARNUNG: Wer einen SuperMicro Server betreibt und noch die IPMI Firmware < 3.80 betreibt und extern erreichbare IPs benutzt, wird bald unerwünschten Besuch erhalten!

CVE-2019-6260

In der 3.65 Version der Firmware ist eine Schwachstelle enthalten, über die Hacker Zugriff auf das System bekommen können. Ein sofortiges Update ist angeraten, aber vorher prüfen, ob Ihr nicht schon infiziert seid, weil sonst Beweise vernichtet werden.

Workaround: die IP auf eine lokale IP umstellen

$ ipmitool lan set 1 ipaddr 192.168.1.2
$ ipmitool lan set 1 ipsrc static

Static, damit sich das nicht per DHCP Update wieder umstellt! DHCP als DEFAULT für eine IPMI !!! unglaublich!

Wie kommt man darauf? Wenn man einen Anruf bekommt, daß das Cluster XZY plötzlich so langsam reagiert und ein XenServer Mensch da mal nachsehen soll. Warum war es langsam, weil da jemand BitCoin gemint hat, mit allen 52 Kernen 😀

Für den Fall, daß Euch das auch passiert, hier eine Checkliste:

CHECKLISTE

  1. last -ai
    Wenn im last-Output „tty“ als Konsole auftaucht, ohne IP, dann ist es die IPMI.
  2. /etc/passwdDie müßt Ihr auf einen weiteren Rootuser hin checken, also 0:0 als UID:GID. Wenn da, dann auch in der /etc/shadow löschen
  3. crontab -lPrüfen ob der Miner per Cron neugestartet wird.
  4. CronjobsPrüfen ob die Cronjobs unter /etc/cron* manipuliert oder welche hinzugefügt wurden.
  5. Verbindungen checkenmit „netstat -lnap| grep LISTEN“ prüfen ob da Dienste laufen, die da nicht hingehören.
    mit „netstat -lnap| grep VERBUNDEN“ prüfen, ob da grade aktiv was ausgeleitet wird.
  6. System überprüfen, z.b. „yum reinstall *“ um unveränderte Software zu bekommen, aber Vorsicht, daß kann auf einem Produktionssystem auch in die Hose gehen. Vielleicht weniger invasiv mal nach kürzlich geänderten Dateien suchen:find / -ctime -30
    find / -mtime -30

Im Beispiel sind es 30 Tage. Wenn man dann „verdächtige“ Files hat, kann man z.b. rpm -qf filename benutzen und sieht, ob die über das System kamen oder von Hand sind.

Kleines Update: „rpm -qa | awk ‚{print „rpm -V „$1;}‘ | bash“ sehr nützlich beim prüfen von korrekten Files.

WICHTIG: ERST MIT TAR ARCHIVIEREN, DANN LÖSCHEN! Gilt auch für Logfiles.

Link: https://nvd.nist.gov/vuln/detail/CVE-2019-6260