Leaderboard

Eu la spital... după ce medicul si-a luat licența cu ChatGPT. Inca mai credeti ca filmul Idiocracy e sci-fi? Mie imi pare documentar / premonitie

Salutare! Sunt pe acest forum de prin 2015 iar in domeniul hacking de vreo 18 ani. Vad, aud, cunosc, observ din ce in ce mai putini romani care sa faca ceva notabil in acest domeniu. Ma tot intreb daca mai exista hackeri romani foarte buni cum erau acum multi ani si renumiti la nivel mondial. Din ce stiam atunci eram dupa rusi... pe locul 2 mondial la hacking skills si multe lucruri porneau de la noi. Parca nu mai vad nimic notabil si devin nostalgic. Ori am imbatranit eu, iar generatiile din urma sunt lenese si in filmele lor (tiktok, curvãsãrealã si drogangeala cat se poate) ? Ori a devenit internetul prea complicat si securizat? Ori toti hackerii de elita s-au pensionat , au devenit WhiteHat si s-au orientat catre joburi legitime in corporatii si le este teama sa mai activeze BlackHat? Voi ce pareri aveti? Ce top 3 mondial pe tari ati face in momentul de fata pentru hacking?

Today, at BlueHat IL 2023, we proudly announced our discovery of a new vulnerability in Azure, which we’ve dubbed ‘Super FabriXss.’ In our presentation, we demonstrated how we were able to escalate a reflected XSS vulnerability in Azure Service Fabric Explorer to an unauthenticated Remote Code Execution by abusing the metrics tab and enabling a specific option in the console – the ‘Cluster Type’ toggle. For the full story, please read our blog post below. Super FabriXss (CVE-2023-23383) is a dangerous Cross-Site Scripting (XSS) vulnerability discovered by the Orca Research Pod that affects Azure Service Fabric Explorer (SFX). This vulnerability enables unauthenticated remote attackers to execute code on a container hosted on a Service Fabric node. Orca Security immediately reported the vulnerability to the Microsoft Security Response Center (MSRC), who investigated the issue and assigned it CVE-2023-23383 (CVSS 8.2) with ‘Important’ severity. Microsoft released a fix and included it in their March 2023 Patch Tuesday. We would like to express our gratitude to Microsoft for the collaboration and prompt responses, as well as their diligent efforts in releasing a patch for the vulnerability. In this blog post, we’ll explore the details of how we found Super FabriXss, the risks it poses, as well as provide recommendations on how to mitigate the vulnerability. Executive Summary Orca Security found a dangerous Cross-Site Scripting (XSS) vulnerability in Azure Service Fabric Explorer (SFX) that we named ‘Super FabriXss’ and was assigned CVE-2023-23383 by Microsoft. The Super FabriXss vulnerability enables remote attackers to leverage an XSS vulnerability to achieve remote code execution on a container hosted on a Service Fabric node without the need for authentication. What started initially as a discovery of an XSS vulnerability that allowed a malicious script to be reflected off a web application, ended up being a full remote code execution (RCE) vulnerability after clicking on a crafted malicious URL and toggling the ‘Cluster’ Event Type setting under the Events tab. Organizations using Service Fabric Explorer version 9.1.1436.9590 or earlier are vulnerable to this CVE. Microsoft included a patch for this vulnerability in their March 2023 Patch Tuesday. If automatic updates are applied, no further action is needed. This is the second XSS vulnerability Orca found in Azure Service Fabric Explorer. The first one was called FabriXss. Since the second one is much more dangerous, we decided to call it ‘Super FabriXss.’ FabriXss? Sounds Familiar. If the name ‘FabriXss’ sounds familiar, it’s because this is the second XSS vulnerability that Orca discovered in Azure Service Fabric Explorer. However, unlike the first one, this vulnerability is much more dangerous. With Super FabriXss, a remote unauthenticated attacker can execute code on a container hosted on one of the Service Fabric nodes. This means that an attacker could potentially gain control of critical systems and cause significant damage. About the Super FabriXss Vulnerability Orca uncovered a critical vulnerability in Azure Service Fabric Explorer that we were able to exploit by sending a crafted URL to any Azure Service Fabric user. The vulnerability arises from a vulnerable ‘Node Name’ parameter, which can be exploited to embed an iframe in the user’s context. This iframe then retrieves remote files from a server controlled by the attacker, eventually leading to the execution of a malicious PowerShell reverse shell. This attack chain can ultimately result in remote code execution on the container which is deployed to the cluster, potentially allowing an attacker to take control of critical systems. Discovery and Remediation Timeline: ● Orca reported the vulnerability to MSRC via MSRC VDP on December 20, 2022 ● MSRC started investigating the issue on December 31, 2022 ● MSRC and Orca discussed the vulnerability and its impact on January 1, 2023 ● MSRC and Orca discussed the case on February 8, 2023 ● MSRC assigned CVE-2023-23383 to the vulnerability on March 14, 2023 ● Fix was included in Microsoft March 2023 Patch Tuesday on March 14, 2023 What is Azure Service Fabric Explorer? Microsoft Azure Service Fabric is a platform for distributed systems that enables the packaging, deployment, and management of stateless and stateful microservices and containers on a large scale. It is compatible with Windows and Linux operating systems, and can be deployed on any cloud, datacenter, or even on a personal laptop, spanning across geographic regions. Super FabriXss is a dangerous vulnerability that exists on Azure Service Fabric Explorer version 9.1.1436.9590 and earlier. Our Proof of Concept for the Super FabriXss Vulnerability For the FabriXss vulnerability that we found a few months ago, both Linux and Windows Clusters were susceptible to Cross Site Scripting through exploitation of the ComposeNewDeployment function in the old dashboard. The SuperFabriXxs vulnerability however, only exists in the Windows Cluster. Below we describe the steps of the exploit. Step 1: Creating the Azure Service Fabric Cluster We start by creating a new Azure Service Fabric with Windows Server 2016 with containers as our main cluster operation system. Once the cluster is ready, we can jump right into it and review the new (and patched) dashboard. Similar to the previous Service Fabric Explorer (SFX) dashboard, which was patched in response to the FabriXss vulnerability CVE-2022-35829, the current dashboard is essentially the same. However, it differs in that we are no longer able to toggle between the old SFX and the new one. As we can see, there is no option to switch between the old UI and the current one – Reviewing our Nodes list, we can see that we are currently running 6 Windows Nodes. When you click on one of the Nodes in the dashboard, it takes you to an independent Node dashboard that contains information about that specific Node. This dashboard has three main tabs: ● Essentials: High-level overview of the Node’s current state and health. ● Details: More detailed information about the Node, such as its ID, load metrics, current state, and uptime status. ● Events: Displays various metrics related to the events that are being executed on the Node. The Super FabriXss resides in the Events tab. Step 2: Observing Node Name Changes We noticed that when the Node name is modified in the UI, it is reflected in the Node’s independent dashboard. This behavior allowed us to observe how the server handles non-existent and/or modified values for different variables. For example, we can demonstrate this by changing the name of the Node to OrcaPOC and refreshing the page. We can see that our Node is now called OrcaPOC, but no valid or existing information regarding the Node is provided. A blank space is shown next to the green health status, in contrast to the valid name shown in the previous screenshots. So now that we know our name is being reflected, the next step would be to try to insert a common HTML Injection or Cross Site Scripting (XSS) payload such as – OK, so nothing unusual this far, the H1 tag was not rendered nor reflected in any unusual way. This can also be verified by reviewing the page elements: Step 3: Toggling the Cluster Option Switching between the different tabs reveals new capabilities that could have an effect on the Node’s newly inserted name, or may have no effect at all. Clicking on the Events tab would show us the exact same output as we receive in the two other tabs, but what about the Node Metrics? What if an actual event would take place or was executed by the Node, how does the name reflect if at all? A single click on Event Types shows two different options: Cluster and Repair Tasks – As we were testing and clicking on the two different options, we were surprised to find that clicking on ‘Cluster’ resulted in a new title being displayed as a large title, due to the effect of the <h1> tag in HTML. That was an interesting output since it now set us on a new course that would ultimately lead to an RCE. With one click to a crafted URL and enabling the Cluster Event Type under the Events tab, we triggered the rendered JS payload, generating a sequence of events that would result in a Remote Code Execution. I’ll validate the same tag escape by providing a Javascript payload that triggers an alert box – I’ll encode the payload, and combine the final url – So now, when entering any authenticated user, whether it’s the Administrator or a Low-Priv user with the appropriate permission clicks on the URL, he could be guided to enable the Cluster Event Type under the Events tab – et voilà! In the screenshot below, it is evident that the <img> tag successfully bypassed the enclosing <div> tag, indicating that it can now be executed. This demonstrates how we managed to escape the <div> class. Step 4: Leveraging the XSS to a RCE After discovering the FabriXss vulnerability, I realized that it might be possible to achieve a similar result by abusing XSS with the newly-found vulnerability. This involves embedding an iframe that allows the attacker to leverage the victim’s permissions to execute a desired action. However, we had a different goal this time: to gain execution command on a container hosted by one of the cluster’s nodes. To achieve this, we had to identify a specific functionality of Service Fabric that we could exploit. After several tests and many hours of reading documentation, we eventually discovered a vulnerability that could allow us to achieve our objective. The Start Compose Deployment Upgrade is sent via a POST request, and its purpose, as implied by its name, is to upgrade (i.e. overwrite) an existing Compose Deployment. It was as if a lightbulb had suddenly switched on in my mind, just like in a cartoon. Reviewing the mandatory Parameters, we can see that it requires a crucial parameter called ComposeDeploymentUpgradeDescription. In order to properly send the malicious payload, we need to understand what exactly the required properties are for the ComposeDeploymentUpgradeDescription: The key element that enables the attack scenario described is the ComposeFileContent. This object contains the specifications for the new deployment created by Docker Compose, which in turn is based on a Dockerfile. In this attack, the ComposeFileContent is modified to reference a new Docker image that is controlled by the attacker. The attacker creates this image using a Dockerfile that includes a CMD instruction, which will be executed when the image is built. The CMD instruction downloads a malicious .bat file that contains a PowerShell payload encoded in a specific way. This payload will then retrieve a second-stage remote file and execute it. The purpose of this attack is to replace the legitimate Compose deployment (in this example, let’s assume it’s an IIS application) with the attacker’s container. Once the attack is successful, the attacker gains access to a custom container that has a Reverse Shell, which enables them to remotely execute commands and potentially take control of the entire cluster node where the container is hosted. The following workflow diagram illustrates the process – In the image above, an attack is demonstrated that involves sending a crafted URL to the Service Fabric Administrator. This URL includes an iframe that uses a simple fetch request to trigger an upgrade of a Compose deployment, in this case for an IIS application. The upgrade process can be monitored in the Service Fabric dashboard, and once it is completed, the application will have a new name, such as “iisupgraded.” There are two main phases to the attack: 1. Once the iframe is embedded and the fetch request is triggered, the attacker’s code takes advantage of the upgrade process to overwrite the existing deployment with a new, malicious one. This new deployment includes a CMD instruction in its Dockerfile that will download a remote .bat file. 2. Once the .bat file is downloaded, it is executed and in turn retrieves a second file that contains an encoded reverse shell. This reverse shell allows the attacker to gain remote access to the target system and potentially take control of the cluster node where the container is hosted. It’s worth noting that this attack takes advantage of the Cluster Type Toggle options under the Events Tab in the Service Fabric platform that allows an attacker to overwrite an existing Compose deployment by triggering an upgrade with a specially crafted URL from XSS Vulnerability. By taking control of a legitimate application in this way, the attacker can then use it as a platform to launch further attacks or gain access to sensitive data or resources. The full attack scenario can be observed in the following video: About Orca Security The Orca Research Pod has discovered several critical vulnerabilities in public cloud provider platforms and worked with cloud service providers to remediate them. We continue to explore cloud products and services to find vulnerabilities before any malicious actors do, to strengthen the Orca platform and help make the cloud a safer place for all organizations. Orca’s agentless Cloud Security Platform connects to your environment in minutes and provides 100% visibility into all your assets AWS, Azure, Google Cloud, and Kubernetes, automatically including new assets as they are added. Orca detects and prioritizes cloud risks across every layer of your cloud estate, including vulnerabilities, malware, misconfigurations, lateral movement risk, API risks, weak and leaked passwords, sensitive data at risk, and overly permissive identities. Source: https://orca.security/resources/blog/super-fabrixss-azure-vulnerability/

RSTCon #3 se va desfasura la finalul acestei saptamani pe 27 si 28 aprilie 2023 de la 10:00 la 17:00 iar concursul CTF va avea loc de pe 29 aprilie 2023 ora 10:00 până pe 30 aprilie 2023 la ora 17:00. - Lista prezentarilor: https://lnkd.in/dbVbypGd - Platforma CTF: https://ctf.rstcon.com/ - Event: https://lnkd.in/daRccaj6 Pentru mai multe detalii: https://rstcon.com/ Like, share and subscribe 🤗

Interesant, mi-a scapat asta insa sunt familiar cu https://orca.security/resources/blog/azure-shared-key-authorization-exploitation/

Din acest motiv facem RSTCon, incercam... Nu stiu daca se poate face un astfel de top, in prezent problema se pune "cine plateste mai mult". Mai exact, daca firmele si guvernele platesc oamenii bine, poate sa iasa research frumos insa cel mai adesea e "secret" (e.g. Snowden). Din punctul meu de vedere SUA si China sunt foarte implicate, dar am vazut tot mai multe despre Coreea de Nord. Nu am idee despre Rusia, in trecut faceau treburi, in prezent probabil nu mai sunt asa "implicati". Asta ma intreb si eu, nu stiu ce se intampla, nu stiu ce fac tinerii din ziua de azi. Politehnica Bucuresti scotea oameni buni cu Security Summer School dar parca nici de acolo nu mai apar prea multi. Eu am fost implicat in ECSC si parca nu prea avem Juniori, nu stiu, poate s-au apucat toti de programare...

Bitcracker BitCracker is the first open source password cracking tool for memory units encrypted with BitLocker (using the password authentication method). Introduction BitLocker (formerly BitLocker Drive Encryption) is a full-disk encryption feature available in recent Windows versions (Ultimate and Enterprise editions of Windows Vista and Windows 7, the Pro and Enterprise editions of Windows 8, 8.1 and 10). BitCracker is a mono-GPU (OpenCL and CUDA) password cracking tool for memory units encrypted with the password authentication method of BitLocker (see picture below). Our attack has been tested on several memory units encrypted with BitLocker running on Windows 7, Window 8.1, Windows 10 (compatible and no-compatible mode) and BitLocker To Go. Requirements Minimum requirements for CUDA implementation: CUDA 7.5 NVIDIA GPU with CC 3.5 or later NVIDIA GPU with Kepler architecture or later Minimum memory requirement is 256 Mb; it may increase depending on the number of passwords processed by each kernel. How To: Use the build.sh script to build 3 executables: Hash extractor BitCracker CUDA version BitCracker OpenCL version The executables are stored in the build directory. Before starting the attack, you need to run bitcracker_hash to extract the hash describing the encrypted memory unit. It also verifies if the input memory unit satisfies BitCracker's requirements. > ./build/bitcracker_hash -h Usage: ./build/bitcracker_hash -i <Encrypted memory unit> -o <output file> Options: -h, --help Show this help -i, --image Path of memory unit encrypted with BitLocker -o, --outfile Output file The extracted hash is fully compatible with the John The Ripper format (see next Section). Then you can use the output hash file to run the BitCracker attack. > ./build/bitcracker_cuda -h Usage: ./build/bitcracker_cuda -f <hash_file> -d <dictionary_file> Options: -h, --help Show this help -f, --hashfile Path to your input hash file (HashExtractor output) -s, --strict Strict check (use only in case of false positives) -d, --dictionary Path to dictionary or alphabet file -g, --gpu GPU device number -t, --passthread Set the number of password per thread threads -b, --blocks Set the number of blocks Note: In case of false positives you can use the -s option, that is a more restrictive check on the correctness of the final result. Altough this check is empirically verified and it works with all the encrypted images in this repo, we can't guarantee that it doesn't lead to false negatives. Use -s option only if BitCracker returns several false positives. In the the run_test.sh script there are several attack examples using the encrypted images provided in this repo: imgWin7: memory unit encrypted with BitLocker using Windows 7 Enteprise edition OS imgWin8: memory unit encrypted with BitLocker using Windows 8 Enteprise edition OS imgWin10Compatible.vhd: memory unit encrypted with BitLocker (compatible mode) using Windows 10 Enteprise edition OS, imgWin10NotCompatible.vhd: memory unit encrypted with BitLocker (not compatible mode) using Windows 10 Enteprise edition OS, imgWin10NotCompatibleLong27.vhd: memory unit encrypted with BitLocker (not compatible mode) using Windows 10 Enteprise edition OS with the longest possible password (27 characters) Currently, BitCracker accepts passwords between 8 (minimum password length) and 27 characters (implementation reasons). BitCracker doesn't provide any mask attack, cache mechanism or smart dictionary creation; therefore you need to provide your own input dictionary. Performance Here we report the best performance of BitCracker implementations tested on different GPUs. GPU Acronim GPU Arch CC # SM Clock CUDA GFT GeForce Titan Kepler 3.5 14 835 7.0 GTK80 Tesla K80 Kepler 3.5 13 875 7.5 GFTX GeForce Titan X Maxwell 5.2 24 1001 7.5 GTP100 Telsa P100 Pascal 6.1 56 1328 8.0 AMDM Radedon Malta - - - - - Performance: Version GPU -t -b Passwords x kernel Passwords/sec Hash/sec CUDA GFT 8 13 106.496 303 635 MH/s CUDA GTK80 8 14 114.688 370 775 MH/s CUDA GFTX 8 24 106.608 933 1.957 MH/s CUDA GTP100 8 56 458.752 1.363 2.858 MH/s OpenCL AMDM 32 64 524.288 241 505 MH/s OpenCL GFTX 8 24 196.608 884 1.853 MH/s John The Ripper We released the OpenCL version as a plugin of John The Ripper (bleeding jumbo): Wiki page: http://openwall.info/wiki/john/OpenCL-BitLocker JtR source code: https://github.com/magnumripper/JohnTheRipper Next Release In the next relese: The maximum password lenght will be dynamic Improve strict check with optional MAC verification to avoid any false positive References, credits and contacts This is a research project in collaboration with the National Research Council of Italy released under GPLv2 license. Copyright (C) 2013-2017 Elena Ago (elena dot ago at gmail dot com) and Massimo Bernaschi (massimo dot bernaschi at gmail dot com) We will provide some additional info about BitCracker's attack in a future paper. Although we use the GPLv2 licence, we are open to collaborations. For any additional info, collaborations or bug report please contact elena dot ago at gmail dot com Download: bitcracker-master.zip or git clone https://github.com/e-ago/bitcracker.git Source: https://github.com/e-ago/bitcracker