Two critical vulnerabilities have been found recently in the wireless LAN devices of Contec. These critical vulnerabilities were discovered by the cybersecurity analysts, Samy Younsi and Thomas Knudsen of Necrum Security Lab.
There are two models of the FLEXLAN FXA2000 and FXA3000 series from CONTEC which are primarily used in airplane installations as WiFi access points.
As a result, these devices offer extremely high-speed connectivity during flight trips for the following purposes:-
The Flexlan FXA3000 and FXA2000 series LAN devices made by the Japan-based firm contain two critical vulnerabilities tracked as CVE–2022–36158 and CVE–2022–36159.
Necrum Security Labs’ researchers Samy Younsi and Thomas Knudsen have discovered two critical vulnerabilities in the wireless LAN devices manufactured by Contec. The company specializes in industrial automation, computing, and IoT communication technology.
Research Details
Reportedly, the Flexlan FXA3000 and FXA2000 series LAN devices made by the Japan-based firm contain two critical vulnerabilities tracked as CVE–2022–36158 and CVE–2022–36159.
For your information, these devices are used in airplanes to offer internet connectivity. The abovementioned series of devices offer WiFi access points in airplanes to ensure uninterrupted high-speed internet communication so that passengers could enjoy music, movies, and even purchased goodies during the flight. Hence, these vulnerabilities can allow an adversary to hack the inflight entertainment system and more.
FXA2000 (left) and FXA3000 (right)
Researchers discovered the first vulnerability (CVE–2022–36158) while performing the firmware’s reverse engineering. They identified a hidden page, which wasn’t listed in the Wireless LAN Manager interface. This page facilitates the execution of Linux commands on the device with root privileges. They could then access all system files and open the telnet port to gain complete access to the device.
The second vulnerability (CVE–2022–36159) entailed the use of hard-coded, weak cryptographic keys and backdoor accounts. While investigating, they also learned that the shadow file contained the has of two users, including root and user, and within a few minutes they could access them through a brute-force attack.
How to Fix the Issues?
In their blog post, researchers explained that the device owner could change the account’s user password from the web admin’s interface, which is the primary reason behind the emergence of these flaws. The root account is reserved for Contec for maintenance purposes.
Therefore, an attacker armed with the root hard-coded password can conveniently access all FXA2000 and FXA3000 series devices.
In order to fix the first issue, the hidden engineering web page must be removed from the under-production devices because the default password is weak and makes it easy for an attacker to inject a backdoor into the device using this page.
Furthermore, the company needs to generate a unique password for each device during the production phase for the second issue.
As pointed out by Eduard Kovacs of SecurityWeek, in its advisory, Contec explained that the vulnerabilities are connected to a private webpage created for developers to execute system commands and the page isn’t linked to other pages available to users. These vulnerabilities have been addressed in versions 1.16.00 for the FX3000 series and 1.39.00 for FX2000 series devices.
Through careful examination of which ports, services, and software are most prevalent on the internet and the systems and regions where they run, the research team discovered that misconfigurations and exposures represent 88% of the risks and vulnerabilities across the internet.
“Assessing the state of the internet is crucial in understanding an organization’s own risks and exposures,” said Zakir Durumeric, Chief Scientist of Censys.
Key findings
Misconfigurations – including unencrypted services, weak or missing security controls and self-signed certificates – make up roughly 60% of observed risks. When analyzing the risk profile of organizations across industries, missing common security headers accounted for the primary security error.
Exposures of services, devices, and information represent 28% of observed risks. This includes everything from accidental database to device exposures.
Critical vulnerabilities and advanced exploits only represent 12% of observed risks. When analyzing organizations by industry, the Computer and Information Technology industry had the widest spread of different risks, while Freight Shipment and Postal Services had the second widest.
Researchers also conducted a holistic assessment of the internet’s response to three major vulnerabilities – Log4j, GitLab and Confluence – to understand mitigation strategies based on how a vulnerability is perceived. From this analysis, Censys learned how the internet responds differently to vulnerability disclosures.
Three distinct types of behavior in response to vulnerability disclosures
Near-immediate upgrading: Systems vulnerable to Log4j acted quickly based on the widespread coverage of the vulnerability. By March 2022, Censys observed only 36% of potential vulnerable services were left unpatched.
Upgrading only after the vulnerability is being actively and widely exploited: While the GitLab vulnerability was being exploited, the remediation process acted slower than others until researchers discovered a botnet composed of thousands of compromised GitLab servers participating in DDoS campaigns.
Near-immediate response by taking the vulnerable instance off the internet entirely: Rather than upgrading, users chose to remove assets entirely from the internet after Confluence’s vulnerability became public between June 2021 and March 2022.
The internet constantly evolves as new technologies emerge, vulnerabilities are discovered, and organizations expand their operations that interact with the internet. Security teams have the responsibility to protect their organizations’ digital assets and need proper visibility into the entire landscape to do so.
Although vulnerabilities often garner the bigger headlines, it’s undetected misconfigurations and exposures that create the most risk for an organization, making it important to regularly assess any new hosts or services that appear in your infrastructure. Regardless of vulnerability type, providing organizations with the visibility and tools needed to strengthen their security posture introduces a proactive, more vigilant approach to digital risk management.
A list of free open source vulnerability scanners which developers and penetration testers can use to scan systems for vulnerabilities and potential malware.
A vulnerability assessment is an in-depth analysis of a network’s hardware, software, and other components to locate and fix potential security holes. Once identified, the software prioritizes security holes by how quickly they must be patched or mitigated. In most cases, the vulnerability scanning tool will also include guidance on how to fix or lessen the impact of any vulnerabilities it finds.
The results from vulnerability scanners can be used as a guide by security teams as they evaluate the safety of their network and take preventative measures.
Devs can use the following open-source vulnerability assessment tools to test their vulnerabilities for free.
Aqua Trivy
For developers to make informed decisions about which components to use in their applications and containers, open-source tools like Aqua Trivy can help them identify vulnerabilities and understand the associated risks. Trivy’s array of vulnerability scanners allows it to detect vulnerabilities in a wide variety of systems.
Static analysis of vulnerabilities in application containers is the focus of the Clair open-source project (currently including OCI and Docker).
Clients can index their container images via the Clair API and compare them to a database of known security flaws.
Tsunami
Tsunami is a flexible, plugin-based network security scanner designed to detect and scan critical vulnerabilities accurately.
Tsunami is scalable, runs quickly, and scans quietly.
Vaf
Vaf is a platform-independent web fuzzer that can quickly thread through requests, fuzz HTTP headers, and even act as a proxy.
Zed Attack Proxy ZAP
Under the OWASP banner, Zed Attack Proxy (ZAP) is developed and maintained as a free, open-source penetration testing tool and can be used as an effective vulnerability scanner.
ZAP is highly adaptable and extensible; it can even be deployed on a Raspberry Pi and is optimized for testing websites and deployed as a vulnerability scanner.
Grab and deploy this backend update if you offer even repo read access
A critical command-injection vulnerability in multiple API endpoints of Atlassian Bitbucket Server and Data Center could allow an unauthorized attacker to remotely execute malware, and view, change, and even delete data stored in repositories.
Atlassian has fixed the security holes, which are present in versions 7.0.0 to 8.3.0 of the software, inclusive. Luckily there are no known exploits in the wild.
But considering the vulnerability, tracked as CVE-2022-36804, received a 9.9 out of 10 CVSS score in terms of severity, we’d suggest you stop what you’re doing and update as soon as possible as it’s safe to assume miscreants are already scanning for vulnerable instances.
As Atlassian explains in its security advisory, published mid-last week: “An attacker with access to a public repository or with read permissions to a private Bitbucket repository can execute arbitrary code by sending a malicious HTTP request.”
Additionally, the Center for Internet Security has labeled the flaw a “high” security risk for all sizes of business and government entities. These outfits typically use Bitbucket for managing source code in Git repositories.
Atlassian recommends organizations upgrade their instances to a fixed version, and those with configured Bitbucket Mesh nodes will need to update those, too. There’s a compatibility matrix to help users find the Mesh version that’s compatible with the Bitbucket Data Center version.
And if you need to postpone a Bitbucket update, Atlassian advises turning off public repositories globally as a temporary mitigation. This will change the attack vector from an unauthorized to an authorized attack. However, “this can not be considered a complete mitigation as an attacker with a user account could still succeed,” according to the advisory.
Security researcher @TheGrandPew discovered and reported the vulnerability via Atlassian’s bug bounty program.
This latest bug follows a series of hits for the popular enterprise collaboration software maker.
Last month, Atlassian warned users of its Bamboo, Bitbucket, Confluence, Fisheye, Crucible, and Jira products that a pair of years-old, critical flaws threaten their security. It detailed the so-called Servlet Filter dispatcher vulnerabilities in its July security updates, and said the flaw allowed remote, unauthenticated attackers to bypass authentication used by third-party apps.
In June, Atlassian copped to another critical flaw in Confluence that was under active attack.
Plus, there was also the two-week-long embarrassing cloud outage that affected almost 800 customers this spring. This is less than half a percent of the company’s total customers, but still, as co-founder and co-CEO Mike Cannon-Brookes admitted on the firm’s most recent earnings call, it’s “one customer is too many.” And definitely not a good look for a cloud collaboration business. ®
(CVSS 9.8), affecting networking devices using Realtek’s RTL819x system on a chip was released online. The issue resides in the Realtek’s SDK for the open-source eCos operating system, it was discovered by researchers from cybersecurity firm Faraday Security
“On Realtek eCos SDK-based routers, the ‘SIP ALG’ module is vulnerable to buffer overflow. The root cause of the vulnerability is insufficient validation on the received buffer, and unsafe calls to strcpy. The ‘SIP ALG’ module calls strcpy to copy some contents of SIP packets to a predefined fixed buffer and does not check the length of the copied contents.” reads the advisory published by Realtek, which published the issue in March 2022. “A remote attacker can exploit the vulnerability through a WAN interface by crafting arguments in SDP data or the SIP header to make a specific SIP packet, and the successful exploitation would cause a crash or achieve the remote code execution.”
Millions of devices, including routers and access points, are exposed to hacking.
A remote attacker can exploit the flaw to execute arbitrary code without authentication by sending to the vulnerable devices specially crafted SIP packets with malicious SDP data.
The issue is very dangerous because the exploitation doesn’t require user interaction.
The PoC code developed by the experts works against Nexxt Nebula 300 Plus routers.
“This repository contains the materials for the talk “Exploring the hidden attack surface of OEM IoT devices: pwning thousands of routers with a vulnerability in Realtek’s SDK for eCos OS.”, which was presented at DEFCON30.” reads the description provided with the exploit code on GitHub.
The repo includes:
analysis: Automated firmware analysis to detect the presence of CVE-2022-27255 (Run analyse_firmware.py).
exploits_nexxt: PoC and exploit code. The PoC should work on every affected router, however the exploit code is specific for the Nexxt Nebula 300 Plus router.
ghidra_scripts: Vulnerable function call searching script and CVE-2022-27255 detection script.
DEFCON: Slide deck & poc video.
Johannes Ullrich, Dean of Research at SANS shared a Snort rule that can be used to detect PoC exploit attempt.
“The rule looks for “INVITE” messages that contain the string “m=audio “. It triggers if there are more than 128 bytes following the string (128 bytes is the size of the buffer allocated by the Realtek SDK) and if none of those bytes is a carriage return. The rule may even work sufficiently well without the last content match. Let me know if you see any errors or improvements.” wrote the expert.
Slides for the DEFCON presentation along with exploits, and a detection script for
South Staffordshire in the UK has acknowledged it was targeted in a cyberattack, but Clop ransomware appears to be shaking down the wrong water company.
South Staffordshire plc, a UK water-supply company, has acknowledged it was the victim of a cyberattack. Around the same time, the Clop ransomware group started threatening Thames Water that it would release data it has stolen from the utility unless Thames Water paid up.
The problem? Thames Water wasn’t breached.
Apparently, Clop got its UK water companies confused.
South Staffordshire serves about 1.6 million customers and recently reported that it was targeted in a cyberattack and was “experiencing a disruption to out corporate IT network and our teams are working to resolve this as quickly as possible.” It added there has been no disruption on service.
“This incident has not affected our ability to supply safe water, and we can confirm we are still supplying safe water to all of our Cambridge Water and South Staffs Water customers,” the water company said.
Meanwhile, Thames Water, the UK’s largest water supplier to more than 15 million people, was forced to deny it was breached by Clop ransomware attackers, who threatened they now had the ability to tamper with the water supply, according to reports.
“As providers of critical national infrastructure, we take the security of our networks and systems very seriously and are focused on protecting them, so that we can continue to provide resilient services to our customers and the environment,” the larger water company told the UK Mirror.
While Clop seems to have its records all wrong, both water utilities mounted capable responses to the ransomware group’s attack on critical infrastructure, according to Edward Liebig, global director of cyber ecosystem at Hexagon Asset Lifecycle Intelligence.
“I’m impressed by South Staffordshire Water’s ability to defend against the cyberattack in the IT systems and buffer the OT systems from impact,” Liebeg said. “And had Thames Water not done an investigation of the ‘proof of compromise,’ they may very well have decided to negotiate further. In both instances, each organization did their due diligence.”
Here’s this week’s BWAIN, our jocular term for a Bug With An Impressive Name.
BWAIN is an accolade that we hand out when a new cybersecurity flaw not only turns out to be interesting and important, but also turns up with its own logo, domain name and website.
This one is dubbed ÆPIC Leak, a pun on the words APIC and EPIC.
The former is short for Advanced Programmable Interrupt Controller, and the latter is simply the word “epic”, as in giant, massive, extreme, mega, humongous.
The letter Æ hasn’t been used in written English since Saxon times. Its name is æsc, pronounced ash (as in the tree), and it pretty much represents the sound of the A in in the modern word ASH. But we assume you’re supposed to pronounce the word ÆPIC here either as “APIC-slash-EPIC”, or as “ah!-eh?-PIC”.
What’s it all about?
All of this raises five fascinating questions:
What is an APIC, and why do I need it?
How can you have data that even the kernel can’t peek at?
Let’s rewind to 1981, when the IBM PC first appeared.
The PC included a chip called the Intel 8259A Programmable Interrupt Controller, or PIC. (Later models, from the PC AT onwards, had two PICs, chained together, to support more interrupt events.)
The purpose of the PIC was quite literally to interrupt the program running on the PC’s central processor (CPU) whenever something time-critical took place that needed attention right away.
These hardware interrupts included events such as: the keyboard getting a keystroke; the serial port receiving a character; and a repeating hardware timer ticking over.
Without a hardware interrupt system of this sort, the operating system would need to be littered with function calls to check for incoming keystrokes on a regular basis, which would be a waste of CPU power when no one was typing, but wouldn’t be responsive enough when they did.
As you can imagine, the PIC was soon followed by an upgraded chip called the APIC, an advanced sort of PIC built into the CPU itself.
These days, APICs provide much more than just feedback from the keyboard, serial port and system timer.
APIC events are triggered by (and provide real-time data about) events such as overheating, and allow hardware interaction between the different cores in contemporary multicore processors.
And today’s Intel chips, if we may simplifly greatly, can generally be configured to work in two different ways, known as xAPIC mode and x2APIC mode.
Here, xAPIC is the “legacy” way of extracting data from the interrupt controller, and x2APIC is the more modern way.
Simplifying yet further, xAPIC relies on what’s called MMIO, short for memory-mapped input/output, for reading data out of the APIC when it registers an event of interest.
In MMIO mode, you can find out what triggered an APIC event by reading from a specific region of memory (RAM), which mirrors the input/output registers of the APIC chip itself.
This xAPIC data is mapped into a 4096-byte memory block somewhere in the physical RAM of the computer.
This simplifies accessing the data, but it requires an annoying, complex (and, as we shall see, potentially dangerous) interaction between the APIC chip and system memory.
In contrast, x2APIC requires you to read out the APIC data directly from the chip itself, using what are known as Model Specific Registers (MSRs).
According to Intel, avoiding the MMIO part of the process “provides significantly increased processor addressability and some enhancements on interrupt delivery.”
Notably, extracting the APIC data directly from on-chip registers means that the total amount of data supported, and the maximum number of CPU cores that can be managed at the same time, is not limited to the 4096 bytes available in MMIO mode.
Software Bill of Material and Vulnerability Management Blind Spots
Open source software is everywhere (which is not a bad thing in itself). However, many buyers don’t have inventory of open source components included in software products they are buying. Business even fail in keeping tack of open source components used in internally developed applications. As a result, vulnerability management programs have blind spots.
Take an inventory of open source software (standalone and libraries) and make it part of your vulnerability management program.
Why it matters:
Use of open source software is not bad in itself. Everyone uses open source software. The biggest examples are Linux and Apache server.
Many commercial software vendors use open source components but don’t properly and adequately disclose all open source components included in the commercial products.
Recent vulnerabilities (e.g. log4j) have far reaching impact.
Software applications developed in-house also include open source components. As these applications age and the initial developers move on to new jobs, older and vulnerable open source components may still stay in the applications unnoticed for long time.
What to do:
It is crucial to have an up-to-date inventory of all open source software, whether used as standalone products or embedded as a library inside a product. We can’t manage if we don’t know its existence.
Require your software vendors to provide you with a list of all open source libraries and their versions embedded into their products.
Make this list part of the vulnerability management program. Monitor release of new vulnerabilities and patches for your inventory of open source software components.
When building a bill of material for open source components, it is imperative to not only contact your software vendors but also review all software applications developed in-house. In some cases you may use source code scanning tools to build inventory of these components.
The best-known cryptographic library in the open-source world is almost certainly OpenSSL.
Firstly, it’s one of the most widely-used, to the point that most developers on most platforms have heard of it even if they haven’t used it directly.
Secondly, it’s probably the most widely-publicised, sadly because of a rather nasty bug known as Heartbleed that was discovered more than eight years ago.
Despite being patched promptly (and despite reliable workarounds existing for developers who couldn’t or wouldn’t update their vulnerable OpenSSL versions quickly), Heartbleed remains a sort of “showcase” bug, not least because it was one of the first bugs to be turned into an aggressive PR vehicle by its discoverers.
With an impressive name, a logo all of its own, and a dedicated website, Heartbleed quickly became a global cybersecurity superstory, and, for better or worse, became inextricably linked with mentions of the name OpenSSL, as though the danger of the bug lived on even after it had been excised from the code.
Life beyond OpenSSL
But there are several other open-source cryptographic libraries that are widely used as well as or instead of OpenSSL, notably including Mozilla’s NSS (short for Network Security Services) and the GNU project’s GnuTLS library.
As it happens, GnuTLS just patched a bug known as CVE-2022-2509, reported in the project’s security advisoryGNUTLS-SA-2022-07-07.
This patch fixes a memory mismanagement error known as a double-free.
A vulnerability, tracked as CVE-2022-30563, impacting Dahua IP Camera can allow attackers to seize control of IP cameras.
The CVE-2022-30563 vulnerability impacting Dahua IP Camera can allow attackers to seize control of IP cameras. The issue affects Dahua’s implementation of the Open Network Video Interface Forum (ONVIF).
ONVIF provides and promotes standardized interfaces for effective interoperability of IP-based physical security products.
The vulnerability was discovered by researchers from Nozomi Networks and received a CVSS score of 7.4.
“We’re publishing the details of a new vulnerability (tracked under CVE-2022-30563) affecting the implementation of the Open Network Video Interface Forum (ONVIF) WS-UsernameToken authentication mechanism in some IP cameras developed by Dahua, a very popular manufacturer of IP-based surveillance solutions.” reads the advisory published by Nozomi Networks. “This vulnerability could be abused by attackers to compromise network cameras by sniffing a previous unencrypted ONVIF interaction and replaying the credentials in a new request towards the camera.”
ONVIF-conformant products allow users to perform a variety of actions on the remote device through a set of standardized Application Programming Interfaces (APIs), including watching camera footage, locking or unlocking a smart door, and performing maintenance operations.
The flaw resides in the “WS-UsernameToken” authentication mechanism implemented by Dahua in some of its IP cameras. Due to the lack of checks to prevent reply attacks, a threat actor can sniff an unencrypted ONVIF interaction and indefinitely replay the credentials in new requests towards the camera, which would be accepted as valid authenticated requests by the device.
Once obtained the credentials, an attacker can add an administrator account and use it to obtain full access to the device and perform actions such as watching live footage from the camera as shown below.
An attacker can conduct this attack by capturing one unencrypted ONVIF request authenticated with the WS-UsernameToken schema.
The following versions of Dahua video products, are affected:
Dahua ASI7XXX: Versions prior to v1.000.0000009.0.R.220620
Dahua IPC-HDBW2XXX: Versions prior to v2.820.0000000.48.R.220614
Dahua IPC-HX2XXX: Versions Prior to v2.820.0000000.48.R.220614
The vendor addressed the issue with the release of a patch on June 28, 2022,
“In addition to building security, surveillance cameras are used throughout many critical infrastructure sectors such as oil & gas, power grids, telecommunications, etc. These cameras are used to oversee many production processes, providing remote visibility to process engineers. Threat actors, nation-state threat groups in particular, could be interested in hacking IP cameras to help gather intel on the equipment or production processes of the target company.” concludes Nozomi. “This information could aid in reconnaissance conducted prior to launching a cyberattack. With more knowledge of the target environment, threat actors could craft custom attacks that can physically disrupt production processes in critical infrastructure.”
Google Project Zero experts disclosed details of a 5-Year-Old Apple Safari flaw actively exploited in the wild.
Researchers from the Google Project Zero team have disclosed details of a vulnerability in Apple Safari that was actively exploited in the wild.
The vulnerability, tracked as CVE-2022-22620, was fixed for the first time in 2013, but in 2016 experts discovered a way to bypass the fix.
“Whenever there’s a new in-the-wild 0-day disclosed, I’m very interested in understanding the root cause of the bug. This allows us to then understand if it was fully fixed, look for variants, and brainstorm new mitigations.” reads the post published by Google Project Zero. “This blog is the story of a “zombie” Safari 0-day and how it came back from the dead to be disclosed as exploited in-the-wild in 2022. CVE-2022-22620 was initially fixed in 2013, reintroduced in 2016, and then disclosed as exploited in-the-wild in 2022.”
Apple has addressed a zero-day vulnerability, tracked as CVE-2022-22620 (CVSS score: 8.8), in the WebKit affecting iOS, iPadOS, macOS, and Safari that may have been actively exploited in the wild.
The zero-day vulnerability was fixed by Apple in February, it is a use-after-free issue that could be exploited by processing maliciously crafted web content, leading to arbitrary code execution
“Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.” reads the security advisory published by Apple. “A use after free issue was addressed with improved memory management.”the google researcher Maddie Stone added. “The vulnerability then continued to exist for 5 years until it was fixed as an in-the-wild 0-day in January 2022.”
The vulnerability was reported by an anonymous researcher and the company addressed it by improving memory management.
“Whenever I’m doing a root cause analysis on a browser in-the-wild 0-day, along with studying the code, I also usually search through commit history and bug trackers to see if I can find anything related. I do this to try and understand when the bug was introduced, but also to try and save time.” she said.
The researcher noticed that the commits dated October 2016 and December 2016 were very large, she discovered that the commit in October changed 40 files with 900 additions and 1225 deletions. The commit in December changed 95 files with 1336 additions and 1325 deletions.
“Usually when we talk about variants, they exist due to incomplete patches: the vendor doesn’t correctly and completely fix the reported vulnerability. However, for CVE-2022-22620 the vulnerability was correctly and completely fixed in 2013. Its fix was just regressed in 2016 during refactoring. We don’t know how long an attacker was exploiting this vulnerability in-the-wild, but we do know that the vulnerability existed (again) for 5 years: December 2016 until January 2022.” concludes the expert. “There’s no easy answer for what should have been done differently. The developers responding to the initial bug report in 2013 followed a lot of best-practices.”
Researchers uncovered 3.6M accessible MySQL servers worldwide that represent a potential attack surface for their owners.
Researchers from Shadow Server scanned the internet for publicly accessible MySQL server instances on port 3306/TCP and uncovered 3.6M installs worldwide responding to their queries.
These publicly accessible MySQL server instances represent a potential attack surface for their owners.
“These are instances that respond to our MySQL connection request with a Server Greeting. Surprisingly to us, we found around 2.3M IPv4 addresses responding with such a greeting to our queries. Even more surprisingly, we found over 1.3M IPv6 devices responding as well (though mostly associated with a single Autonomous System).” states the report published by the researchers.
Most of the accessible IPv4 MySQL servers are in the United States (740.1K), China (296.3K), Poland (207.8K) and Germany (174.9K).
Accessible IPv4 MySQL servers
Most of the accessible IPv6 MySQL servers are in the United States (460.8K), Netherlands (296.3K), Singapore (218.2K) and Germany (173.7K).
“It is unlikely that you need to have your MySQL server allowing for external connections from the Internet (and thus a possible external attack surface). If you do receive a report on your network/constituency take action to filter out traffic to your MySQL instance and make sure to implement authentication on the server.” concludes the report.
US Critical Infrastructure Security Agency (CISA) adds 41 new vulnerabilities to its Known Exploited Vulnerabilities Catalog.
The Cybersecurity & Infrastructure Security Agency (CISA) has added 41 flaws to its Known Exploited Vulnerabilities Catalog, including recently addressed issues in the Android kernel (CVE-2021-1048 and
The Cisco IOS XR flaw (CVE-2022-20821, CVSS score: 6.5, is actively exploited in attacks in the wild, it resides in the health check RPM of Cisco IOS XR Software. An unauthenticated, remote attacker could trigger the issue to access the Redis instance that is running within the NOSi container.
A zero-day vulnerability in uClibc and uClibc-ng, a popular C standard library, could enable a malicious actor to launch DNS poisoning attacks on vulnerable IoT devices.
The bug, tracked as ICS-VU-638779, which has yet to be patched, could leave users exposed to attack, researchers have warned.
DNS poisoning
In a DNS poisoning attack, the target domain name is resolved to the IP address of a server that’s under an attacker’s control.
This means at if a malicious actor were to send a ‘forgotten password’ request, they could direct it to their own email address and intercept it – allowing them to change the victim’s password and access their account.
For an IoT device, this attack could potentially be used to intercept a firmware update request and instead directing it to download malware.
The DNS poisoning vulnerability was discovered by researchers at Nozomi Networks, who revealed that the issue remains unpatched, potentially exposing multiple users to attack.
Nozomi Networks states that uClibc is known to be used by major vendors such as Linksys, Netgear, and Axis, or Linux distributions such as Embedded Gentoo. uClibc-ng is a fork specifically designed for OpenWRT, a common operating system for web routers.
The library maintainer was unable to provide a fix, according to Nozomi. The researchers said they would refrain from sharing technical details or listing vulnerable devices until a patch is available.
“It’s important to note that a vulnerability affecting a C standard library can be a bit complex,” the team wrote in a blog post this week.
“Not only would there be hundreds or thousands of calls to the vulnerable function in multiple points of a single program, but the vulnerability would affect an indefinite number of other programs from multiple vendors configured to use that library.”
It’s easy to see why: it may be exploited by unauthenticated, remote attackers to breach systems and by attackers that already have access to a system and want to hop on others on the same network. It can also be exploited without the vulnerable system’s user doing anything at all (aka “zero-click” exploitation).
About CVE-2022-26809
CVE-2022-26809 is a remote code execution vulnerability in Microsoft Remote Procedure Call (RPC) runtime and affects a wide variety of Windows and Windows Server versions.
“To exploit this vulnerability, an attacker would need to send a specially crafted RPC call to an RPC host. This could result in remote code execution on the server side with the same permissions as the RPC service,” Microsoft said and advised admins to:
Block TCP port 445 at the enterprise perimeter firewall (but be aware that this does not protects systems from attacks from within the enterprise perimeter), and
This mention of SMB is probably what triggered some initial nervousness with security defenders, as it resurfaced bad memories related to the global WannaCry outbreak, which used the EternalBlue exploit to take advantage of vulnerabilities in Microsoft Windows SMB Server.
The infosec community worries about a functional proof-of-concept (PoC) exploit being released publicly soon and making the situation bad for enterprise defenders. There has been some topical online trolling and scam offers, but no PoC yet – and no evidence of covert exploitation.
Mitigation and detection
In the meantime, infosec experts have been augmenting Microsoft’s initial risk mitigation advice with their own:
CVE-2022-26809 Yes, blocking 445 at your network perimeter is necessary but not sufficient to help prevent exploitation. If by April 2022 you STILL have SMB exposed to the broader internet you've got some soul searching to do. Now, about those hosts already inside your network… pic.twitter.com/jS8fPrv8E2
Please remember: Port 445 is just ONE of the ports that may reach #RPC (CVE-2022-26809) on Windows. #MSRPC does Port 135 (and high port) or in some cases HTTP as well. Don't "close some ports" but "only open ports you need open". #allowlist#dontblocklist
Akamai researchers have shared their own analysis of Microsoft’s patch, which provides additional insight about the origin of the flaw, and Dr. Johannes Ullrich, Dean of Research at the SANS Technology Institute, published a post summarizing the danger
CVE-2022-26809
poses and reiterated that patching is the only real fix for this vulnerability.
“You can’t ‘turn off’ RPC on Windows if you are wondering. It will break stuff. RPC does more than SMB. For example, you can’t move icons on the desktop if you disable RPC (according to a Microsoft help page),” he explained, and noted that exploitation detection may be hard.
“I have no idea when we will see a working exploit, but I hope we will have until next week,” he concluded.
This cross-site scripting (XSS) cheat sheet contains many vectors that can help you bypass WAFs and filters. You can select vectors by the event, tag or browser and a proof of concept is included for every vector.
Researchers at healthcare cybersecurity company Cynerio just published a report about five cybersecurity holes they found in a hospital robot system called TUG.
TUGs are pretty much robot cabinets or platforms on wheels, apparently capable of carrying up to 600kg and rolling along at just under 3km/hr (a slow walk).
They’re apparently available in both hospital variants (e.g. for transporting medicines in locked drawers on ward rounds) and hospitality variants (e.g. conveying crockery and crumpets to the conservatory).
During what we’re assuming was a combined penetration test/security assessment job, the Cynerio researchers were able to sniff out traffic to and from the robots in use, track the network exchanges back to a web portal running on the hospital network, and from there to uncover five non-trivial security flaws in the backend web servers used to control the hospital’s robot underlords.
In a media-savvy and how-we-wish-people-wouldn’t-do-this-but-they-do PR gesture, the researchers dubbed their bugs The JekyllBot Five, dramatically stylised JekyllBot:5 for short.
Despite the unhinged, psychokiller overtones of the name “Jekyllbot”, however, the bugs don’t have anything to do with AI gone amuck or a robot revolution.
The researchers also duly noted in their report that, at the hospital where they were investigating with permission, the robot control portal was not directly visible from the internet, so a would-be attacker would have already needed an internal foothold to abuse any of the bugs they found.
Unauthenticated access to everything
Nevertheless, the fact that the hospital’s own network was shielded from the internet was just as well.
With TCP access to the server running the web portal, the researchers claim that they could:
Access and alter the system’s user database. They were apparently able to modify the rights given to existing users, to add new users, and even to assign users administrative privileges.
Snoop on trivially-hashed user passwords. With a username to add to a web request, they could recover a straight, one-loop, unsalted MD5 hash of that users’ password. In other words, with a precomputed list of common password hashes, or an MD5 rainbow table, many existing passwords could easily be cracked.
Send robot control commands. According to the researchers, TCP-level access to the robot control server was enough to issue unauthenticated commands to currently active robots. These commands included opening drawers in the robot’s cabinet (e.g. where medications are supposedly secured), cancelling existing commands, recovering the robot’s location and altering its speed.
Take photos with a robot. The researchers showed sample images snapped and recovered (with authorisation) from active robots, including pictures of a corridor, the inside of an elevator (lift), and a shot from a robot approaching its charging station.
Inject malicious JavaScript into legitimate users’ browsers. The researchers found that the robot management console portal was vulnerable to various types of cross-site scripting (XSS) attack, which could allow malware to be foisted on legitimate users of the system.
The modern realities of cybersecurity have uncovered the unpreparedness of many sectors and industries to deal with emerging threats. One of these sectors is the healthcare industry. The pervasiveness and proliferation of online innovation, systems, and applications in global healthcare have created a threat domain wherein policy and regulation struggle to keep pace with development, standardization faces contextual challenges, and technical capacity is largely deficient.
It is now urgent that healthcare professionals know the most relevant concepts and fundamentals of global cybersecurity related to eHealth. Cybersecurity for eHealth: A Practical Guide for Nontechnical Stakeholders and Healthcare Practitioners uses both a rigorous academic and practical professional approach in covering the essentials of cybersecurity. The book:
Distills foundational knowledge and presents it in a concise manner that is easily assimilated
Draws lessons from real-life case studies across the global healthcare industry to drive home complex principles and insights
Helps eHealth professionals to deal more knowledgeably and effectively with the realities of cybersecurity
Written for healthcare professionals without a background in the workings of information and communication technologies, the book presents the basics of cybersecurity and an overview of eHealth. It covers the foundational concepts, perspectives, and applications of cybersecurity in the context of eHealth and traverses the cybersecurity threat landscape to eHealth, including:
Threat categories, agents, and objectives
Strategies and approaches deployed by various threat agents
Predisposing risk factors in cybersecurity threat situations
Tools and techniques to protect against cybersecurity incidents
Experts recommend also private organizations review the Catalog and address the vulnerabilities in their infrastructure.
A remote attacker with unprivileged credentials can exploit the CVE-2022-23176 vulnerability in WatchGuard Firebox and XTM appliances to access the system with a privileged management session via exposed management access.
The vulnerability is actively exploited by the Cyclops Blink botnet operated by the Russia-linked Sandworm APT group. Sandworm (aka BlackEnergy and TeleBots) has been active since 2000, it operates under the control of Unit 74455 of the Russian GRU’s Main Center for Special Technologies (GTsST).
The group is also the author of the NotPetya ransomware that hit hundreds of companies worldwide in June 2017, causing billions worth of damage.
Cyclops Blink is believed to be a replacement for the VPNFilter botnet, which was first exposed in 2018 and at the time was composed of more than 500,000 compromised routers and network-attached storage (NAS) devices.
The Cyclops Blink malware has been active since at least June 2019, it targets WatchGuard Firebox, Small Office/Home Office (SOHO) network devices, and ASUS router models.
WatchGuard published instructions on how to restore compromised Firebox appliances. The company also developed and released a set of Cyclops Blink detection tools, as well as this 4-Step Cyclops Blink Diagnosis and Remediation Plan to help customers diagnose, remediate if necessary, and prevent future infection.
Cyclops Blink is sophisticated malware with a modular structure. It supports functionality to add new modules at run-time allowing Sandworm operators to implement additional capability as required.
The malware leverages the firmware update process to achieve persistence. The malware manages clusters of victims and each deployment of Cyclops Blink has a list of command and control (C2) IP addresses and ports that it uses.
Recently, the U.S. government has announced that it had dismantled the Cyclops Blink botnet operated by the Russia-linked Sandworm APT group.
Developers Remediate Less Than a Third of Vulnerabilities
Developers are regularly ignoring security issues as they deal with an onslaught of issues from security teams, even as they are expected to release software more frequently and faster than ever before.
In addition, developers fix just 32% of known vulnerabilities, and 42% of developers push vulnerable code once per month, according to Tromzo’s Voice of the Modern Developer Report.
The report, based on a survey of more than 400 U.S.-based developers who work at organizations where they currently have CI/CD tools in place, also found a third of respondents think developers and security are siloed.
Tromzo CTO and co-founder Harshit Chitalia pointed out the top security vulnerabilities of the past few years—Log4j, SolarWinds, Codecov—have all been supply chain attacks.
“This has made AppSec an urgent and top priority for CISOs worldwide,” he said. “In addition, everything as code with Kubernetes, Terraform and so on have made all parts of the development stack part of AppSec.”
From his perspective, the only way this big attack surface can be overcome is with security and development teams working hand in hand to secure the application in every step of the development cycle.
He added developers ignoring security issues is one of the fundamental issues AppSec engineers have with security.
“Security teams put their blood, sweat and tears into finding different vulnerabilities in code through orchestrating scanners and manual testing,” he said. “After all the work, seeing the issue on Jira queue for months is disappointing and quite frustrating.”
Fighting Friction
On the other hand, he pointed to developers who are now asked not only to develop features and fix bugs but also look at DevOps, performance and security of their applications.
“This leads to friction in priorities and, if unresolved, leads to unhappy employees,” he said. “The C-suite is very much aware of this problem, but they are stuck with security tools which are not created for developers. As application security is going through a big transformation, we believe the tooling will also shift.”
He explained there were several concerning findings from the survey but that two, in particular, stood out.
The first thing Chitalia found deeply concerning was the fact that 62% of developers are using 11 or more application security tools.
He said application security has evolved in recent years with AppSec teams now responsible for source-code analysis, DAST, bug bounty, dependency, secrets scanning, cloud scanning and language-specific scanners.
“This means developers are constantly fed information from these tools without any context and they have to triage and prioritize the workload these tools generate for them,” he said.
The second big worry was the fact that a third of vulnerabilities are noise.
“If someone told you that a third of the work you did needs to be thrown away every single day, how would you feel about that?” he asked. “But that’s the current state of application security.”
