Onderwerp: SSHD Rootkit in omloop

Ik sluit me volledig aan bij Yourwebhoster. Dit is de meest logische verklaring, en zien we al jaren. Lijkt eerder een uitbreiding op het al bekende virus wat FTP / SMTP auth gegevens e.d. opvist. Lijkt erop dat er ook stukjes netwerk verkeer worden gelogd (wel mooi geschreven natuurlijk ) en daardoor ook direct met juiste poort wordt ingelogd.
Goede reden om de klant zonder VPN geen toegang meer te geven tot SSH.

Redhat heeft wel een update uitgebracht :

http://secunia.com/advisories/52312/

Red Hat has issued an update for openssh. This fixes a vulnerability, which can be exploited by malicious, local users to gain escalated privileges.

The vulnerability is caused due to the application calling the glibc "error()" function instead of the pam_ssh_agent_auth "error()" function and can be exploited to e.g. execute arbitrary code with root privileges.

De laatste update van csf:

5.79 - Modified csf error routine to store failing error in csf.error and
display an instructional message

Check for libkeyutils-1.2.so.2 in LF_EXPLOIT option SSHDSPAM

Modified the Server Report proxysubdomains check on cPanel servers

Added new options CC_DENY_PORTS, CC_DENY_PORTS_TCP,
CC_DENY_PORTS_UDP. This feature denies access from the countries
listed in CC_DENY_PORTS to listed TCP/UDP ports. For example, using
this FTP access port 21 could be blocked to only the specified
countries

Interessant. http://www.webhostingtalk.com/showpo...postcount=1117

Oorspronkelijk geplaatst door Zadmin

After really some helpful data from flopunctro I was able to gather some info that added up to what I have already here is what I got so far :

1-we are facing an advanced version of this exploit/patch :

Where the username/password is send hashes via UDP port 53 instantly (ONLY in case of password login not via pub/priv key)

UDP Packets sent look like this :

Code:

7741e5e70c67b9c0737dd0a1467fbec5557afbfc48.XX.XX.XX.XX.XX: type A, class IN

6214f8fc6a5ab0a13727c3a05658d9c9376ddba7537edee26aXX.XX.XX.XX.XX: type A, class IN

Where XX.XX.XX.XX.XX is the connecting IP

* That was root login btw if it may help anyone decoding the hash

2- This were inserted in openssh package includes.h

Code:

EXTLIB_KEY Kw4DC88AXa0yScbrMZsbb5WPa2M7Gptp
EXTLIB_FILE_NAME	 /tmp/.socks
SERVER	205.134.160.54 (Thats an Older version IP that was used)
super_password	XXXxCfWmZyl
super_password_pr_mask	XXXxCfWmZylXcat
super_password_ver_mask	XXXxCfWmZylXver
LCH_SUBSTR_1	*different*
LCH_SUBSTR_2	*fingerprint*
LCH_SUBSTR_3	*connecting*
LCH_SUBSTR_4	*authenticity*
LCH_SUBSTR_5	*Please type*
LCH_SUBSTR_6	abcdefghijklmnopqrstuvwxyz
LCH_SUBSTR_7	biz
LCH_SUBSTR_8	info
LCH_SUBSTR_9	net
LCH_SUBSTR_10	Version 0.4.4-5.5p1
LIB_LENGTH Guess_Length_Of_LCH_SUBSTR_10

which matches the strings pattern that was captured on they files found though they are not added in plain text rather obfuscated using xor like this :

Code:

#define EXTLIB_KEY {75,119,52,68,67,56,56,65,88,97,48,121,83,99,98,114,77,90,115,98,98,53,87,80,97,50,77,55,71,112,116,112,0}
#define EXTLIB_FILE_NAME {100,3,89,52,108,22,75,46,59,10,67,0}
#define SERVER {121,71,1,106,114,11,12,111,105,87,0,87,102,87,0}
#define super_password {19,47,108,60,0,94,111,44,2,24,92,0}
#define super_password_pr_mask {19,47,108,60,0,94,111,44,2,24,92,33,48,2,22,0}
#define super_password_ver_mask {19,47,108,60,0,94,111,44,2,24,92,33,37,6,16,0}
#define LCH_SUBSTR_1 {97,19,93,34,37,93,74,36,54,21,26,0}
#define LCH_SUBSTR_2 {97,17,93,42,36,93,74,49,42,8,94,13,121,0}
#define LCH_SUBSTR_3 {97,20,91,42,45,93,91,53,49,15,87,83,0}
#define LCH_SUBSTR_4 {97,22,65,48,43,93,86,53,49,2,89,13,42,73,0}
#define LCH_SUBSTR_5 {97,39,88,33,34,75,93,97,44,24,64,28,121,0}
#define LCH_SUBSTR_6 {42,21,87,32,38,94,95,41,49,11,91,21,62,13,13,2,60,40,0,22,23,67,32,40,24,72,0}
#define LCH_SUBSTR_7 {41,30,78,0}
#define LCH_SUBSTR_8 {34,25,82,43,0}
#define LCH_SUBSTR_9 {37,18,64,0}
#define LCH_SUBSTR_10 {29,18,70,55,42,87,86,97,104,79,4,87,103,78,87,92,120,42,66,0}
#define LIB_LENGTH {11,14,11,15,15,11,13,12,14,13,26,3,4,3,19,0}

here is the xor routine :

Code:

sub _xor{@Arr=split(//,$_[0]);@Key=split(//,$_[1]);$j=0; $keylen=scalar(@Key);for($i=0;$i<scalar(@Arr);$i++)
{$_[2][$i]=ord($Arr[$i])^ord($Key[$j]);$j++;$j=0 if($j>=$keylen);};};

3- This is not a privilege escalation exploit rather a "Maintaining access" exploit

4- Ips found associated with this so far if you want block/report them are :

Code:

205.134.160.54
124.224.178.154
15.229.164.97
178.162.248.74
188.165.129.30
218.94.149.83
250.159.28.33
46.105.108.166
46.105.20.166
5.199.133.226
72.156.139.154
78.47.139.110
86.35.214.22
87.230.54.65
94.23.23.153
94.23.72.193

5- the best route if you got this files reported is OS reload and force password changes afterwards as most if not all services login credentials are affected by this

6- it is suspected *till now* that super_password variable is used to spawn a reverse shell to attacker IP if he telnet to ssh port and pastes the super password though this has not been confirmed yet , hope somone can confirm/deny this .

* While in process of fixing you can prevent ongoing password leaks by prohibiting access to outgoing port 53 for only a predefined IP lets say google ns 8.8.8.8

Hope this helps anyone working on this .

Oorspronkelijk geplaatst door Bart L

Ik sluit me volledig aan bij Yourwebhoster. Dit is de meest logische verklaring, en zien we al jaren. Lijkt eerder een uitbreiding op het al bekende virus wat FTP / SMTP auth gegevens e.d. opvist. Lijkt erop dat er ook stukjes netwerk verkeer worden gelogd (wel mooi geschreven natuurlijk ) en daardoor ook direct met juiste poort wordt ingelogd.
Goede reden om de klant zonder VPN geen toegang meer te geven tot SSH.

Tja dan kunnen ze net zo goed ook vpn gegevens opvangen in hun exploit en heb je hetzelfde probleem of gewoon de server via de client benaderen.

Oorspronkelijk geplaatst door The-BosS

Tja dan kunnen ze net zo goed ook vpn gegevens opvangen in hun exploit en heb je hetzelfde probleem of gewoon de server via de client benaderen.

Dit script is gericht op de grootste doelgroep en slechts een beperkt aantal maken gebruik van VPN. Het zou dus zeker een extra beveiliging kunnen geven omdat externe servers proberen te connecten met je SSH van je servers (wat zonder VPN dus niet kan). Ook een jumphost zou in dit geval geïnfecteerd zijn maar vermoedelijk niet de servers waarmee verbonden zou worden vanaf de jumphost (tenzij dit een Windows machine is, ik ga er van uit dat het een Linux machine zal zijn).

Al met al het is geen echte beveiliging als iemand je specifiek wilt aanvallen maar tegen dit soort dingen ben je wel een stukje veiliger dan een normale setup.

Jammer dat ze op wht.com zoveel zitten te bashen.

Hier vind je een korte samenvatting van wat er op wht.com wordt besproken en een check voor je server
https://isc.sans.edu/diary/SSHD+root...the+wild/15229

Parallels heeft zojuist een Security Advisory verzonden:

SECURITY ADVISORY FOR LINUX-BASED SSHD-ENABLED SYSTEMS
Parallels Customer,
Please read this message in its entirety and take the recommended actions.
Situation
External: Recent reports indicate a vulnerability for SSHD-enabled systems. This issue is not related to Parallels products as all SSHD-enabled systems are at risk.

In de mail wordt gewezen op een KB artikel: http://kb.parallels.com/en/115589

Oorspronkelijk geplaatst door Yourwebhoster

Dit script is gericht op de grootste doelgroep en slechts een beperkt aantal maken gebruik van VPN. Het zou dus zeker een extra beveiliging kunnen geven omdat externe servers proberen te connecten met je SSH van je servers (wat zonder VPN dus niet kan). Ook een jumphost zou in dit geval geïnfecteerd zijn maar vermoedelijk niet de servers waarmee verbonden zou worden vanaf de jumphost (tenzij dit een Windows machine is, ik ga er van uit dat het een Linux machine zal zijn).

Al met al het is geen echte beveiliging als iemand je specifiek wilt aanvallen maar tegen dit soort dingen ben je wel een stukje veiliger dan een normale setup.

Jammer dat ze op wht.com zoveel zitten te bashen.

Tja en als iedereen een vpn begint te gebruiken passen ze hun exploits gewoon aan of open ze gewoon een reverse shell op de geinfecteerde client. Dat het in dit geval kan helpen is een feit, maar dan moet je je ook afvragen waarom het in de eerst plaats zo ver is kunnen komen.

No offense, maar heeft ook maar 1 iemand van de beetje ervaren hosters hier met dit probleem te maken gehad?

lol, ik denk niet dat je vraag -op deze manier- uitnodigt tot veel bekentenissen.

Even serieus, ook al ben je een ervaren hoster, een werkstation kan natuurlijk nog steeds besmet raken. Er zijn een hoop manieren om de risicovlakken te verminderen door te beschermen in lagen, maar niemand is 100% perfect veilig.
Er waren ook rapporten op het forum waarbij de hacker ingelogd had via de IP van het kantoor waar het besmette werkstation stond (veel geluk dan met je VPN setup)

Een ontdekking zoals deze rootkit die geplaatst wordt nadat ssh inloggevens worden verzonden geeft een goed signaal af om nog een keer goed je verdediging te bekijken. Bescherming is niet een definitieve oplossing, maar iets dat regelmatig dient te worden geinspecteerd en verbeterd.

Het antwoord op je vraag, nee, niet besmet.

Nou, ik bedoelde meer of iemand hier het überhaupt al is tegengekomen of het in de logs gezien heeft, of ie nu besmet is of niet. Hoeft niet eens aan de hoster te liggen tenslotte, maar kan ook een onvoorzichtige klant zijn op een dedi/colo bakkie of zo. Persoonlijk vind ik het allemaal een beetje veel poeha aangezien rootkits met vrijwel elke remote/local root exploit geinstalleerd kunnen worden.
'even' een libje vervangen is dan al zo oud als de weg naar Rome.

In het kader van de vele distributed brute force attacks die wij de laatste tijd zien, lijkt me dit vooralsnog meer een standaard security issue dan iets echt nieuws.

Dat servers die bv. even cpanel/da installeren en er verder een jaar niet meer naar omkijken op zo'n manier het haasje zijn kan ik me dan wel voorstellen.
Was alleen een beetje benieuwd of het ook voorkomt op servers bij mensen die de boel redelijk op orde hebben. (je weet wel, beetje de servers beveiligd, firewalletjes, ids, niet op de werkpc kloten met java, legale software gebruiken etc.)

Gisteren de scan gemaakt en gelukkig niets tegen gekomen.

Persoonlijk vind ik het allemaal een beetje veel poeha aangezien rootkits met vrijwel elke remote/local root exploit geinstalleerd kunnen worden.
'even' een libje vervangen is dan al zo oud als de weg naar Rome.

Als het een makelijke was dan was het draadje niet zolang op WHT.com

Oorspronkelijk geplaatst door 4service

Gisteren de scan gemaakt en gelukkig niets tegen gekomen.


Als het een makelijke was dan was het draadje niet zolang op WHT.com

Mja, zolang mensen niet weten wat de attack vector is kunnen draadjes erg lang worden natuurlijk. Als blijkt dat het puur komt door een root password te sniffen vanaf beheer pc's, dan is het zelfs niet meer echt een exploit te noemen, hooguit een doordacht opgezet libje, toch?