Détecter faille permettant hack

Alors, j'ai eu récemment chez 2 clients qui ne maintenaient pas convenablement leur spip...
Première chose à faire :
- vérifier les crons, sur l'un de mes serveurs l'attaquant à mit un script dans les crons de l'user pour relancer ses merdes au reboot.
- Faire le ménage dans le site spip, essayer de trouver des fichiers qui n'ont rien à faire là, etc...
- Dans /tmp le ménage est fait à chaque reboot, donc le + simple, restart...
- Bien évidemment, mettre à jour totalement les sites sous SPIP.... Je ne fais pas, mais je peux recommander un presta dont spip est le coeur de métier (c'est pas gratuit je précise)...

Je n'ai pas les compétences en spip pour dire quelle est la faille qui a été utilisée, tt ce que je peux confirmer c'est que les sites patchés et vérifié par le presta dont je parle + haut n'ont plus été attaqué ensuite...
SPIP est très rarement attaqué, mais comme tout CMS il faut le tenir à jour...

C'est gentil d'avoir pris le temps de me répondre. Mais en fait, la réponse est un peu à coté de la question.
La question n'est pas : que faire si SPIP est le fautif ?
Mais : SPIP est-il le fautif ? Sinon qui ?

En effet, trouver un fichier qui n'a rien à faire dans SPIP, je l'ai fait, et je l'ai indiqué. MAIS, ça ne me garantie pas du tout que l'attaque provienne de là, d'autant que, comme je l'ai indiqué, ce script n'est selon moi un danger que s'il est lancé en root, ce qui n'est pas le cas ici.
Si j'avais la certitude que seul SPIP était en cause, sa mise à jour, comme je l'ai dit, voire sa suppression au pire, réglerait le problème, mais ce n'est pas le cas ici.
Si je relance le serveur, et que la faille n'est pas SPIP, le problème se reproduira inexorablement.
C'est l'autre découverte dans /var/tmp qui est plus inquiétante (que tu as l'air de confondre avec /tmp). Et supprimer tout ça n'est évidemment pas compliqué, mais ça ne sert à rien si on ne bouche pas la faille.
Faire appel à un prestataire n'est pas envisageable, parce que 1) le site sous SPIP est un site pour mon frère, pour ses besoins persos, sans aucune rémunération et surtout 2) s'il se contente de mettre à jour SPIP, je sais faire, mais comme expliqué, pour l'instant ça ne m'apporte aucune garantie.

Le support que j'avais sollicité à ce sujet m'a répondu parefeu, à croire qu'ils n'a absolument rien lu de ma demande. Il y a déjà un parefeu, mais il ne peut servir à rien dans cette situation. Je ne vais pas fermer l'accès http... Je crois que j'aurais préféré qu'ils me disent que ce n'est pas leur problème plutôt que de me répondre n'importe quoi.

Alors j'ai répondu :
> Je n'ai pas les compétences en spip pour dire quelle est la faille qui a été utilisée, tt ce que je peux confirmer c'est que les sites patchés et vérifié par le presta dont je parle + haut n'ont plus été attaqué ensuite...

Les fichiers installé font tourner un module crypto qui va utiliser le cpu (ceux dans /var/tmp ou /tmp au choix, j'ai eu les 2 perso). Il y a probablement également d'autres merdes qui vont faire des attaques sur d'autres serveurs...

Et oui le parefeu peut être utile, en empêchant le serveur d'effectuer des requêtes sortantes vers d'autres serveurs / services sans que cela ne soit autorisé...
Sauf que la plupart des parefeu sont configurés en "allow all" en sortie... Mais on peut tout à fait le configurer pour limiter les connexions sortantes également...

Oui, pour le parefeu, à part qu'empêcher des requête sortantes sur le port 80, autant arrêter le serveur.
J'ai un parefeu, complété d'un fail2ban parfaitement configurés et très restrictifs, mais ça a ses limites, ici justement.
L'important pour moi est toujours de savoir comment il est entré, pas de le supprimer, ni de l'empêcher de communiquer.

Sachant que je ne sais toujours pas si les 2 éléments trouvés sont liés ou pas, mais 2 en 2 jours, ça laisse peu de place à la coïncidence, même si je ne vois vraiment aucun rapport entre les 2.
J'ai enfin trouvé une référence à l'un des 2 https://www.reddit.com/r/linuxquestions/comments/56mqcn/what_kind_of_compromise_do_i_have_here/ https://www.reddit.com/r/linuxquestions/comments/56mqcn/what_kind_of_compromise_do_i_have_here/ mais malheureusement, je ne vois rien dans les réponses qui puisse m'éclairer.

Il en est également question ici http://www.stxletto.com/posts/%E5%85%B3%E4%BA%8E%E4%B8%80%E5%AE%97%E9%97%A8%E7%BD%97%E5%B8%81%E6%8C%96%E7%9F%BF%E5%AE%89%E5%85%A8%E4%BA%8B%E4%BB%B6%E7%9A%84%E5%88%86%E6%9E%90%E6%8A%A5%E5%91%8A/ http://www.stxletto.com/posts/%E5%85%B3%E4%BA%8E%E4%B8%80%E5%AE%97%E9%97%A8%E7%BD%97%E5%B8%81%E6%8C%96%E7%9F%BF%E5%AE%89%E5%85%A8%E4%BA%8B%E4%BB%B6%E7%9A%84%E5%88%86%E6%9E%90%E6%8A%A5%E5%91%8A/ mais la langue...

Il y a ça aussi :

https://discuter.spip.net/t/alerte-vague-de-piratage-de-sites-depuis-le-23-avril-pas-d-acces-a-ecrire-version-spip-inferieures-a-3-2-18-4-1-8-et-4-2-1/169042/21

Ah voilà une excellente piste !
Merci beaucoup.
J'ai tellement de mal à trouver des requêtes viables tellement les noms sont communs.
Ça aurait donc ici rapport avec SPIP.

Mais ça n'aurait bien aucun rapport avec l'autre élément (dans /var/tmp) qui, après investigations incessantes, aurait lui été installé depuis le 20/05, mais rendu actif uniquement depuis le 25/06.

Je continue mes recherches.
En tout cas, merci pour ton aide.

Bonjour,

Dans votre premier message le mec fait une attaque UDP depuis le port 39126 donc oui un firewall qui n'autorise que les ports nécessaires en sortie aurais pu vous éviter ça.

Sinon pas besoin d'être root pour lancer ce genre d'attaque.

Cordialement, janus57

Certes, mais c'est le port source. Vous limitez les ports source sur votre firewall vous ? Moi je ne l'ai jamais fait, je l'avoue. Je me suis toujours contenté des ports destination.

Et pour le lancement de l'attaque en root. J'ai dit que le script en question ne fait que (il me semble) des choses possibles en root sur mon system.
Ex : chmod +x /etc/init.d/network
Je n'ai pas dit que l'attaque ne pouvait pas avoir lieu sans être root, d'autant que j'en ai la preuve dans mon cas.

Bonjour,

Certes, mais c'est le port source. Vous limitez les ports source sur votre firewall vous ? Moi je ne l'ai jamais fait, je l'avoue. Je me suis toujours contenté des ports destination.

en entreprise on utilise un firewall centrale et on ouvre les ports de destination à la demande.
Sur un serveur web typiquement on va autoriser le 80 et 443 en TCP uniquement et on va faire un rejet sur les connexion UDP (si le client ne sait pas nous dire les destinations que le serveur va avoir besoin de taper), et oui on s'en fou (pour le moment) ci cela casse le HTTPS en UDP.
Si le client nous indique une liste d'adresse on fait en plus un filtrage sur les FQDN (genre on va autoriser les dépôts debian, google pour le recaptcha, les CDN etc.)

J'ai dit que le script en question ne fait que (il me semble) des choses possibles en root sur mon system.

n'ayant pas vu le script, impossible à dire surtout que le script pourrais très bien faire appel a une faille pour faire une élévation de privilège (si l'OS lui était pas à jour).

Cordialement, janus57

en entreprise on utilise un firewall centrale et on ouvre les ports de destination à la demande.

C'est bien ce que je dis, le port de destination, qui là était le port 80. Vous vous voyez bloquer le port 80 en destination d'un serveur http ?
Avant ça, ce dont vous parliez, c'était le port source. Vous avez complètement changez de discours du coup.
Notez qu'ici, on parle toujours de connexion sortante hein...

Sur un serveur web typiquement on va autoriser le 80 et 443 en TCP uniquement et on va faire un rejet sur les connexion UDP (si le client ne sait pas nous dire les destinations que le serveur va avoir besoin de taper), et oui on s'en fou (pour le moment) ci cela casse le HTTPS en UDP.
Si le client nous indique une liste d'adresse on fait en plus un filtrage sur les FQDN (genre on va autoriser les dépôts debian, google pour le recaptcha, les CDN etc.)

Et ici vous parlez maintenant des connexions rentrantes. Mais c'est complètement hors sujet ici. On parlait de l'attaque de mon serveur vers X, c'est une connexion sortante. C'est vous-même qui êtes revenu sur ce sujet en reprenant la ligne de mon premier post.



Alors, revenons à ce que nous disions, vous me préconisez quoi en la matière ?

n'ayant pas vu le script, impossible à dire surtout que le script pourrais très bien faire appel a une faille pour faire une élévation de privilège (si l'OS lui était pas à jour).

impossible à dire pour vous, mais moi, je l'ai vu le script.
Quant à l'OS, il est toujours à jour chez moi.

Bonjour,

Avant ça, ce dont vous parliez, c'était le port source. Vous avez complètement changez de discours du coup.

non car le parler du port source ET du protocole.

Dans votre premier message le mec fait une **attaque UDP** depuis le port 39126

Et ici vous parlez maintenant des connexions rentrantes.

non encore une fois que parle des sortantes, pour ça que ensuite je dit qu'on filtre sur du FQDN quand le client nous les donnes.
Le but étant que le serveur web ne puisse initier une connexion que vers des destination connues.
Et sinon oui en entrant on fait la même chose sans la restriction FQDN.

Alors, revenons à ce que nous disions, vous me préconisez quoi en la matière ?

ce que j'ai dit :

Sur un serveur web typiquement on va autoriser le 80 et 443 en TCP uniquement

De base un serveur web n'a pas à faire de l'UDP* en sortie.

impossible à dire pour vous, mais moi, je l'ai vu le script.
Quant à l'OS, il est toujours à jour chez moi.

comment on est censé le savoir si vous l'avez pas dit (pour OS à jour) et montrer (pour le script).

Bref je vais m'arrêter là vu que visiblement vous m'avez pris en grippe et je suis pas là pour ça.
Je vous laisse voir avec @Sich

*sauf si vous voulez absolument utiliser HTTP/3 sur une connexion initié.

Cordialement, janus57

Certes, mais c'est le port source. Vous limitez les ports source sur votre firewall vous ? Moi je ne l'ai jamais fait, je l'avoue. Je me suis toujours contenté des ports destination.

Je ne le fais pas non plus, mais ça fait parti des "bonnes pratiques" qu'il faudrait appliquer.
C'est à dire filtrer également en sortie, voir n'autoriser que certains hôtes distants (repos debian par exemple).
Et en effet, ça permet d'éviter qu'un attaquant qui installe une backdoor sur un serveur puisse ensuite dl une liste de script, voir attaquer des serveurs distants.

C'est clairement une chose sur laquelle je vais devoir me pencher sérieusement également... Mais c'est très pénible à déployer au vu de la variété de config que je dois gérer...

Je ne le fais pas non plus, mais ça fait parti des "bonnes pratiques" qu'il faudrait appliquer.

Je le faisais avant. Mais c'est super contraignant, et j'avais jugé, à tort peut-être, que ça n'était pas forcément utile sur ce serveur d'une activité particulièrement modeste.

C'est à dire filtrer également en sortie, voir n'autoriser que certains hôtes distants (repos debian par exemple).

Je le fais pour certaines choses, mais je ne l'ai pas étendu à tout.

Et en effet, ça permet d'éviter qu'un attaquant qui installe une backdoor sur un serveur puisse ensuite dl une liste de script, voir attaquer des serveurs distants.

Oui, sauf s'il le fait sur un port que tu as forcément ouvert, ex 80.

C'est clairement une chose sur laquelle je vais devoir me pencher sérieusement également... Mais c'est très pénible à déployer au vu de la variété de config que je dois gérer...

C'est pénible oui, forcément.
D'ailleurs, après avoir tenté de nettoyer mon serveur de ce qui me semblait "frauduleux", mis en place quelques protections comme le blocage de la création de crontab pour n'importe quel user, et différentes bricoles, et en rajoutant quelques supervisions, j'ai fini par relancer le serveur (*), j'ai mis à jour spip, en rajoutant le fameux "écran de sécurité".
Je tente donc maintenant de limiter les connexions sortantes à ce dont j'ai strictement besoin, mais l'usage du serveur n'est pas que web, donc c'est un peu large.
Maintenant, je regarde ce qui est bloqué en sortie, et ce que je vois ne me parle pas du tout. Je ne sais pas si je bloque un truc légitime, en ne sachant pas lequel, ou si mon serveur est toujours compromis avec un élément caché qui tente de communiquer avec l'extérieur.
J'aimerais l'avis des spécialistes.
Quelques exemples (ici unique mais présents en plusieurs exemplaires) :

IN= OUT=eth0 SRC=myip DST=217.182.134.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=60602 WINDOW=0 RES=0x00 RST URGP=0
IN= OUT=eth0 SRC=myip DST=2.57.122.71 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=57555 WINDOW=0 RES=0x00 RST URGP=0
IN= OUT=eth0 SRC=myip DST=2.57.122.71 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=56758 WINDOW=0 RES=0x00 RST URGP=0


sachant que ce serveur fait, entre autre, web mais aussi MX backup.
Je ne trouve rien en crontab aux horaires correspondants à ces lignes, et aucun processus en cours qui me semble suspicieux.

Merci d'avance.

(*) inutile de me dire que l'idéal est de réinstaller le serveur, je le sais, mais avec ma connexion faiblarde, c'est très compliqué de tout rapatrier pour tout remettre ensuite, et je n'ai pas plusieurs serveurs distants à dispo

IN= OUT=eth0 SRC=myip DST=217.182.134.106 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=60602 WINDOW=0 RES=0x00 RST URGP=0

Le serveur distant est un serveur ovh, mais c'est peut être simplement qu'il répond à une requête distante sur le port 80... (spt 80), il faudrait voir si l'ip apparait dans les logs apache.

IN= OUT=eth0 SRC=myip DST=2.57.122.71 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=57555 WINDOW=0 RES=0x00 RST URGP=0
IN= OUT=eth0 SRC=myip DST=2.57.122.71 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=56758 WINDOW=0 RES=0x00 RST URGP=0

Idem ici, SPT 80 et 443, IP Chinoise par contre...
Normalement en cas de connexion TCP la réponse ne devrait pas être bloquée vu que c'est l'hôte distant qui initie la connexion sur le 80/443 qui est autorisé...
Mais il faut vérifier les logs web et faire des tests en visitant les sites depuis une IP non whitelistée.

(*) inutile de me dire que l'idéal est de réinstaller le serveur, je le sais, mais avec ma connexion faiblarde, c'est très compliqué de tout rapatrier pour tout remettre ensuite, et je n'ai pas plusieurs serveurs distants à dispo

Il faut louer une instance PCI à l'heure éventuellement.
Mais ça ne sert à rien de réinstaller si les failles sont tjrs présentes.

Le serveur distant est un serveur ovh, mais c'est peut être simplement qu'il répond à une requête distante sur le port 80... (spt 80), il faudrait voir si l'ip apparait dans les logs apache.

Tu me fais peur là.
On est sur des connexions NEW, pas ESTABLISHED. On n'est pas sur des réponses à des requetes.
Sinon, mon serveur web ne répondrait plus du tout à rien. Ce qui n'est pas le cas.
Et si je dois ouvrir tout ce qui est SPT=80, alors ça revient à ce que j'ai dit dès le départ, en aucune manière ça ne pourra bloquer le résultat de l'attaque en question dans mon premier message. Et dans ce cas, bloquer les connexions sortantes n'a plus aucun intérêt.

Mais ça ne sert à rien de réinstaller si les failles sont tjrs présentes.

Absolument.

Il faut louer une instance PCI à l'heure éventuellement.

Je ne connais pas, mais me renseignerai le cas échéant.

Hum du new sur un port distant comme ça ce n'est pas normal en effet... Surtout pour contacter un autre serveur...

Pour le PCI voir ici : https://www.ovhcloud.com/fr/public-cloud/prices/

Pratique pour du test ou de l'instance temporaire.
Pas top en prod permanente je trouve.

Hum du new sur un port distant comme ça ce n'est pas normal en effet... Surtout pour contacter un autre serveur...

J'avoue très humblement que tout ça me dépasse complètement..
Je confirme qu'elles correspondent à des connexions établies repérées dans les logs. Ce que je ne comprends pas, c'est leur légitimité, d'autant que le service est toujours fourni, malgré le blocage de ces connexions.
Ce matin, j'avais le même genre de requêtes sortantes bloquées, avec un SPT=25, vers une IP effectivement trouvée dans les logs postfix.

Parefeu :

DST=147.78.103.204 LEN=91 PROTO=TCP SPT=25 DPT=37662 WINDOW=502 ACK PSH FIN URGP=0
DST=147.78.103.204 LEN=91 PROTO=TCP SPT=25 DPT=37662 WINDOW=502 ACK PSH URGP=0
DST=147.78.103.204 LEN=91 PROTO=TCP SPT=25 DPT=41518 WINDOW=502 ACK PSH FIN URGP=0
DST=147.78.103.204 LEN=91 PROTO=TCP SPT=25 DPT=41518 WINDOW=502 ACK PSH URGP=0

Postfix :

Jul 5 12:03:42 monserveur postfix/smtpd[10204]: connect from unknown[147.78.103.204]
Jul 5 12:03:42 monserveur postfix/smtpd[10204]: lost connection after CONNECT from unknown[147.78.103.204]
Jul 5 12:03:42 monserveur postfix/smtpd[10204]: disconnect from unknown[147.78.103.204] commands=0/0
Jul 5 12:03:47 monserveur postfix/smtpd[10204]: connect from unknown[147.78.103.204]
Jul 5 12:03:47 monserveur postfix/smtpd[10204]: NOQUEUE: reject: RCPT from unknown[147.78.103.204]: 554 5.7.1 outlook.com>: Relay access denied; from= to=outlook.com> proto=SMTP helo=
Jul 5 12:03:47 monserveur postfix/smtpd[10204]: using backwards-compatible default setting smtpd_relay_before_recipient_restrictions=no to reject recipient "ramseywhale@outlook.com" from client "unknown[147.78.103.204]"
Jul 5 12:03:53 monserveur postfix/smtpd[10207]: connect from unknown[147.78.103.204]
Jul 5 12:04:08 monserveur postfix/smtpd[10215]: connect from unknown[147.78.103.204]
Jul 5 12:04:10 monserveur postfix/smtpd[10204]: lost connection after RCPT from unknown[147.78.103.204]
Jul 5 12:04:10 monserveur postfix/smtpd[10204]: disconnect from unknown[147.78.103.204] helo=1 mail=1 rcpt=0/1 commands=2/3
Jul 5 12:08:54 monserveur postfix/smtpd[10207]: timeout after EHLO from unknown[147.78.103.204]
Jul 5 12:08:54 monserveur postfix/smtpd[10207]: disconnect from unknown[147.78.103.204] ehlo=1 commands=1
Jul 5 12:09:08 monserveur postfix/smtpd[10215]: timeout after EHLO from unknown[147.78.103.204]
Jul 5 12:09:08 monserveur postfix/smtpd[10215]: disconnect from unknown[147.78.103.204] ehlo=1 commands=1

Pour le PCI voir ici : https://www.ovhcloud.com/fr/public-cloud/prices/

Pratique pour du test ou de l'instance temporaire.

Ah oui, pas mal du tout ça. Effectivement, ça peut tout à fait répondre à mon besoin ponctuel si je dois en arriver là, voire même pour une autre situation comparable. Merci !

Pas top en prod permanente je trouve.

Tu m'étonnes :D