Discussione Chinese threat actors are mass-attacking SSH or Apache, in this guide we'll stop them (forever)

Stato
Discussione chiusa ad ulteriori risposte.

Netcat

Utente Jade
17 Gennaio 2022
455
129
334
691
Hi, my name is Wesker (aka Access Denied), and I'm the owner of a cheap and fast Romanian VPS. Kind of a good deal, but?

Despite my Network Rate is 125 MB/s, I often faced network resource loss, failures, SSH lockouts etc. I'm able to download 1 GB of data within seconds from that server, so why I faced all these problems? If you are controlling a WAN-exposed home server or an abroad VPS server, and you are facing my same problems, the reason is the following:

Chinese threat actors is the reason, and that's all. But how they do and why? These guys are targeting IoT exposed servers. For example, I found in my Apache logs traces of the well known Censys scanner, which performed an unauthorized scan on HTTP 80, and obviously, port 22 (SSHD). The result of these scans become public, and shared across other IoTs like ZoomEye, or Shodan. Chinese threat actors perform a mass-bulk download of IP addresses from these IoTs, then they look for known vulnerabilities on Apache 80/443, or just bruteforcing your SSH, to gain the complete control of your server. How to prevent that from happening?

Step 1. If you are using Apache just for sporadic/occasional tasks, just don't forgot it opened. Type "systemctl status service apache2" to see if the service it's active or not, then just type in "service apache2 stop" to shut it down. Apache is made in a way you have it automatically running upon system restart, so your server may expose it without your knowledge.

Step 2. If you truly need Apache to costantly run, ensure it's always updated to the latest version, do never use weak configurations, such as unsafe cgi scripts, and moreover, if you are incorporating a SQL database, watch out for SQL flaws, that could lead to complete database take over, and data leakage.

The most important part of a VPS server is SSH, since this service is "the door" to enter the system. Chinese cybercriminals are mass-bruteforcing this service, aggressively. By opening the "/var/log/auth.log", we can find all the attempts to gain access on SSH. My "auth.log" file presented thousands of failed username/pass combination from chinese IP addresses. Thank God, all these attempts will always fail (unless you are using weak login credential), but the real problem is, how truly stressful is for the Network Resources to tank all these tragicomic login requests?

Step 3. All we need to do, is to monitor the network for SSH requests. By typing "netstat -a" on our terminal, we can see all IP addresses who are connected to SSH, or probing it for login attempts. After recognizing your own IP address istance in the netstat table, all others IP addresses are obviously bruteforcers. Surf to "etc/hosts.deny", then vim the hosts.deny file and copy/paste the IP address value of the attacker, in this format "sshd : ip_of_the_attacker", save, and the IP address is blocked. Each criminal IP must be copy/pasted into the "hosts.deny" file individually. Another technique, which is risky, is to prevent all IP addresses from contacting the SSH service except your, which may lock you out whatever your home-network IP is dynamic and not static. After blocking each bruteforcer's IP, open an account on www.abuseipdb.com, a webservice widely known among the white hat/grey hat community, and report the bruteforcer IP, like in this example, "https://www.abuseipdb.com/check/36.110.138.149" where 36.110.138.149 was reported 740 times for unauthorized bruteforce login attempts against SSH, from 348 distinct sources. Reporting these trolls in this blacklist will consume their web-reputation over time, thus popular websites like Google will prevent them from crawling the Internet for scraping data, IoT search engines will prevent them from accessing sensitive data, email spam filters will filter out these IPs whatever they will carry phishing artifacts, and eventually, popular EDRs automatically recognizing their IP as malicious.
 
  • Mi piace
Reazioni: TheWorm91
Ultima modifica:
Ciao @Access Denied, tieni conto che la maggior parte degli attaccanti che compiono azioni di questo tipo camuffano il loro IP reale con uno fornito da VPN o proxy. Non hai alcuna garanzia che quegli attacchi provengano effettivamente dalla Cina. Il primo consiglio sarebbe quello di disattivare il server quando non lo si utilizza? Stai dicendo che tenendo il server offline per più tempo abbiamo meno possibilità di essere attaccati? Non ci saremmo mai arrivati...🙃😁
 
Ciao @Access Denied, tieni conto che la maggior parte degli attaccanti che compiono azioni di questo tipo camuffano il loro IP reale con uno fornito da VPN o proxy. Non hai alcuna garanzia che quegli attacchi provengano effettivamente dalla Cina. Il primo consiglio sarebbe quello di disattivare il server quando non lo si utilizza? In tal modo è esposto per meno tempo e, quindi, meno soggetto ad attacchi...mi sembra un'ovvietà...🙃😉
Looking at Shodan https://www.shodan.io/host/36.110.138.149, this guy looks like another VPS server, not a VPN... Shodan would have it marked with the tag "vpn". I see he has SSH, he has Apache HTTP 80 opened, and port 50050 opened with an unknown service listening (probably a RAT). This guy could be a state-sponsored hacker, or it's just a pwned VPS controlled against owner's consent.
 
Ultima modifica:
his guy could be a state-sponsored hacker
Per colpire una VPS romena senza alcun dato importante per il governo? Non credo, mirano più in alto. Certo, c'è la possibilità che un governo assoldi cybercriminali per la costruzione magari di una botnet, finalizzata ad altri scopi.
he has Apache HTTP 80 opened
La porta è aperta, ma il server non è disponibile. Questo potrebbe avvalorare la seconda ipotesi, ossia che si tratti di una VPS compromessa. Forse il proprietario, prima che venisse attaccato, aveva hostato un sito http sulla VPS sulla porta 80? Potrebbe essere...

or it's just a pwned VPS
Ipotesi molto più probabile, a mio avviso. In ogni caso, potrebbe essere tutto e niente, stando così le cose: è inutile discutere di cosa può o non può essere, senza poterlo dimostrare, a meno di compromettere quel nodo malevolo...:asd:

Inoltre, ho dato un'occhiata alla versione OpenSSH utilizzata (8.4p1) ed ho scoperto l'esistenza di due vulnerabilità particolarmente rischiose, che sono state patchate se non erro, le quali potrebbero essere state sfruttate al momento dell'attacco (prima che venissero patchate ovviamente):
- CVE-2023-38408
- CVE-2021-28041
Da notare, in particolare, che la prima è una RCE, quindi stiamo parlando di una falla bella grossa. :asd:
 
  • Mi piace
Reazioni: TheWorm91
Ultima modifica:
Per colpire una VPS romena senza alcun dato importante per il governo? Non credo, mirano più in alto. Certo, c'è la possibilità che un governo assoldi cybercriminali per la costruzione magari di una botnet, finalizzata ad altri scopi.

La porta è aperta, ma il server non è disponibile. Questo potrebbe avvalorare la seconda ipotesi, ossia che si tratti di una VPS compromessa. Forse il proprietario, prima che venisse attaccato, aveva hostato un sito http sulla VPS sulla porta 80? Potrebbe essere...


Ipotesi molto più probabile, a mio avviso. In ogni caso, potrebbe essere tutto e niente, stando così le cose: è inutile discutere di cosa può o non può essere, senza poterlo dimostrare, a meno di compromettere quel nodo malevolo...:asd:
He's running Debian, as Shodan stated. I'm highly suspecting this is a pwned device, since Debian is an uncommon choice to setup a server... Noobs often go for Ubuntu, not Debian. Also, Debian is well known to be less affected by bugs, flaws and vulnerabilities... Famous distribution "Kali Linux" for pentesting is based on Debian as well...
Messaggio unito automaticamente:

Per colpire una VPS romena senza alcun dato importante per il governo? Non credo, mirano più in alto. Certo, c'è la possibilità che un governo assoldi cybercriminali per la costruzione magari di una botnet, finalizzata ad altri scopi.

La porta è aperta, ma il server non è disponibile. Questo potrebbe avvalorare la seconda ipotesi, ossia che si tratti di una VPS compromessa. Forse il proprietario, prima che venisse attaccato, aveva hostato un sito http sulla VPS sulla porta 80? Potrebbe essere...


Ipotesi molto più probabile, a mio avviso. In ogni caso, potrebbe essere tutto e niente, stando così le cose: è inutile discutere di cosa può o non può essere, senza poterlo dimostrare, a meno di compromettere quel nodo malevolo...:asd:

Inoltre, ho dato un'occhiata alla versione OpenSSH utilizzata (8.4p1) ed ho scoperto l'esistenza di due vulnerabilità particolarmente rischiose, che sono state patchate se non erro, le quali potrebbero essere state sfruttate al momento dell'attacco (prima che venissero patchate ovviamente):
- CVE-2023-38408
- CVE-2021-28041
Da notare, in particolare, che la prima è una RCE, quindi stiamo parlando di una falla bella grossa. :asd:
He has CVE-2023-38408 and Shodan tells nothing? Hell, guys.
 
Stato
Discussione chiusa ad ulteriori risposte.