Request "Under Attack by Slyslanting Fox! We Need Your Help!"

[kocero64]

Hello friends,

For the past week, we've been getting hacked by someone named "Slyslanting Fox." As you can see in the image, they are deleting our load balancers and renaming the main server with names like the one shown in the image. When we contacted them via Telegram, they said they would tell us how to fix the vulnerability in the panel for 500 euros. If anyone knowledgeable about this issue can help, we would greatly appreciate it.

 

[ddart00]

Hello friends,

For the past week, we've been getting hacked by someone named "Slyslanting Fox." As you can see in the image, they are deleting our load balancers and renaming the main server with names like the one shown in the image. When we contacted them via Telegram, they said they would tell us how to fix the vulnerability in the panel for 500 euros. If anyone knowledgeable about this issue can help, we would greatly appreciate it.

View attachment 5674

There is a fix/patch for that hack released by a developer of xui. Do some search in the forum (or internet). After the patch, they wont be able to hack you anymore.

 

[julian]

There is a fix/patch for that hack released by a developer of xui. Do some search in the forum (or internet). After the patch, they wont be able to hack you anymore.

Hello friends,

For the past week, we've been getting hacked by someone named "Slyslanting Fox." As you can see in the image, they are deleting our load balancers and renaming the main server with names like the one shown in the image. When we contacted them via Telegram, they said they would tell us how to fix the vulnerability in the panel for 500 euros. If anyone knowledgeable about this issue can help, we would greatly appreciate it.

View attachment 5674

There is a fix/patch for that hack released by a developer of xui. Do some search in the forum (or internet). After the patch, they wont be able to hack you

There is a fix/patch for that hack released by a developer of xui. Do some search in the forum (or internet). After the patch, they wont be able to hack you anymore.

He is already on 1.5.13, it shows in the picture. Did the original poster change the streaming key after updating the panel to latest version?

 

[kocero64]

He is already on 1.5.13, it shows in the picture. Did the original poster change the streaming key after updating the panel to latest version?

Yes, I am using the original new version, bro, but whoever this hacker is, they keep managing to access the main server. And as you said, I couldn't find any fix/patch anywhere.

 

[redhat]

May there is a different vulnerability.
You should get in contact with @GTAXUI

 

[kocero64]

May there is a different vulnerability.
You should get in contact with @GTAXUI

Ok admin, thank you for your help.

 

[GTAXUI]

He is already on 1.5.13, it shows in the picture. Did the original poster change the streaming key after updating the panel to latest version?

He was on 1.5.5 when he was initially hacked then upgraded to 1.5.13. I've had contact with SlySlantingFox who has stated that the fix I provided for 1.5.13 did work and that was the method he was using to get in, however he's pretty switched on so when he does get in he finds a way to stick around...

Realistically you're still safe on 1.5.13, but if he had hacked you on a prior version then there's no guarantees at all. But I released the fix months ago, you all should have upgraded by now.

 

[redhat]

He was on 1.5.5 when he was initially hacked then upgraded to 1.5.13. I've had contact with SlySlantingFox who has stated that the fix I provided for 1.5.13 did work and that was the method he was using to get in, however he's pretty switched on so when he does get in he finds a way to stick around...

Realistically you're still safe on 1.5.13, but if he had hacked you on a prior version then there's no guarantees at all. But I released the fix months ago, you all should have upgraded by now.

Thanks for the clarification mate

 

[kocero64]

He was on 1.5.5 when he was initially hacked then upgraded to 1.5.13. I've had contact with SlySlantingFox who has stated that the fix I provided for 1.5.13 did work and that was the method he was using to get in, however he's pretty switched on so when he does get in he finds a way to stick around...

Realistically you're still safe on 1.5.13, but if he had hacked you on a prior version then there's no guarantees at all. But I released the fix months ago, you all should have upgraded by now.

So far so good, thank you very much Gta

 

[netteflix]

1.5.13 has just been hacked.

 

[gzowner]

1.5.13 has just been hacked.

View attachment 5678

had to be something else and never changed the information. sometimes its best to go through your admin accounts to see if their anything changed, and update your passwords.

 

[redhat]

Some TIPS to secure your server:

1. Perform a new installation of xui.one v1.5.13 on your MAIN and all LB's
2. Regenerate a your Admin Access Code, delete all unnecessary access codes like reseller, MAG if you not use them.
3. Restrict your API Services
4. Upgrade the Redis latest version on your Main Server (the v4.x Redis Server has Vulnerabilities)
5. Upgrade your OpenSSH server on your Main Server and LB's

Build Redis from Source (Latest Version) >> only required if you realy activated and use Redis Connection Handler

1. Find the Redis Process
   
   

   ps aux | grep redis

   
   You should see a line like this:
   
   

   xui      1234  0.5  0.3  56789 12345 ? Ssl  12:34   0:05 /home/xui/bin/redis/redis-server 127.0.0.1:6379

   The 1234 in this example is the process ID (PID).
   
   
2. Kill the Redis Process
   
   

   kill -9 1234

   or stop it with:
   

   pkill redis-server

   
   
3. Backup the Old Redis
   
   

   mv /home/xui/bin/redis/redis-server /home/xui/bin/redis/redis-server.old

   
   
4. Install dependencies
   
   

   sudo apt update
   sudo apt install -y build-essential tcl

   
   
5. Download and compile the latest Redis
   
   

   wget [URL]http://download.redis.io/redis-stable.tar.gz[/URL]
   tar xzvf redis-stable.tar.gz
   cd redis-stable
   make -j$(nproc)
   sudo make install

   
   
6. Check if the Compilation Was Successful
   
   

   src/redis-server --version

   
   
7. Replace the Old Redis Binary
   
   

   cp src/redis-server /home/xui/bin/redis/

   
   
8. Verify the new binary
   
   

   /home/xui/bin/redis/redis-server --version

   
   
9. Uncomment the server-threads and server-thread-affinity Directive in redis.conf (directives is not supported in Redis 7.4.2)
   
   

   nano /home/xui/bin/redis/redis.conf

   
   Comment them out:
   

   # server-threads 4
   # server-thread-affinity true

   
   
10. Start Redis using the updated binary
    
    

    /home/xui/bin/redis/redis-server /home/xui/bin/redis/redis.conf

Build OpenSSH from Source (Latest Version)​

1. Install dependencies
   
   

   sudo apt update
   sudo apt install -y build-essential zlib1g-dev libssl-dev libpam0g-dev

   
   
2. Download and compile the latest OpenSSH
   
   

   wget [URL]https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz[/URL]
   tar -xzf openssh-9.7p1.tar.gz
   cd openssh-9.7p1
   ./configure --prefix=/usr --sysconfdir=/etc/ssh
   make -j$(nproc)
   sudo make install

   
   
3. Restart OpenSSH
   
   

   sudo systemctl restart ssh

 

[julian]

Some TIPS to secure your server:

1. Perform a new installation of xui.one v1.5.13 on your MAIN and all LB's
2. Regenerate a your Admin Access Code, delete all unnecessary access codes like reseller, MAG if you not use them.
3. Restrict your API Services
4. Upgrade the Redis latest version on your Main Server (the v4.x Redis Server has Vulnerabilities)
5. Upgrade your OpenSSH server on your Main Server and LB's

Build Redis from Source (Latest Version) >> only required if you realy activated and use Redis Connection Handler

1. Find the Redis Process
   
   

   ps aux | grep redis

   
   You should see a line like this:
   
   

   xui      1234  0.5  0.3  56789 12345 ? Ssl  12:34   0:05 /home/xui/bin/redis/redis-server 127.0.0.1:6379

   The 1234 in this example is the process ID (PID).
   
   
2. Kill the Redis Process
   
   

   kill -9 1234

   or stop it with:
   

   pkill redis-server

   
   
3. Backup the Old Redis
   
   

   mv /home/xui/bin/redis/redis-server /home/xui/bin/redis/redis-server.old

   
   
4. Install dependencies
   
   

   sudo apt update
   sudo apt install -y build-essential tcl

   
   
5. Download and compile the latest Redis
   
   

   wget http://download.redis.io/redis-stable.tar.gz
   tar xzvf redis-stable.tar.gz
   cd redis-stable
   make -j$(nproc)
   sudo make install

   
   
6. Check if the Compilation Was Successful
   
   

   src/redis-server --version

   
   
7. Replace the Old Redis Binary
   
   

   cp src/redis-server /home/xui/bin/redis/

   
   
8. Verify the new binary
   
   

   /home/xui/bin/redis/redis-server --version

   
   
9. Uncomment the server-threads and server-thread-affinity Directive in redis.conf (directives is not supported in Redis 7.4.2)
   
   

   nano /home/xui/bin/redis/redis.conf

   
   Comment them out:
   

   # server-threads 4
   # server-thread-affinity true

   
   
10. Start Redis using the updated binary
    
    

    /home/xui/bin/redis/redis-server /home/xui/bin/redis/redis.conf

Build OpenSSH from Source (Latest Version)​

1. Install dependencies
   
   

   sudo apt update
   sudo apt install -y build-essential zlib1g-dev libssl-dev libpam0g-dev

   
   
2. Download and compile the latest OpenSSH
   
   

   wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
   tar -xzf openssh-9.7p1.tar.gz
   cd openssh-9.7p1
   ./configure --prefix=/usr --sysconfdir=/etc/ssh
   make -j$(nproc)
   sudo make install

   
   
3. Restart OpenSSH
   
   

   sudo systemctl restart ssh

Hi. Great tutorial.
When you mean ''Restrict your API Services", do you mean to whitelist from the following settings? General Settings > API > "api services" Admin Streaming IP's, API IP's and API Password. Could you please provide an example of what you think is safe. further clarification regarding these often forgotten settings would be very helpful as there seems to be no consensus or discussion about them. thanks and regards

 

[redhat]

Hi. Great tutorial.
When you mean ''Restrict your API Services", do you mean to whitelist from the following settings? General Settings > API > "api services" Admin Streaming IP's, API IP's and API Password.

Yes exactly.

Could you please provide an example of what you think is safe.

Mate isn’t that part self-explanatory?
And there also descriptions where its explained more in details.

 

[julian]

Yes exactly.


Mate isn’t that part self-explanatory?
And there also descriptions where its explained more in details.

View attachment 5733

Sorry for not being clear in my previous post, but what I really wanted to ask is whether to leave API IP blank or not. When left blank, does the system accept api calls from any ip or none? If any ip, it could be a security risk if left blank, especially without api password, although the attacker would have to 'guess' the api key and know the access code. I have been thinking about this matter for a while but could not find clarification here or elsewhere. thanks

 

[Juanwom]

Issue sumary

The XUI One panel is allowing requests even when IP whitelisting is enabled. This happens because, after analyzing the decrypted api.php, the panel does not correctly detect the requesting IP.

Actions Taken

Implemented protection on version 1.5.5, since versions 1.5.12 and 1.5.13 cause high CPU usage.

Set up logging to capture incoming API requests, showing both the IP and request details for better monitoring.

Video:

To view the content, you need to Sign In or Register.

 

[julian]

Issue sumary

The XUI One panel is allowing requests even when IP whitelisting is enabled. This happens because, after analyzing the decrypted api.php, the panel does not correctly detect the requesting IP.

Actions Taken

Implemented protection on version 1.5.5, since versions 1.5.12 and 1.5.13 cause high CPU usage.

Set up logging to capture incoming API requests, showing both the IP and request details for better monitoring.

Video:

Xui 1.5.5

That’s not good news. Could you tell us how best to secure it, once you know exactly how it works, or may be make the decrypted php file available? I think it would help the whole community. Thanks

 

[Juanwom]

Issue sumary

The XUI One panel is allowing requests even when IP whitelisting is enabled. This happens because, after analyzing the decrypted api.php, the panel does not correctly detect the requesting IP.

Actions Taken

Implemented protection on version 1.5.5, since versions 1.5.12 and 1.5.13 cause high CPU usage.

Set up logging to capture incoming API requests, showing both the IP and request details for better monitoring.

Video:

Xui 1.5.5

Recommendation

I found that once a load balancer is infected, it becomes easy for the attacker to persist and regain access to XUI One 1.5.13.

Security Recommendation

If a system is ever compromised, the best approach is to change the IP addresses or format the machine to fully remove any backdoors or persistent threats.

 

[denis81726262618]

Some TIPS to secure your server:

1. Perform a new installation of xui.one v1.5.13 on your MAIN and all LB's
2. Regenerate a your Admin Access Code, delete all unnecessary access codes like reseller, MAG if you not use them.
3. Restrict your API Services
4. Upgrade the Redis latest version on your Main Server (the v4.x Redis Server has Vulnerabilities)
5. Upgrade your OpenSSH server on your Main Server and LB's

Build Redis from Source (Latest Version) >> only required if you realy activated and use Redis Connection Handler

1. Find the Redis Process
   
   

   ps aux | grep redis

   
   You should see a line like this:
   
   

   xui      1234  0.5  0.3  56789 12345 ? Ssl  12:34   0:05 /home/xui/bin/redis/redis-server 127.0.0.1:6379

   The 1234 in this example is the process ID (PID).
   
   
2. Kill the Redis Process
   
   

   kill -9 1234

   or stop it with:
   

   pkill redis-server

   
   
3. Backup the Old Redis
   
   

   mv /home/xui/bin/redis/redis-server /home/xui/bin/redis/redis-server.old

   
   
4. Install dependencies
   
   

   sudo apt update
   sudo apt install -y build-essential tcl

   
   
5. Download and compile the latest Redis
   
   

   wget [URL]http://download.redis.io/redis-stable.tar.gz[/URL]
   tar xzvf redis-stable.tar.gz
   cd redis-stable
   make -j$(nproc)
   sudo make install

   
   
6. Check if the Compilation Was Successful
   
   

   src/redis-server --version

   
   
7. Replace the Old Redis Binary
   
   

   cp src/redis-server /home/xui/bin/redis/

   
   
8. Verify the new binary
   
   

   /home/xui/bin/redis/redis-server --version

   
   
9. Uncomment the server-threads and server-thread-affinity Directive in redis.conf (directives is not supported in Redis 7.4.2)
   
   

   nano /home/xui/bin/redis/redis.conf

   
   Comment them out:
   

   # server-threads 4
   # server-thread-affinity true

   
   
10. Start Redis using the updated binary
    
    

    /home/xui/bin/redis/redis-server /home/xui/bin/redis/redis.conf

Build OpenSSH from Source (Latest Version)​

1. Install dependencies
   
   

   sudo apt update
   sudo apt install -y build-essential zlib1g-dev libssl-dev libpam0g-dev

   
   
2. Download and compile the latest OpenSSH
   
   

   wget [URL]https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz[/URL]
   tar -xzf openssh-9.7p1.tar.gz
   cd openssh-9.7p1
   ./configure --prefix=/usr --sysconfdir=/etc/ssh
   make -j$(nproc)
   sudo make install

   
   
3. Restart OpenSSH
   
   

   sudo systemctl restart ssh

Sharing tips and strategies like this are rare but appreciate if you do more thanks