Categories: News
Categories: Scams
Tags: tax scams

Tags:  efile.com

Tags:  US tax 2023

Tags:  backdoor

Tags:  Trojan

Tags:  Johannes Ullrich

Tags:  MalwareHunterTeam

Tags:  /u/SaltyPotter

Tags:  fake network error notification

Cybercriminals have compromised eFile.com to host malicious code that allows for the download of Trojans.



(Read more...)




The post Visitors of tax return e-file service may have downloaded malware appeared first on Malwarebytes Labs.

The IRS-authorized electronic filing service for tax returns, eFile.com, has been caught serving a couple of malicious JavaScript (JS) files these past few weeks, according to several security researchers and corroborated by BleepingComputer. Note this security incident only concerns eFile.com, not the IRS' e-file infrastructure and other similar-sounding domains.

As of this writing, eFile.com is clean. Users can access it without worry.

**The attack began 18 days ago**

The incident first arose as a possibility that something might be up with the website. A Reddit user encountered a fake "Network Error" page when accessing www.efile.com_._ The page, as shown below, informed visitors their browser "uses an unsupported protocol," and that they need to click the link it provided to them to update their browser—a known tactic often used by scammers.

This fake error message used to come up when visiting the domain. Uncharacteristically, it told visitors to update their browsers. This made Redditors suspect the domain was hijacked. (Source: /u/SaltyPotter, original image cropped to fit)

This, however, is no scam.

Known figures in cybersecurity, such as MalwareHunterTeam (@malwarehunterteam) and Johannes Ullrich (@johullrich) of SANS, caught wind of the potential site compromise and dug in, with each writing their analysis.

According to both MalwareHunterTeam and Ullrich, a malformed JS file named _popper.js_ contains encrypted malicious code—meaning it cannot be read plainly. Its purpose is to load another JS script called _update.js_ hosted on an Amazon Web Services (AWS) site. _update.js_ contains code used to display the fake error page.

_popper.js_ is a legitimate file modified to do malicious tasks. Because almost every page within the eForm website loads it, the malicious activities we mentioned are triggered every time a user visits any site page.

_update.js_ also contains two hard-coded download URLs, both served on the malicious domain _infoamanewonliag\[.\]online_. The two payloads are for two specific browsers visitors typically use, Chrome and Firefox.

"So different browsers get different payloads," says Ullrich. Chrome users get a payload named "update.exe" with a valid signature from Sichuan Niurui Science and Technology. Firefox users get "installer.exe." There is no indication if browsers based on Chromium (where Chrome is based) or Quantum (where Firefox is based) could also receive the payloads.

BleepingComputer has independently confirmed the payloads connect to an IP address hosted by Alibaba in China. The same IP also hosts the illicit domain the payloads were downloaded from.

These executables were written in Python. Malwarebytes detects them as **Trojan.Downloader.Python**.

As of Wednesday, _popper.js_ is free of malicious code.

**The backdoor**

Once users execute the payload, a PHP script runs quietly in the background. BleepingComputer's analysis shows that every 10 seconds, the backdoor script connects to a remote command and control (C2) server to receive one or more tasks to perform on the affected system. These include "executing a command and sending its output back to the attackers or downloading additional files onto the computer."

The backdoor is unsophisticated, but it's enough to give attackers access to the entire system, including company-owned devices.

"The full scope of this incident, including if the attack successfully infected any eFile.com visitors and customers, remains yet to be learned," says BleepingComputer.

Malwarebytes removes all remnants of ransomware and prevents you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

TRY NOW

Visitors of tax return e-file service may have downloaded malware

SQL Injection vulnerability in audit/class.audit.php in osTicket osTicket-plugins before commit a7842d494889fd5533d13deb3c6a7789768795ae via the order parameter to the getOrder function.

Nowadays, there are open-source solutions for every type of need. From accounting to CMS (Content Management System) applications, we can search for an application on the Internet that offers a solution to a specific issue or answers a need. Although, most of the time, it will be easier/faster than reinventing the wheel, using open-source applications might create some challenges. Security is one of those challenges, and zero-day vulnerabilities might put open-source users at risk.

With that in mind, one of the activities performed by _Checkmarx Labs_ is to search for security issues in open-source applications. The goal is to help secure open-source software which, usually, is not developed with a security-first approach, and is used by a community that often does not have the means to secure the open-source software.

One of the applications assessed was osTicket, an open-source ticketing system. With distinctive features and plugins, osTicket gives users the ability to “Manage, organize, and archive all your support requests and responses (…).” During our assessment, the _Checkmarx Labs_ team found some interesting vulnerabilities. In this blog/report, not only will we disclose some of the identified vulnerabilities but also elaborate on the team’s approach to identifying them.

**Research Lab**

The process that we follow, from creating a testing instance with the open-source application to finding the vulnerabilities, includes several steps. One of the first steps is to perform a static analysis scan (SAST) of the project, which will scan the code and find data flows that could lead to possible vulnerabilities. The use of this method often increases the number of issues found and is very useful when conducting these assessments. To validate the exploitability of the scan findings, we create a virtual machine (VM) and install the application in order to have a local testing environment for further testing. This way, we can confirm the existence of vulnerabilities and widen the assessment scope by performing a full penetration test, using both manual and automatic methodologies.

**Methodology**

After finalizing the first steps, we analyze scan results and identify the flows that lead to identified vulnerabilities. Although the scan simplifies the process, we also need to understand the application source code to find the “vulnerability entry point” (the input), and the flows that can be exploited. For example, during the analysis of the results, we identified some strange code injection results ending at “variable variables” \[1\]. This meant that user input controlled the variable name, and although this is not uncommon, it is a dangerous behavior—especially when user input is used.

_Figure 1 – Variable $sort, from the GET parameter, controlling the initial part of the variable name $x_

In this case, the string “**\_sort**” was added to the variable before its usage. We could not find any interesting variable name with that pattern. So, while the code is potentially weak to overwriting arbitrary variables, they would have to end in “\_sort”. This means the code does have a weakness but is not exploitable in a meaningful way.

There were a few different SAST results on this matter, and we decided to look further:

_Figure 2 – Request parameter concatenated to a raw HTML string at a user-controlled variable_

At the directory.inc.php file, the **$\_REQUEST** parameter was added directly to this string which appeared to be an HTML string, and yes, it was being used in multiple table headers. And of course, it would not be so simple.

We discovered that osTicket had a custom HTML sanitization method that was applied in many other HTML inputs, and it was not a very standard method for sanitizing input:

_Figure 3 – Request parameters filtered before usage in directory.inc.php_

This is an example piece of their sanitization method:

_Figure 4 – A fraction of the Format: sanitize blacklist function_

Although this method has some complexity, blacklisting specific strings and focusing on sanitizing HTML tags is not an effective way to sanitize the input, since it is difficult to be aware of every possible context and special characters that can be used to build an exploit.

After this analysis, we tried the only thing left, which was to confirm the vulnerability (in a local testing environment) explained in the **Reflected XSS, CVE-2022-32132** section below.

To confirm the vulnerabilities existence in the application, we created our own environment by setting up the application in a VM, and then perform the dynamic tests. With this environment, we not only confirmed the results found, but we could also find different vulnerabilities that are easier to find with our dynamic testing approach.

**Findings****Reflected XSS, CVE-2022-32132**

A Reflected XSS \[2\] was found in osTicket, allowing an attacker to inject malicious JavaScript into a browser’s DOM, which could enable attackers to hijack user sessions, perform actions on a user’s behalf within that user’s session context, and more.

After the analysis described in the Methodology, we validated that the vulnerability does exist in the application. Our first goal was to understand and escape the sanitizer. Sure enough, some special characters allowed us to discover this Reflected XSS vulnerability in the ‘directory’ URL, which is available by default in every osTicket installation. The blacklist was prepared to block user input from escaping HTML tags or even create dangerous tags like _<script>_, but on this specific scenario, the input was added to an attribute, and it allowed escaping from attributes. One of the obvious payloads was using the **_onmouseover_** attribute, which runs its value as JavaScript when the mouse moves over the component.

_Figure 5 – XSS payload executed_

_Figure 6 – Source page code with the XSS payload_

There are some things that can be done to increase the value (or risk) of this vulnerability, and the first thing is to make it easier for the victim to be attacked. An easy way of achieving this is to also inject the _style_ attribute of the vulnerable HTML tag in order to make it the size of the screen, being almost inevitable for the victim to visit the URL and trigger the payload.

/scp/directory.php?&&order=DESCE%22%20onmouseover=%22alert(1)%22%20style=%22position:fixed;top:0px;right:0;bottom:0px;left:0px;&sort=name

Another thing that can be done is to leverage this vulnerability by using other weaknesses. We found two cases that can be abused for that purpose:

*   A stored HTML injection in the _“notes”_ section can be abused to have a permanent attack vector inside the application that redirects the user to the Reflected XSS, making it in practice, a stored XSS.
*   A CSRF in the _“change password”_ functionality can be used as a payload for the XSS, allowing an attacker to change the user password of the victim.

As the _directory.php_ page is in an admin panel, these steps could leverage this vulnerability from a simple Reflected XSS to a Stored XSS capable of full _admin account takeover_ without the need of any installed plugins.

**Reflected XSS, CVE-2022-31889**

In the Audit plugin, we found two Reflected XSS results where user input from the type or state parameters was inserted into the HTML without being sanitized. The fix adds the missing sanitization for these inputs. A similar procedure to the one presented in the Methodology section, was taken when analyzing the plugins results.

After the analysis, and confirmation that it was a True Positive, we validated that it was indeed vulnerable to XSS. Looking at the code in which the vulnerability occurs, we can see how easily it can be exploited:

_Figure 7 – type variable insert in the HTML without sanitization_

The input from the _type_ and _state_ parameters is inserted into the “**_a”_** tag without any sanitization. We can just close the **href** quote and the tag (>) and insert a simple script tag.

_Figure 8 – XSS payload executed_

_Figure 9 – Source page code with the XSS payload_

**SQL injection, CVE-2022-31890**

In the same plugin (Audit), we came across a SQL Injection result where user input from the order parameter was inserted into a SQL query without proper sanitization. Looking at the fix, there was a condition in the if statement in the old code that verified if the order query parameter existed in the **orderWay** array. The problem is that this array was not defined, so PHP will issue a Notice and the _if condition_ will always be false. The correction involved adding the missing array and changing some of the sanitization logic for the order variable.

_Figure 10 – order\_by variable concatenated directly into SQL query_

After confirming that the flow was indeed vulnerable, a Proof-of-Concept was created to demonstrate the real impact, as shown in Figure 13. By exploiting the SQL injection vulnerability, an attacker could obtain passwords hashes, PII, and access privilege information. The fact that the injection is after an ORDER BY makes the possible injection limited. A SQL injection after the ORDER BY clause is different from other cases (after a WHERE clause for example) because the database does not accept UNION, WHERE, OR, or AND keywords. It is possible to have nested queries, and we can also have multiple queries if we use a semicolon, but this is only possible if the method that executes the queries allows multiple queries execution. In this case, the method that executes the queries does not allow multiple queries. Nonetheless, a blind time-based injection is possible, allowing data extraction from the database.

**Example of a regular request:**

_Figure 11 – Normal request to the audits.php page_

**Sleep injection:**

_Figure 12 – Sleep injection result in the audits.php page_

With this knowledge, we can create a script that allows data extraction that triggers a _sleep_ when a particular condition is met, like a specific character in the user’s table that matches one provided by us.

    import requests
    import urllib
    import string
    
    HOSTNAME = 'http://localhost'
    cookie = {'OSTSESSID': '...'}
    headers = {'User-Agent': '...'}
    alphabet = string.ascii_lowercase + string.digits + '-_!'
    position = 1
    offset = 0
    
    for letter in alphabet:
        payload = "(select case when ((select substring(username," + str(position) + ",1) from os_staff LIMIT 1 OFFSET " + str(offset) + ")='" + letter + "') then sleep(0.3) else 1 end);"
        result = requests.get(HOSTNAME + '/scp/audits.php?&type=S&state=All&order=ASC,' + urllib.parse.quote(payload) +'--&sort=timestamp&_pjax=%23pjax-container', cookies=cookie, headers=headers)
        if result.elapsed.total_seconds() > 2:
            print(letter)
            break

_Figure 13 – Python script that obtains the first username character of the first os\_staff table entry_

**Session fixation, CVE-2022-31888**

SAST tools increases the number of security issues that can be found, and yet code analysis is not enough when trying to find all kinds of problems. For example, we found a session fixation issue while interacting with the application that, with code review, is difficult to notice.

Due to the nature of the problem, detecting that a new session is generated and the old one is terminated in the correct place is complex to detect. Most of the time, a clear understanding of the code base is required to spot a session fixation issue, but this can also be applied to other types of vulnerabilities that can be chained together and create a higher risk. Dynamic testing is also necessary if we want to find other types of vulnerabilities, or vulnerabilities that trigger only in specific situations.

In this case, the application provides two login pages, one for the admin panel and another for the user portal. While testing both interfaces, the existing session cookie (used in both interfaces) is not invalidated after a login.

We found this vulnerability while fuzzing the login pages. When a login is successful, the server should invalidate the previous session and create a new one by sending it in the Set-Cookie header. This did not happen, and it was also possible to define our own session.

_Figure 14 – Set-Cookie with controlled cookie_

_Figure 15 – Session cookie controlled_

If an attacker can access or control the session value before authentication, an authenticating user would be authenticating a session known to the attacker, who would then hijack it.

**Stored XSS, CVE-2022-32074**

While dynamically analyzing the Filesystem Storage plugin, we came across two issues:

1 – It’s possible to browse directly to the root of the file upload directory (in this example, the name chosen for the folder is file\_uploads). With this, a directory listing is possible, as shown below.

_Figure 16 – File uploads directory content_

2 – Images accessible via this storage do not properly neutralize SVG files, which can contain XSS payloads. For example, uploading the following XML inside a JPG file will serve its contents as SVG.

    <?xml version="1.0" standalone="no"?>
    <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
    
    <svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
       <rect width="200" height="200" style="fill:rgb(0,255,255);stroke-width:3;stroke:rgb(0,0,0)" />
       <script type="text/javascript">
          alert("Stored XSS!!");
       </script>
    </svg>
    

By exploiting these two issues, we were able to find a Stored XSS.

_Figure 17 – XSS payload executed after accessing the image_

**Conclusion**

While the injection vulnerabilities such as SQLi and XSS are some of the security issues with more widespread knowledge and mitigation techniques, they are still at the top of vulnerabilities found. According to an Akamai report “the top three web application attacks were LFI (38%), SQLi (34%), and XSS (24%).”

These issues mainly arise because developers do not take into consideration that all data should be sanitized. Whether coming from user input or a database, the data should always be sanitized. There are also cases where custom sanitizers are implemented, and what happens is that developers’ implementation does not consider all cases. As a result, attackers can find ways to bypass the sanitizer \[3\].

OWASP provides a Cheat Sheet series that developers can use to understand the vulnerabilities and how to prevent them \[4\] \[5\].

The research was conducted in testing environments, and no production systems were used to test or exploit the previously mentioned vulnerabilities.

**Timeline**

*   April 20, 2022 – Full vulnerabilities report shared with osTicket team.
    *   osTicket team acknowledged receipt.
*   May 19, 2022 – Fix released.
*   June 22, 2022 – CVE-2022-31888, CVE-2022-31889, CVE-2022-31890 assigned.
*   July 13, 2022 – CVE-2022- 32074 assigned.
*   July 21, 2022 – CVE-2022-32132 assigned.
*   February 14, 2023 – Public disclosure

**Final Words**

It was a pleasure working with **osTicket’s** security team. Their professionalism and cooperation, as well as the prompt ownership they took, are what we hope for when we engage with software companies. Kudos!

This type of research activity is part of the _Checkmarx Security Research Team’s_ ongoing efforts to drive the necessary changes in software security practices among organizations who offer online services in an effort to improve security for everyone overall.

**References**

\[1\] https://www.php.net/manual/en/language.variables.variable.php

\[2\] https://portswigger.net/web-security/cross-site-scripting/reflected

\[3\] https://owasp.org/www-community/Injection\_Theory

\[4\] https://cheatsheetseries.owasp.org/cheatsheets/SQL\_Injection\_Prevention\_Cheat\_Sheet.html

\[5\] https://cheatsheetseries.owasp.org/cheatsheets/Cross\_Site\_Scripting\_Prevention\_Cheat\_Sheet.html

Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

CVE-2022-31890: Securing Open-Source Solutions: A Study of osTicket Vulnerabilities

Cross Site Scripting (XSS) vulnerability in audit/templates/auditlogs.tmpl.php in osTicket osTicket-plugins before commit a7842d494889fd5533d13deb3c6a7789768795ae.

@@ -3,18 +3,18 @@

  

$qs = array();

if($\_REQUEST\['type'\])

$qs += array('type' => $\_REQUEST\['type'\]);

$qs += array('type' => Format::htmlchars($\_REQUEST\['type'\]));

$type\='D';

  

if ($\_REQUEST\['type'\])

$type\=$\_REQUEST\['type'\];

$type\=Format::htmlchars($\_REQUEST\['type'\]);

  

if($\_REQUEST\['state'\])

$qs += array('state' => $\_REQUEST\['state'\]);

$qs += array('state' => Format::htmlchars($\_REQUEST\['state'\]));

$state\=\_\_('All');

  

if ($\_REQUEST\['state'\])

$state\=$\_REQUEST\['state'\];

$state\=Format::htmlchars($\_REQUEST\['state'\]);

  

//dates

$startTime =($\_REQUEST\['startDate'\] && (strlen($\_REQUEST\['startDate'\])>=8))?strtotime($\_REQUEST\['startDate'\]):0;

@@ -28,7 +28,7 @@

if($endTime)

$qs += array('endDate' => $\_REQUEST\['endDate'\]);

}

$order = AuditEntry::getOrder($\_REQUEST\['order'\]);

$order = AuditEntry::getOrder(Format::htmlchars($\_REQUEST\['order'\]));

$qs += array('order' => (($order\=='DESC') ? 'ASC' : 'DESC'));

$qstr = '&amp;'. Http::build\_query($qs);

CVE-2022-31889: xss: Audit Log · osTicket/osTicket-plugins@047a1c3

Ulearn version a5a7ca20de859051ea0470542844980a66dfc05d allows an attacker with administrator permissions to obtain remote code execution on the server through the image upload functionality. This occurs because the application does not validate that the uploaded image is actually an image.

**Summary**

**Name**

Ulearn a5a7ca20de859051ea0470542844980a66dfc05d - RCE

**Code name**

Scott

**Product**

Ulearn

**Affected versions**

a5a7ca20de859051ea0470542844980a66dfc05d

**State**

Public

**Release Date**

2023-04-10

**Vulnerability**

**Kind**

Insecure file upload

**Rule**

027\. Insecure file upload

**Remote**

Yes

**CVSSv3 Vector**

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

**CVSSv3 Base Score**

9.1

**Exploit available**

No

**CVE ID(s)**

CVE-2023-0670

**Description**

Ulearn version a5a7ca20de859051ea0470542844980a66dfc05d allows an attacker with administrator permissions to obtain remote code execution on the server through the image upload functionality. This occurs because the application does not validate that the uploaded image is actually an image.

**Vulnerability**

This vulnerability This occurs because the application does not validate that the uploaded image is actually an image.

**Evidence of exploitation**

To exploit this vulnerability, we only need to send the following malicious PHP code to the server.

**Our security policy**

We have reserved the ID CVE-2023-0670 to refer to this issue from now on.

*   https://fluidattacks.com/advisories/policy/

**System Information**

*   Version: Ulearn a5a7ca20de859051ea0470542844980a66dfc05d
    
*   Operating System: GNU/Linux
    

**Mitigation**

There is currently no patch available for this vulnerability.

**Credits**

The vulnerability was discovered by Carlos Bello from Fluid Attacks' Offensive Team.

**References**

**Vendor page** https://github.com/ulearnpro/ulearn/

**Timeline**

2023-02-03

Vulnerability discovered.

2023-02-03

Vendor contacted.

2023-02-03

Vendor replied acknowledging the report.

2023-04-10

Public Disclosure.

CVE-2023-0670: Ulearn a5a7ca20de859051ea0470542844980a66dfc05d - RCE | Advisories | Fluid Attacks

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to cross-site scripting (XSS) because it fails to sanitize user input in the `stopword` parameter. This has been fixed in 3.1.12.

**thorsten/phpmyfaq vulnerable to cross-site scripting (XSS) via stopword parameter**

Moderate severity GitHub Reviewed Published Apr 5, 2023 to the GitHub Advisory Database • Updated Apr 6, 2023

GHSA-gmjj-g2rm-xwm7: thorsten/phpmyfaq vulnerable to cross-site scripting (XSS) via stopword parameter

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the adminlog. This has been fixed in 3.1.12.

**thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) via adminlog**

High severity GitHub Reviewed Published Apr 5, 2023 to the GitHub Advisory Database • Updated Apr 6, 2023

GHSA-gcmq-7652-x98j: thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) via adminlog

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the FAQ site while generating an HTML Export. This has been fixed in 3.1.12.

**thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) via HTML export**

Moderate severity GitHub Reviewed Published Apr 5, 2023 to the GitHub Advisory Database • Updated Apr 6, 2023

GHSA-8p48-ghv5-7qq7: thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) via HTML export

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to improper access control when FAQ News is marked as inactive in settings and have comments enabled, allowing comments to be posted on inactive FAQs. This has been fixed in 3.1.12.

**thorsten/phpmyfaq vulnerable to improper access control**

Moderate severity GitHub Reviewed Published Apr 5, 2023 to the GitHub Advisory Database • Updated Apr 6, 2023

GHSA-2wjp-w7g7-h63q: thorsten/phpmyfaq vulnerable to improper access control

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to DOM cross-site scripting (XSS) because it fails to sanitize user input in the configuration privacy note URL parameter. This has been fixed in 3.1.12.

**thorsten/phpmyfaq vulnerable to DOM cross-site scripting (XSS) via configuration privacy note URL parameter**

High severity GitHub Reviewed Published Apr 5, 2023 to the GitHub Advisory Database • Updated Apr 6, 2023

GHSA-jph3-3j24-pg3j: thorsten/phpmyfaq vulnerable to DOM cross-site scripting (XSS) via configuration privacy note URL parameter

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the `category field name` parameter. This has been fixed in 3.1.12.

**thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) via category field name parameter**

Moderate severity GitHub Reviewed Published Apr 5, 2023 to the GitHub Advisory Database • Updated Apr 6, 2023

Tag

#php