This article explores a phishing technique that simulates a browser window within the browser to spoof a legitimate domain.

Introduction

For security professionals, the URL is usually the most trusted aspect of a domain. Yes there’s attacks like IDN Homograph and DNS Hijacking that may degrade the reliability of URLs but not to an extent that makes URLs unreliable.

All of this eventually lead me to think, is it possible to make the “Check the URL” advice less reliable? After a week of brainstorming I decided that the answer is yes.

Pop-Up Login Windows

Quite often when we authenticate to a website via Google, Microsoft, Apple etc. we’re provided a pop-up window that asks us to authenticate. The image below shows the window that appears when someone attempts to login to Canva using their Google account.

Replicating The Window

Fortunately for us, replicating the entire window design using basic HTML/CSS is quite simple. Combine the window design with an iframe pointing to the malicious server hosting the phishing page, and its basically indistinguishable. The image below shows the fake window compared with the real window. Very few people would notice the slight differences between the two.

JavaScript can be easily used to make the window appear on a link or button click, on the page loading etc. And of course you can make the window appear in a visually appealing manner through animations available in libraries such as JQuery.

Demo

Custom URL on-hover

Hovering over a URL to determine if it’s legitimate is not very effective when JavaScript is permitted. HTML for a link generally looks like this:

<a href="https://gmail.com">Google</a>

If an onclick event that returns false is added, then hovering over the link will continue to show the website in the href attribute but when the link is clicked then the href attribute is ignored. We can use this knowledge to make the pop-up window appear more realistic.

<a href="https://gmail.com" onclick="return launchWindow();">Google</a>

function launchWindow(){
    // Launch the fake authentication window
    return false; // This will make sure the href attribute is ignored
}

Available Templates

I’ve created templates for the following OS and browser:

• Windows – Chrome (Light & Dark Mode)
• Mac OSX – Chrome (Light & Dark Mode)

The templates are available on my Github here.

Conclusion

With this technique we are now able to up our phishing game. The target user would still need to land on your website for the pop-up window to be displayed. But once landed on the attacker-owned website, the user will be at ease as they type their credentials away on what appears to be the legitimate website (because the trustworthy URL says so).

Source: Browser In The Browser (BITB) Attack | mr.d0x

The flaw, tracked as CVE-2022-0778, was reported to the OpenSSL Project by Google vulnerability researcher Tavis Ormandy.

The security hole affects OpenSSL versions 1.0.2, 1.1.1 and 3.0, and it has been fixed with the release of versions 1.0.2zd (for premium support customers), 1.1.1n and 3.0.2. Version 1.1.0 is also impacted, but it’s no longer supported and will not receive a patch.

Exploitation of the vulnerability is possible in certain situations, and it can lead to a DoS attack against a process that parses externally supplied certificates.

“The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli,” the OpenSSL Project explained in its advisory. “Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form.”

“It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters,” the advisory reads.

Source: High-Severity DoS Vulnerability Patched in OpenSSL | SecurityWeek.Com

A vulnerability in the container runtime engine CRI-O can be exploited by a rogue user to gain root-level access on a host.

In a Kubernetes environment powered by CRI-O, the security hole can be used by a miscreant to move through a cluster as an administrator, install malware, and cause other chaos.

CrowdStrike’s threat research team discovered the privilege-escalation flaw in CRI-O version 1.19. The bug, tracked as CVE-2022-0811 and more creatively dubbed cr8escape, received a severity score of 8.8 out of 10.

CrowdStrike privately disclosed the vulnerability, and CRI-O’s developers today released a fix while recommending immediate patching. Besides Kubernetes, other software and platforms that depend on or use CRI-O – these include OpenShift and Oracle Container Engine for Kubernetes – may also be vulnerable, CrowdStrike warned.

Each Kubernetes node includes a container runtime such as CRI-O. Among other tasks, the container runtime allows containerized apps to safely share each node’s underlying Linux kernel and other resources. As part of this, Linux ensures that when one container alters a kernel setting, this change isn’t reflected in other containers or on the host as a whole, thus keeping the containers suitably isolated from each other and the underlying platform, CrowdStrike explained.

“Some parameters are namespaced and can therefore be set in a single container without impacting the system at large,” the threat researchers wrote. “Kubernetes and the container runtimes it drives allow pods to update these ‘safe’ kernel settings while blocking access to others.”

And herein lies the security flaw: CRI-O introduced a bug that allows attackers to bypass these safeguards and set kernel parameters. “Due to the addition of sysctl support in version 1.19, [the pinns utility] will now blindly set any kernel parameters it’s passed without validation,” the threat researchers explained.

This means that anyone who can deploy a pod on a cluster using the CRI-O runtime can “abuse the kernel.core_pattern parameter to achieve container escape and arbitrary code execution as root on any node in the cluster,” CrowdStrike continued.

[…]

Source: Kubernetes container runtime CRI-O has make-me-root flaw

The 2022 update to our famous Hive Systems Password Table that’s been shared across the internet, social media, the news, and organizations worldwide. So what’s new, and what’s our methodology behind it? Keep reading!

---

Looking for a high resolution version to download?

Download the table now

---

It’s been two years since we first shared our (now famous) password table. So it was about time we not only updated it for 2022 but we wanted to walk you through our methodology. While the data fits nicely into the table above, things aren’t as as simple as it shows. So we’ll walk you through our data, our assumptions, and oh, you’re going to see a LOT of variations of the password table above!

“So how’d you make the table”?”

In 2020, we shared a colorful table that took the internet by storm. It showed the relative strength of a password against a brute force cracking attempt, based on the password’s length and complexity. The data was based on how long it would take a consumer-budget hacker to crack your password hash using a desktop computer with a top-tier graphics card. Two years later – quite a long period of time in processing power improvement terms –  we’re long overdue for an update.

First, let’s get some key terms out of the way. We’re going to talk about hashing. In the context of passwords, a “hash” is a scrambled version of text that is reproducible if you know what hash software was used. In other words, if I hash the word “password” using MD5 hashing software, the output hash is 5f4dcc3b5aa765d61d8327deb882cf99. Now if you hash the word “password” using MD5 hashing software, you’ll also get 5f4dcc3b5aa765d61d8327deb882cf99! We both secretly know the word “password” is our secret code, but anyone else watching us just sees 5f4dcc3b5aa765d61d8327deb882cf99. For this reason, the passwords you use on websites are stored in servers as hashes instead of in plain text like “password” so that if someone views them, in theory they won’t know the actual password.

You can’t do the reverse. A hash digest like 5f4dcc3b5aa765d61d8327deb882cf99 can’t be reverse computed to produce the word “password” that was used to make it. This one-way approach for hashing functions is by design. So how do hackers who steal hashes from websites ultimately end up with a list of real life passwords?

Hackers solve this problem by cracking the passwords instead. In this context, cracking means making a list of all combinations of characters on your keyboard and then hashing them. By finding matches between this list and the hashes from the stolen passwords, hackers can figure out your true password – letting them log into your favorite websites. And if you use the same password on multiple sites, you’re in for a bad time.

You can do this comparison with any computer, but it is much faster if you accelerate the process with a powerful graphics card. Graphics cards are those circuit boards that stick out of your computer’s bigger green circuit board. Among other things, this special circuit board has a Graphic Processing Unit (GPU) on it. A GPU is the shiny square tile on your graphics card that likely says NVIDIA or AMD on it. Originally GPU’s were built to make pictures and videos load faster on your computer screen. As it turns out, they’re also great for mining cryptocurrencies, and for calculating hashes. A popular application for hashing is called Hashcat. Hashcat includes hashing functions, like MD5, while allowing you to use them quickly and see how fast it was able to do so. As a side note, we usually say “hash function” instead of “hash software.”

[…]

Source: Are Your Passwords in the Green?

The rest of the article is very interesting, including many more graphs depicting various scenarios

The National Security Agency (NSA) has released a new report that gives all organizations the most current advice on how to protect their IT network infrastructures from cyberattacks.

NSA’s report ‘Cybersecurity Technical Report (CTR): Network Infrastructure Security Guidance‘ is available freely for all network admins and CIOs to bolster their networks from state-sponsored and criminal cyberattacks.

The report covers network design, device passwords and password management, remote logging and administration, security updates, key exchange algorithms, and important protocols such as Network Time Protocol, SSH, HTTP, and Simple Network Management Protocol (SNMP).

SEE: Cybersecurity: Let’s get tactical (ZDNet special report)

The US Cybersecurity and Infrastructure Security Agency (CISA) is encouraging tech leaders to view the NSA document as part of its new push for all organizations in the US and elsewhere to raise defenses after the recent disk wiper malware targeting Ukrainian organizations.

The document, from NSA’s cybersecurity directorate, encourages the adoption of ‘zero trust’ networks. Zero trust assumes malicious insiders and threats existing inside and outside classical network boundaries.

[…]

Source: NSA report: This is how you should be securing your network | ZDNet

Samsung shipped an estimated 100 million smartphones with botched encryption, including models ranging from the 2017 Galaxy S8 on up to last year’s Galaxy S21.

Researchers at Tel Aviv University found what they called “severe” cryptographic design flaws that could have let attackers siphon the devices’ hardware-based cryptographic keys: keys that unlock the treasure trove of security-critical data that’s found in smartphones.

What’s more, cyber attackers could even exploit Samsung’s cryptographic missteps – since addressed in multiple CVEs – to downgrade a device’s security protocols. That would set up a phone to be vulnerable to future attacks: a practice known as IV (initialization vector) reuse attacks. IV reuse attacks screw with the encryption randomization that ensures that even if multiple messages with identical plaintext are encrypted, the generated corresponding ciphertexts will each be distinct.

Untrustworthy Implementation of TrustZone

In a paper (PDF) entitled “Trust Dies in Darkness: Shedding Light on Samsung’s TrustZone Keymaster Design” – written by by Alon Shakevsky, Eyal Ronen and Avishai Wool – the academics explain that nowadays, smartphones control data that includes sensitive messages, images and files; cryptographic key management; FIDO2 web authentication; digital rights management (DRM) data; data for mobile payment services such as Samsung Pay; and enterprise identity management.

The authors are due to give a detailed presentation of the vulnerabilities at the upcoming USENIX Security, 2022 symposium in August.

The design flaws primarily affect devices that use ARM’s TrustZone technology: the hardware support provided by ARM-based Android smartphones (which are the majority) for a Trusted Execution Environment (TEE) to implement security-sensitive functions.

TrustZone splits a phone into two portions, known as the Normal world (for running regular tasks, such as the Android OS) and the Secure world, which handles the security subsystem and where all sensitive resources reside. The Secure world is only accessible to trusted applications used for security-sensitive functions, including encryption.

Cryptography Experts Wince

Matthew Green, associate professor of computer science at the Johns Hopkins Information Security Institute, explained on Twitter that Samsung incorporated “serious flaws” in the way its phones encrypt key material in TrustZone, calling it “embarrassingly bad.”

“They used a single key and allowed IV re-use,” Green said.

“So they could have derived a different key-wrapping key for each key they protect,” he continued. “But instead Samsung basically doesn’t. Then they allow the app-layer code to pick encryption IVs.” The design decision allows for “trivial decryption,” he said.

[…]

Source: Samsung Screwed Up Encryption on 100M Phones | Threatpost