Forums

"received more than $500 million in ransom payments" - Nu au dus-o rau deloc... 

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 ‍

Cred ca DIMETRA este implementarea Motorola a protocolului TETRA. Au mai adaugat ceva customizari. Acum vorbim de o gramada de bani cu infrastructurile astea. Mai intai m-as indura la un flipper, vorba lui @UnixDevel

De fapt ai nevoie de Prowlarr sau Jackett

Parca erau upgradati la Dimetra... deci este necesar si mai mult spor

Acesta nu este bun?   PS Mai functioneaza echipamentul?

Salut, ai nevoie pentru WiFi cracking, sau activitati similare, sau vrei doar net simplu? Solutia basic ar fi LiveCD, dar depinde de ce vrei tu sa faci. Nu am testat asta din VM, e posibil sa apara probleme. Incearca si VirtualBox si VMWare. 

Salut, nu poti lua legatura cu ei? 

Salutare oameni buni! Aș avea și eu nevoie de un backup al firmwareul-ui stock de la Allview P4 Duo cu Android 4.0 ICS.   Mulțumesc, Mihai