Jump to content


Active Members
  • Posts

  • Joined

  • Last visited

  • Days Won


akkiliON last won the day on January 2

akkiliON had the most liked content!


592 Excellent


About akkiliON

  • Rank
  • Birthday 01/01/1970

Recent Profile Visitors

6360 profile views
  1. Un XSS Reflected in www.apple.com. Raportul a fost acceptat. Nu sunt sigur daca o sa primesc vreo recompensa, dar am sa va zic. Issues eligible for public acknowledgment. We review all issues reported to us, and all legitimate services issues are eligible for public acknowledgement. While we request that you report all issues, the following issues are eligible for bounty reward payments only if they’re evaluated as novel or high impact based on Apple’s discretion. Open Redirects Reflected or Self XSS Bugs requiting exceeding unlikely user interaction Cross-site request forgery vulnerabilities where the only impact is logout Banner Grabbing or Service Versions without a vulnerability or PoC Rate Limiting unless credentials are able to be guessed External and Public Credential Dumps Denial of Service vulnerabilities Username enumeration unless some personal identifiable information is disclosed like email or phone number Report from automated tools or scanners where the vulnerability is not proven Expired Certificates DMARC/SPF Misconfiguration concerns Social engineering Properties that are not owned or operated by Apple Link: https://security.apple.com/bounty/categories/
  2. Un XSS Dom Based in www.intel.com. Din pacate, nu ofera bani pentru aplicatiile web. https://app.intigriti.com/programs/intel/intel/detail Vulnerabilitatea a fost raportata.
  3. @abraxyss - Problema pe care am gasit-o in Outlook, nu am luat bani. Mi-au zis ca a fost identificata de altcineva. https://microsoft.com/en-us/msrc/bounty-online-services?rtc=1 Aici gasesti ce este in scop.
  4. Prologue In 2022, Pwn2Own returned to Miami and was again targeting industrial control systems (ICS) software. I had participated in the inaugural Pwn2Own Miami in 2020 and was eager to participate again this year. My previous work included a nice vulnerability against the Iconics Genesis64 Control Server product. That vulnerability allowed a remote attacker to run arbitrary SQL commands using a custom WCF client. This year I was able to win $20,000 by running arbitrary JScript.NET code! This post will describe the process I took and the vulnerability I found. There were a few changes in the rules for 2022 though. In 2020, a successful entry against the Iconics Genesis64 target had to be launched against the exposed network services. In the new 2022 rules, however, opening a file is now considered a valid attack scenario: This sounded promising as this attack surface was not explored at the previous event and would likely have lots of issues! Installing Iconics Genesis64 After downloading the installation ISO, you install Iconics Genesis64 by running the setup.exe program in the ICONICS_Suite directory. The installer will ask you to restart multiple times and eventually all the dependencies will get installed and configuration begins. I used the default configuration in everything, but was also careful to make sure the demo programs were installed. Installation was the most tedious aspect of this entire effort. Exploring and exploiting the new attack surface I started by searching the file system for examples of the filetypes that Iconics Genesis64 handles by default: For example the “.awxx” file is a XML file and there are a number of example files in the “AlarmWorX64_Examples” folder included in the Iconics Genesis64 GenDemo package: For each file found, I did a quick visual scan looking for interesting data and keywords. Initially, I’m just trying to get a high-level overview of what each file is used for. Ideally, I’d find something like a serialized object stored in a file that would be deserialized when the file is opened. Some of the files are binary file formats. Some are compressed. Again, at this point in the process I’m just quickly scanning files for interesting strings and features, with no real expectations. However, when I scanned the “.gdfx” files the “ScriptCode” and “ScriptCodeManager” tags looked VERY interesting: <gwx:GwxDocument.GwxDocument> <gwx:GwxDocument FileVersion="" ScanRate="500"> <gwx:GwxDocument.ScriptCodeManager> <script:ScriptCodeManager> <script:ScriptCodeManager.Scripts> <script:ScriptCode Name="ThisDisplayCode" Type="JScriptNet"> <x:XData><![CDATA[ function DebugDump(sender : System.Object, cmdArgs : Ico.Gwx.CommandExecutionEventArgs) { var callback : Ico.Fwx.ClientWrapper.MethodCallDoneDelegate = ThisDocument.CreateDelegate(Ico.Fwx.ClientWrapper.MethodCallDoneDelegate, this, "CallDone"); ThisWindow.FwxClientWrapper.MethodCallAsync(":", "DebugDump", new Object[0], callback, null); } function CallDone(result : Ico.Fwx.ClientWrapper.MethodCallDoneResult) { message : String; message = String.Format("Result: {0}", result.Status.ToString()); if ((result.OutputArguments != null) && (result.OutputArguments.Count > 0)) { path = result.OutputArguments[0].ToString(); message += String.Format("\n\nDump file: {0}", path); } MessageBox.Show(message, "Debug Dump Result", MessageBoxButton.OK); } ]]></x:XData> </script:ScriptCode> <script:ScriptCode Name="JScriptDotNetGlobalVariablesCode" Type="JScriptNet" EditorBrowsable="Never"> <x:XData><![CDATA[ var ThisWindow : Ico.Gwx.GwxRuntimeViewControl; var ThisDocument : Ico.Gwx.GwxDocument; var ThisConfiguration : Ico.Gwx.GwxConfiguration; ]]></x:XData> </script:ScriptCode> </script:ScriptCodeManager.Scripts> </script:ScriptCodeManager> </gwx:GwxDocument.ScriptCodeManager> </gwx:GwxDocument> </gwx:GwxDocument.GwxDocument> This looks like JScript.NET code embedded in the file! This appears to be a feature for adding scripts to projects. However, when I try to open the file I get a “File Access Denied” message: It appears an Iconics user needs to be logged in first before this file will open. I documented this behavior and made a note to check if the JScript code could be executed before the authentication check or if the authentication could be bypassed, but then continued my survey of default file types. When I examined a GraphWorX64 Template file, “.tdfx”, I saw the same “ScriptCodeManager” tag and the file opened without requiring authentication: Adding the following code into a “ScriptCode” tag in the template file causes calc to be executed when the file is opened! var objShell = new ActiveXObject("Shell.Application"); objShell.ShellExecute("calc.exe", "", "calc.exe", "open", 0); To Submit or Not Submit Obviously, this is a pretty shallow bug and is a very weak bug to bring to Pwn2Own. There is a high likelihood that other researchers would find this bug and collide. I only had a couple hours of effort in at this point and had to make a decision to go with this bug or to immediately report this bug to ZDI and continue searching for better bugs. The decision was complicated further when the contest was delayed a few months because of the Omicron surge in Florida. Ultimately, my laziness and the busyness of life prevailed. I decided to take my chances with this weak bug. In the end, despite being the fifth (of 7 total) researchers to target Iconics Genesis64, the bug did not collide with previous attempts and was successful! Conclusion In this post I presented a vulnerability in the ICONICS Genesis64 Control Server’s handling of TDFX files. I also showed the simple process to find “new” attack surface in the code. Unfortunately, identifying attack surface that has not seen significant scrutiny is oftentimes all that is necessary to find and exploit critical vulnerabilities. ZDI assigned CVE-2022-33317 to this vulnerability and ICONICS fixed it in version 10.97.2. Thanks to the vendor for the timely fix and thanks to ZDI for organizing another great Pwn2Own! Source: https://trenchant.io/two-lines-of-jscript-for-20000-pwn2own-miami-2022/
  5. Vulnerabilitatea din [*].live.com. Azi am primit mesaj. Nu ma asteptam asa repede la un raspuns. 🙂 L.E: Au si reparat-o... LOL. Am verificat acum 😅
  6. O sa revin cu un mesaj cand primesc vreo noutate.... O sa dureze sigur ceva timp.... Mersi ! Asta l-am gasit si eu si am vrut sa il raportez pentru HoF macar. Daca l-ai gasit si tu si ti-au zis ca e out-of-scope.... nu mai are rost.... 😅 Ma nO_Ob, pe tine cine te-o pus sa stai... treci la munci 😂
  7. Salut. Am gasit doua vulnerabilitati XSS in aplicatiile detinute de cei de la Microsoft. Una este in Outlook, iar a doua intr-o alta aplicatie folosita si cunoscuta de multi... nu pot da detalii momentan deoarece nu a fost rezolvata nici una pana acum... Cel putin, nu am primit duplicat pe rapoartele trimise. 🙂 1. XSS reflected (without user interaction) - [*].live.com: 2. XSS reflected (user interaction required) - Outlook: Am observat ca si domeniile acestea sunt vulnerabile: office365.com si live.com.
  8. Ride hailing giant Uber disclosed Thursday it's responding to a cybersecurity incident involving a breach of its network and that it's in touch with law enforcement authorities. The New York Times first reported the incident. The company pointed to its tweeted statement when asked for comment on the matter. The hack is said to have forced the company to take its internal communications and engineering systems offline as it investigated the extent of the breach. The publication said the malicious intruder compromised an employee's Slack account, and leveraged it to broadcast a message that the company had "suffered a data breach," in addition to listing internal databases that's supposed to have been compromised. "It appeared that the hacker was later able to gain access to other internal systems, posting an explicit photo on an internal information page for employees," the New York Times said. Uber has yet to offer additional details about the incident, but it seems that the hacker, believed to be an 18-year-old teenager, social-engineered the employee to get hold of their password by masquerading as a corporate IT person and used it to obtain a foothold into the internal network. "Once on the internal network, the attackers found high privileged credentials laying on a network file share and used them to access everything, including production systems, corp EDR console, [and] Uber slack management interface," Kevin Reed, chief information security officer at Acronis, told The Hacker News. This is not Uber's first breach. It came under scrutiny for failing to properly disclose a 2016 data breach affecting 57 million riders and drivers, and ultimately paying off the hackers $100,000 to hide the breach. It became public knowledge only in late 2017. Federal prosecutors in the U.S. have since charged its former security officer, Joe Sullivan, with an alleged attempted cover-up of the incident, stating he had "instructed his team to keep knowledge of the 2016 breach tightly controlled." Sullivan has contested the accusations. In December 2021, Sullivan was handed down additional three counts of wire fraud to previously filed felony obstruction and misprision charges. "Sullivan allegedly orchestrated the disbursement of a six-figure payment to two hackers in exchange for their silence about the hack," the superseding indictment said. It further said he "took deliberate steps to prevent persons whose PII was stolen from discovering that the hack had occurred and took steps to conceal, deflect, and mislead the U.S. Federal Trade Commission (FTC) about the data breach." The latest breach also comes as the criminal case against Sullivan went to trial in the U.S. District Court in San Francisco. "The compromise is certainly bigger compared to the breach in 2016," Reed said. "Whatever data Uber keeps, the hackers most probably already have access." Source: https://thehackernews.com/2022/09/uber-says-its-investigating-potential.html
  9. Company says it is making changes to its security controls to prevent malicious insiders from doing the same thing in future; reassures bug hunters their bounties are safe. HackerOne has fired one of its employees for collecting bug bounties from its customers after alerting them to vulnerabilities in their products — bugs that had been found by other researchers and disclosed privately to HackerOne via its coordinated vulnerability disclosure program. HackerOne discovered the caper when one of its customers asked the organization to investigate a vulnerability disclosure that was made outside the HackerOne platform in June. The customer, like other clients of bug bounty programs, uses HackerOne to collect and report vulnerabilities in its products that independent security researchers might have discovered. In return, the company pays a reward — or bug bounty — for reported vulnerabilities. In this instance, the HackerOne customer said an anonymous individual had contacted them about a vulnerability that was very similar to another bug in its technology that a researcher had previously submitted via the HackerOne platform. Bug collisions — where two or more researchers might independently unearth the same vulnerability — are not uncommon. "However, this customer expressed skepticism that this was a genuine collision and provided detailed reasoning," HackerOne said in a report summarizing the incident. The customer described the individual — who used the handle "rzlr" — as using intimidating language in communicating information about the vulnerability, HackerOne said. Malicious Insider The company's investigation of the June 22, 2022, tip almost immediately pointed to multiple customers likely being contacted in the same manner. HackerOne researchers began probing every scenario where someone might have gained access to its vulnerability disclosure data: whether someone might have compromised one of its systems, gained remote access some other way, or if the disclosure had resulted from a misconfiguration. The data quickly pointed to the threat actor being an insider with access to the vulnerability data. HackerOne's investigators then looked at their log data on employee access to vulnerability disclosures and found that just one employee had accessed each of the disclosures that customers reported as being suspicious. "Within 24 hours of the tip from our customer, we took steps to terminate that employee's system access and remotely locked their laptop pending further investigation," HackerOne said. The company found the former employee had created a fictitious HackerOne account and collected bounties for a handful of disclosures. HackerOne worked with the relevant payment providers in each instance to confirm the bounties were paid into a bank account connected with the now-former employee. By analyzing the individual's network traffic, the investigators were also able to link the fictitious account to the ex-employee's primary HackerOne account. Undermining Trust Mike Parkin, senior technical engineer at Vulcan Cyber, says incidents like this can undermine the trust that is key to the success of crowdsourced vulnerability disclosure programs such as the one that HackerOne manages. "Trust is a big factor in vulnerability research and can play a large part in many bug bounty programs," Parkin says. "So, when someone effectively steals another researcher's work and presents it as their own, that foundational trust can be stretched." Parkin praised HackerOne for being transparent and acting quickly to address the situation. "Hopefully this incident won't affect the vulnerability research ecosystem overall, but it may lead to deeper reviews of bug bounty submissions going forward," he says. HackerOne said the former employee — who started only on April 4 — directly communicated with a total of seven of its customers. It urged any other customers that might have been contacted by an individual using the handle rzlr to contact the company immediately, especially if the communication had been aggressive or threatening in tone. The company also reassured hackers who have signed up for the platform that their eligibility for any bounties they might receive for vulnerability disclosures had not been adversely impacted. "All disclosures made from the threat actor were considered duplicates. Bounties applied to these submissions did not impact the original submissions." HackerOne said it would contact hackers whose reports the ex-employee might have accessed and attempted to resubmit. "Since the founding of HackerOne, we have honored our steadfast commitment to disclosing security incidents because we believe that sharing security information is essential to building a safer Internet," the company said. Following the incident, HackerOne has identified several areas where it plans to bolster controls. These include improvements to its logging capabilities, adding employees to monitor for insider threats, enhancing its employee screening practices during the hiring process, and controls for isolating data to limit damage from incidents of this type. Jonathan Knudsen, head of global research at Synopsys Cybersecurity Research Center, says HackerOne's decision to communicate clearly about the incident and its response to it is an example of how organizations can limit damage. "Security incidents are often viewed as embarrassing and irredeemable," he says. But being completely transparent about what happened can increase credibility and garner respect from customers. "HackerOne has taken an insider threat incident and responded in a way that reassures customers that they take security very seriously, are capable of responding quickly and effectively, and are continuously examining and improving their processes," Knudsen says. Source: https://www.darkreading.com/vulnerabilities-threats/hackerone-employee-fired-for-stealing-and-selling-bug-reports-for-personal-gain
  10. The LockBit 3.0 ransomware operation was launched recently and it includes a bug bounty program offering up to $1 million for vulnerabilities and various other types of information. LockBit has been around since 2019 and the LockBit 2.0 ransomware-as-a-service operation emerged in June 2021. It has been one of the most active ransomware operations, accounting for nearly half of all ransomware attacks in 2022, with more than 800 victims being named on the LockBit 2.0 leak website. The cybercriminals are encrypting files on compromised systems and also stealing potentially valuable information that they threaten to make public if the victim refuses to pay up. With the launch of LockBit 3.0, it seems they are reinvesting some of the profit in their own security via a “bug bounty program”. Similar to how legitimate companies reward researchers to help them improve their security, LockBit operators claim they are prepared to pay out between $1,000 and $1 million to security researchers and ethical or unethical hackers. Rewards can be earned for website vulnerabilities, flaws in the ransomware encryption process, vulnerabilities in the Tox messaging app, and vulnerabilities exposing their Tor infrastructure. They are also prepared to reward “brilliant ideas” on how to improve their site and software, as well as information on competitors. Addressing these types of security holes can help protect the cybercrime operation against researchers and law enforcement. One million dollars are offered to anyone who can dox — find the real identity — of a LockBit manager known as “LockBitSupp”, who is described as the “affiliate program boss”. This bounty has been offered since at least March 2022. Major ransomware groups are believed to have made hundreds of millions and even billions of dollars, which means the LockBit group could have the funds needed for such a bug bounty program. “With the fall of the Conti ransomware group, LockBit has positioned itself as the top ransomware group operating today based on its volume of attacks in recent months. The release of LockBit 3.0 with the introduction of a bug bounty program is a formal invitation to cybercriminals to help assist the group in its quest to remain at the top,” commented Satnam Narang, senior staff research engineer at Tenable. However, John Bambenek, principal threat hunter at security and operations analytics SaaS company Netenrich, said he doubts the bug bounty program will get many takers. “I know that if I find a vulnerability, I’m using it to put them in prison. If a criminal finds one, it’ll be to steal from them because there is no honor among ransomware operators,” Bambenek said. Casey Ellis, founder and CTO of bug bounty platform Bugcrowd, noted that “the same way hackers aren't always ‘bad’, the bounty model isn't necessarily ‘only useful for good’.” Ellis also pointed out, “Since Lockbit 3.0's bug bounty program essentially invites people to add a felony in exchange for a reward, they may end up finding that the $1,000 low reward is a little light given the risks involved for those who might decide to help them.” Other new features introduced with the launch of LockBit 3.0 include allowing victims to buy more time or “destroy all information”. The cybercriminals are also offering anyone the option to download all files stolen from a victim. Each of these options has a certain price. Vx-underground, a service that provides malware samples and other resources, also noted that the harassment of victims is now also encouraged. South Korean cybersecurity firm AhnLab reported last week that the LockBit ransomware has been distributed via malicious emails claiming to deliver copyright claims. “Lures like this one are simple and effective, although certainly not unique,” said Erich Kron, security awareness advocate at KnowBe4. “Like so many other phishing attacks, this is using our emotions, specifically the fear of a copyright violation, which many people have heard can be very costly, to get a person to make a knee-jerk reaction.” Source: https://www.securityweek.com/lockbit-30-ransomware-emerges-bug-bounty-program
  11. MEGA is a leading cloud storage platform with more than 250 million users and 1000 Petabytes of stored data, which aims to achieve user-controlled end-to-end encryption. We show that MEGA's system does not protect its users against a malicious server and present five distinct attacks, which together allow for a full compromise of the confidentiality of user files. Additionally, the integrity of user data is damaged to the extent that an attacker can insert malicious files of their choice which pass all authenticity checks of the client. We built proof-of-concept versions of all the attacks, showcasing their practicality and exploitability. Background MEGA is a cloud storage and collaboration platform founded in 2013 offering secure storage and communication services. With over 250 million registered users, 10 million daily active users and 1000 PB of stored data, MEGA is a significant player in the consumer domain. What sets them apart from their competitors such as DropBox, Google Drive, iCloud and Microsoft OneDrive is the claimed security guarantees: MEGA advertise themselves as the privacy company and promise User-Controlled end-to-end Encryption (UCE). We challenge these security claims and show that an adversarial service provider, or anyone controlling MEGA’s core infrastructure, can break the confidentiality and integrity of user data. Key Hierarchy At the root of a MEGA client’s key hierarchy, illustrated in the figure below, is the password chosen by the user. From this password, the MEGA client derives an authentication key and an encryption key. The authentication key is used to identify users to MEGA. The encryption key encrypts a randomly generated master key, which in turn encrypts other key material of the user. For every account, this key material includes a set of asymmetric keys consisting of an RSA key pair (for sharing data with other users), a Curve25519 key pair (for exchanging chat keys for MEGA’s chat functionality), and a Ed25519 key pair (for signing the other keys). Furthermore, for every file or folder uploaded by the user, a new symmetric encryption key called a node key is generated. The private asymmetric keys and the node keys are encrypted by the client with the master key using AES-ECB and stored on MEGA’s servers to support access from multiple devices. A user on a new device can enter their password, authenticate to MEGA, fetch the encrypted key material, and decrypt it with the encryption key derived from the password. Attacks RSA Key Recovery Attack MEGA can recover a user's RSA private key by maliciously tampering with 512 login attempts. Plaintext Recovery MEGA can decrypt other key material, such as node keys, and use them to decrypt all user communication and files. Framing Attack MEGA can insert arbitrary files into the user's file storage which are indistinguishable from genuinely uploaded ones. Integrity Attack The impact of this attack is the same as that of the framing attack, trading off less stealthiness for easier pre-requisites. GaP-Bleichenbacher Attack MEGA can decrypt RSA ciphertexts using an expensive padding oracle attack. RSA Key Recovery Attack MEGA uses RSA encryption for sharing node keys between users, to exchange a session ID with the user at login and in a legacy key transfer for the MEGA chat. Each user has a public RSA key pksharepkshare used by other users or MEGA to encrypt data for the owner, and a private key skshareskshare used by the user themselves to decrypt data shared with them. The private RSA key is stored for the user in encrypted form on MEGA’s servers. Key recovery means that an attacker successfully gets possession of the private key of a user, allowing them to decrypt ciphertexts intended for the user. We discovered a practical attack to recover a user’s RSA private key by exploiting the lack of integrity protection of the encrypted keys stored for users on MEGA’s servers. An entity controlling MEGA’s core infrastructure can tamper with the encrypted RSA private key and deceive the client into leaking information about one of the prime factors of the RSA modulus during the session ID exchange. More specifically, the session ID that the client decrypts with the mauled private key and sends to the server will reveal whether the prime is smaller or greater than an adversarially chosen value. This information enables a binary search for the prime factor, with one comparison per client login attempt, allowing the adversary to recover the private RSA key after 1023 client logins. Using lattice cryptanalysis, the number of login attempts required for the attack can be reduced to 512. Proof of Concept Attack Since the server code is not published, we cannot implement a Proof-of-Concept (PoC) in which the adversary actually controls MEGA. Instead, we implemented a MitM attack by installing a bogus TLS root certificate on the victim. This setup allows the attacker to impersonate MEGA towards the user while using the real servers to execute the server code (which is unknown to us). Server responses can be patched on the fly since they do not rely on secrets stored by the server, allowing the attack to be performed in real time as the victim interacts with MEGA. The following video shows how our attack recovers the first byte of the RSA private key. Afterward, we abort the attack to avoid any adverse impact on MEGA’s production servers. For each recovered bit, the attack consists of the following steps: The victim logs in. The adversary hijacks the login and replaces the correct session ID with their probe for the next secret bit. Based on the client’s response, the adversary updates its interval for the binary search of the RSA prime factor. The login fails for the victim. This is only a limitation of the MitM setup, since the correct SID is lost. An adversarial cloud storage provider can simply accept the returned SID. Note that after aborting the attack, the search interval is [0xe03ff...f, 0xe07ff...f]. The secret prime factor qq of the RSA modulus starts with 0xe06.... This value is within the search interval and the adversary already recovered the first byte 0xe0. Using all of qq, the adversary can recover the RSA private key (d,N)(d,N) using the public key (e,N)(e,N) as p=N/qp=N/q and d=e−1mod(p−1)(q−1)d=e−1mod(p−1)(q−1). Video: https://mega-awry.io/videos/rsa_key_recovery_poc.mp4 Plaintext Recovery As shown in the key hierarchy MEGA clients encrypt the private keys for sharing, chat key transfer, and signing with the master key using AES-ECB. Furthermore, file and folder keys also use the same encryption. A plaintext recovery attack lets the adversary compute the plaintext from a given ciphertext. In this specific attack, MEGA can decrypt AES-ECB ciphertexts created with a user’s master key. This gives the attacker access to the aforementioned and highly sensitive key material encrypted in this way. With the sharing, chat, signing, and node keys of a user, the adversary can decrypt the victim’s data or impersonate them. This attack exploits the lack of key separation for the master key and knowledge of the recovered RSA private key (e.g., from the RSA key recovery attack). The decryption oracle again arises during authentication, when the encrypted RSA private key and the session ID (SID), encrypted with the RSA public key, is sent from MEGA’s servers to the user. MEGA can overwrite part of the RSA private key ciphertext in the SID exchange with two target ciphertext blocks. It then uses the SID returned by the client to recover the plaintext for the two target blocks. Since all key material is protected with AES-ECB under the master key, an attacker exploiting this vulnerability can decrypt node keys, the victim’s Ed25519 signature key, its Curve25519 chat key, and, thus, also all exchanged chat keys. Given that the private RSA key has been recovered, one client login suffices to recover 32 bytes of encrypted key material, corresponding, for instance, to one full node key. Framing Attack This attack allows MEGA to forge data in the name of the victim and place it in the target’s cloud storage. While the previous attacks already allow an adversary to modify existing files using the compromised keys, this attack allows the adversary to preserve existing files or add more documents than the user currently stores. For instance, a conceivable attack might frame someone as a whistle-blower and place an extensive collection of internal documents in the victim’s cloud storage. Such an attack might gain credibility when it preserves the user’s original cloud content. To create a new file key, the attacker makes use of the particular format that MEGA uses for node keys. Before they are encrypted, node keys are encoded into a so called obfuscated key object, which consists of a reversible combination of the node key and information used for decryption of the file or folder. (Specifically, a nonce and a truncated MAC tag.) Since none of our attacks allow an attacker to encrypt values of their choosing with AES-ECB under the master key, the attacker works in the reverse direction to create a new valid obfuscated key object. That is, it first obtains an obfuscated key by decrypting a randomly sampled key ciphertext using the plaintext recovery attack. Note that this ciphertext can really be randomly sampled from the set of all bit strings of the length of one encrypted obfuscated key object. Decryption will always succeed, since the AES-ECB encryption mode used to encrypt key material does not provide any means of checking the integrity of a ciphertext. The resulting string is not under the control of the adversary and will be random-looking, but can regardless be used as a valid obfuscated key object since both file keys and the integrity information (nonces and MAC tags) can be arbitrary strings. Hence, the adversary parses the decrypted string into a file key, a nonce and MAC tag. It then modifies the target file which is to be inserted into the victim’s cloud such that it passes the integrity check when the file key and integrity information from the obfuscated key is used. The attacker achieves this by inserting a single AES block in the file at a chosen location. Finally, the adversary uses the known file key to encrypt the file and uploads the result to the victim’s cloud. Many standard file formats such as PNG and PDF tolerate 128 injected bits (for instance, in the file’s metadata, as trailing data, or in unused structural components) without affecting the displayed content. The image above shows the file our proof of concept inserts in the victim account. Our attack added the highlighted bytes to satisfy the integrity check. Due to the structure of PNG files, these bytes do not change the displayed pixels, i.e., it is visually identical to the unmodified image. Proof-of-Concept Attack The PoC shows our framing attack in the MitM setting described in the RSA private key recovery attack. The video shows the following steps: The victim logs into their account without any attack running. There are only three files in the cloud storage and none of them is called hacker-cat.png. The victim logs out and the adversary runs the plaintext recovery attack once. This involves the following steps: The adversary hijacks the victim’s login attempt and replaces the encrypted SID with the encrypted key that it picked for the file forgery. The victim’s client responds with the decrypted SID, from which the adversary can recover the plaintext for the injected ciphertext blocks. The log in attempt fails, which is only a limitation of the MitM setting. A malicious cloud provider can perform this attack without the user noticing. The adversary uses the key recovered in the previous step to forge an encrypted file. The victim logs in again. The adversary injects the forged file into the loaded file tree. The victim’s cloud now displays four files, including a new file called hacker-cat.png. When the user views this file in the browser, it correctly decrypts and shows the image. Video: https://mega-awry.io/videos/framing_attack_poc.mp4 Integrity Attack This attack exploits the peculiar structure of MEGA’s obfuscated key objects to manipulate an encrypted node key such that the decrypted key consists of all zero bytes. Since the attacker now knows the key, this key manipulation can be used to forge a file in a manner similar to the framing attack. Unlike for the framing attack (which requires the ability to decrypt arbitrary AES-ECB ciphertexts), for this attack the adversary only needs access to a single plaintext block and the corresponding ciphertext encrypted with AES-ECB under the master key. For instance, the attacker can use MEGA’s protocol for public file sharing to obtain the pair: when a user shares a file or folder publicly, they create a link containing the obfuscated key in plaintext. Hence, a malicious cloud provider who obtains such a link knows both the plaintext and the corresponding ciphertext for the node key, since the latter is uploaded to MEGA when the file was created (before being shared). This can then be used as the starting point for the key manipulation and allows a forged file ciphertext to be uploaded into the victim’s cloud, just as for the framing attack. However, this attack is less surreptitious than the framing attack because of the low probability of the all-zero key appearing in an honest execution, meaning that an observant user who inspects the file keys stored in their account could notice that the attack has been performed. GaP-Bleichenbacher Attack This attack is a novel variant of Bleichenbacher’s attack on PKCS#1 v1.5 padding. We call it a Guess-and-Purge (GaP) Bleichenbacher attack. MEGA can use this attack to decrypt RSA ciphertexts by exploiting a padding oracle in the fallback chat key exchange of MEGA’s chat functionality. The vulnerable RSA encryption is used for sharing node keys between users, to exchange a session ID with the user at login and in a legacy key transfer for the MEGA chat. As shown in the key hierarchy, each user has a public RSA key used by other users or MEGA to encrypt data for the owner, and a private key used by the user themselves to decrypt data shared with them. With this attack, MEGA can decrypt these RSA ciphertexts, albeit requiring an impractical number of login attempts. Attack idea: The original Bleichenbacher attack maintains an interval for the possible plaintext value of a target ciphertext. It exploits the malleability of RSA to test the decryption of multiples of the unknown target message. Successful unpadding leaks the prefix of the decrypted message due to the structure of the PKCS#1 v1.5 padding. This prefix allows an adversary to reduce intervals efficiently and recover the plaintext. MEGA uses a custom padding scheme which is less rigid than PKCS#1 v1.5. This makes it challenging to apply Bleichenbacher’s attack, because a successful unpadding no longer corresponds to a single solution interval. Instead many disjoint intervals are possible, depending on the value of an unknown prefix in MEGA’s padding scheme. Our attack devices a new Guess-and-Purge strategy that guesses the unknown prefix and quickly purges wrong guesses. This enables us to perform a search for the decryption of a ciphertext in 216.9216.9 client login attempts on average. Although this attack is weaker than the RSA key recovery attack (in the sense that a key recovery implies plaintext recovery), it is complementary in the vulnerabilities that it exploits and requires different attacker capabilities. It attacks the legacy chat key decryption of RSA encryption instead of the session ID exchange and can be performed by a slightly weaker adversary since no key-overwriting is necessary. The details of the GaP-Bleichenbacher attack are intricate. For a full description, see Appendix B of the paper. Sources: https://mega-awry.io/ https://thehackernews.com/2022/06/researchers-uncover-ways-to-break.html https://blog.mega.io/mega-security-update/
  12. Despite the old saying, not everything lives forever on the internet — including stolen crypto. This week, crypto security firm BlockSec announced that a hacker figured out how to exploit lending agreements and triple their crypto reward on the ZEED DeFi protocol, which runs on the Binance Smart Chain and trades with a currency called YEED. “Our system detected an attack transaction that exploited the reward distribution vulnerability in ZEED,” BlockSec said on Twitter this week. The end of the thread threw readers for a loop, though, because BlockSec also said the stolen currency had been permanently lost because of a self-destruct feature the hacker used. “Interestingly, the attacker does not transfer the obtained tokens out before self-destructing the attack contract. Probably, he/she was too excited,” BlockSec said in a following tweet. Possible Vigilante The sheer thought of losing a million dollars is enough to make anybody sweat bullets, but it’s possible the hacker did this on purpose. BlockSec isn’t sure what the motive was, and suggests it could’ve been an accident. A report by VICE published this week says the hacker could’ve been a vigilante with a message or something to prove. Because the self-destruct feature “burned” the tokens, they’re essentially gone forever. VICE suggests the hacker could’ve wanted to watch the crypto world burn — and the mysterious attacker certainly did cause a lot of chaos. After selling the hacked tokens, YEED’s value crashed to near zero. Sales won’t resume until ZEED takes steps to secure, repair and test its systems. Maybe the hacker messed up, or maybe we just witnessed a modern day Robin Hood attack. It’s possible we’ll never know who pulled off the hack, or why. Source: https://futurism.com/the-byte/hacker-steals-destroys Dorele, ce făcuși..... 😂
  13. A security vulnerability has been disclosed in the web version of the Ever Surf wallet that, if successfully weaponized, could allow an attacker to gain full control over a victim's wallet. "By exploiting the vulnerability, it's possible to decrypt the private keys and seed phrases that are stored in the browser's local storage," Israeli cybersecurity company Check Point said in a report shared with The Hacker News. "In other words, attackers could gain full control over the victim's wallets." Ever Surf is a cryptocurrency wallet for the Everscale (formerly FreeTON) blockchain that also doubles up as a cross-platform messenger and allows users to access decentralized apps as well as send and receive non-fungible tokens (NFTs). It's said to have an estimated 669,700 accounts across the world. By means of different attack vectors like malicious browser extensions or phishing links, the flaw makes it possible to obtain a wallet's encrypted keys and seed phrases that are stored in the browser's local storage, which can then be trivially brute-forced to siphon funds. Given that the information in the local storage is unencrypted, it could be accessed by rogue browser add-ons or information-stealing malware that's capable of harvesting such data from different web browsers. Following responsible disclosure, a new desktop app has been released to replace the vulnerable web version, with the latter now marked as deprecated and used only for development purposes. "Having the keys means full control over the victim's wallet, and, therefore funds," Check Point's Alexander Chailytko said. "When working with cryptocurrencies, you always need to be careful, ensure your device is free of malware, do not open suspicious links, keep OS and anti-virus software updated." "Despite the fact that the vulnerability we found has been patched in the new desktop version of the Ever Surf wallet, users may encounter other threats such as vulnerabilities in decentralized applications, or general threats like fraud, [and] phishing." Source: https://thehackernews.com/2022/04/critical-bug-in-everscale-wallet.html
  14. After a deep security research by Cysource research team led by Shai Alfasi & Marlon Fabiano da Silva, we found a way to execute commands remotely within VirusTotal platform and gain access to its various scans capabilities. About virustotal: The virustotal.com application has more than 70 antivirus scanners that scan files and URLs sent by users. The original idea of the exploration was to use the CVE-2021-22204 so that these scanners would execute the payload as soon as the exiftool was executed. Technical part: The first step was uploading a djvu file to the page https://www.virustotal.com/gui/ with the payload: Virustotal.com analyzed my file and none of the antiviruses detected the payload added to the file's metadata. According to the documentation at the link: https://support.virustotal.com/hc/en-us/articles/115002126889-How-it-works , virustotal.com uses several scans. The application sent our file with the payload to several hosts to perform the scan. On virustotal hosts, at the time that exiftool is executed, according to CVE-2021-22204 inform, instead of exiftool detecting the metadata of the file it executes our payload. Handing us a reverse shell on our machine. After that we noticed that it’s not just a Google-controlled environment, but environments related to internal scanners and partners that assist in the virustotal project. In the tests it was possible to gain access to more than 50 internal hosts with high privileges. Hosts identified within the internal network: The interesting part is every time we uploaded a file with a new hash containing a new payload, virustotal forwarded the payload to other hosts. So, not just we had a RCE, but also it was forwarded by Google's servers to Google's internal network, it customers and partners. Various types of services were found within the networks, such as: mysql, Kubernetes, oracle database, http and https applications, metrics applications, SSH, etc. Due to this unauthorized access, it was possible to obtain sensitive and critical information such as: Kubernetes tokens and certificates, service settings info, source codes, Logs, etc. We reported all the findings to Google that fixed this issue quickly. Disclosure Process: Report received by GoogleVRP - 04.30.2021 GoogleVRP trigged the report - 05.19.2021 GoogleVRP accepted the report as a valid report - 21.05.2021 GoogleVRP closed the report - 04.06.2021 Virustotal was no longer vulnerable - 13.01.2022 GoogleVRP allowed publishing - 15.01.2022 Source: https://www.cysrc.com/blog/virus-total-blog
  15. Hackers: https://breached.co/index.php ---------------------------------------------
  • Create New...