The final Patch Tuesday of 2023 is upon us, with Microsoft Corp. today releasing fixes for a relatively small number of security holes in its Windows operating systems and other software. Even more unusual, there are no known “zero-day” threats targeting any of the vulnerabilities in December’s patch batch. Still, four of the updates pushed out today address “critical” vulnerabilities that Microsoft says can be exploited by malware or malcontents to seize complete control over a vulnerable Windows device with little or no help from users.
Among the critical bugs quashed this month is CVE-2023-35628, a weakness present in Windows 10 and later versions, as well as Microsoft Server 2008 and later. Kevin Breen, senior director of threat research at Immersive Labs, said the flaw affects MSHTML, a core component of Windows that is used to render browser-based content. Breen notes that MSHTML also can be found in a number of Microsoft applications, including Office, Outlook, Skype and Teams.
“In the worst-case scenario, Microsoft suggests that simply receiving an email would be enough to trigger the vulnerability and give an attacker code execution on the target machine without any user interaction like opening or interacting with the contents,” Breen said.
Another critical flaw that probably deserves priority patching is CVE-2023-35641, a remote code execution weakness in a built-in Windows feature called the Internet Connection Sharing (ICS) service that lets multiple devices share an Internet connection. While CVE-2023-35641 earned a high vulnerability severity score (a CVSS rating of 8.8), the threat from this flaw may be limited somewhat because an attacker would need to be on the same network as the target. Also, while ICS is present in all versions of Windows since Windows 7, it is not on by default (although some applications may turn it on).
Satnam Narang, senior staff research engineer at Tenable, notes that a number of the non-critical patches released today were identified by Microsoft as “more likely to be exploited.” For example, CVE-2023-35636, which Microsoft says is an information disclosure vulnerability in Outlook. An attacker could exploit this flaw by convincing a potential victim to open a specially crafted file delivered via email or hosted on a malicious website.
Narang said what makes this one stand out is that exploitation of this flaw would lead to the disclosure of NTLM hashes, which could be leveraged as part of an NTLM relay or “pass the hash” attack, which lets an attacker masquerade as a legitimate user without ever having to log in.
”It is reminiscent of CVE-2023-23397, an elevation of privilege vulnerability in Microsoft Outlook that was exploited in the wild as a zero day and patched in the March 2023 Patch Tuesday release,” Narang said. “However, unlike CVE-2023-23397, CVE-2023-35636 is not exploitable via Microsoft’s Preview Pane, which lowers the severity of this flaw.”
As usual, the SANS Internet Storm Center has a good roundup on all of the patches released today and indexed by severity. Windows users, please consider backing up your data and/or imaging your system before applying any updates. And feel free to sound off in the comments if you experience any difficulties as a result of these patches.
More than five years after domain name registrars started redacting personal data from all public domain registration records, the non-profit organization overseeing the domain industry has introduced a centralized online service designed to make it easier for researchers, law enforcement and others to request the information directly from registrars.
In May 2018, the Internet Corporation for Assigned Names and Numbers (ICANN) — the nonprofit entity that manages the global domain name system — instructed all registrars to redact the customer’s name, address, phone number and email from WHOIS, the system for querying databases that store the registered users of domain names and blocks of Internet address ranges.
ICANN made the policy change in response to the General Data Protection Regulation (GDPR), a law enacted by the European Parliament that requires companies to gain affirmative consent for any personal information they collect on people within the European Union. In the meantime, registrars were to continue collecting the data but not publish it, and ICANN promised it would develop a system that facilitates access to this information.
At the end of November 2023, ICANN launched the Registration Data Request Service (RDRS), which is designed as a one-stop shop to submit registration data requests to participating registrars. This video from ICANN walks through how the system works.
Accredited registrars don’t have to participate, but ICANN is asking all registrars to join and says participants can opt out or stop using it at any time. ICANN contends that the use of a standardized request form makes it easier for the correct information and supporting documents to be provided to evaluate a request.
ICANN says the RDRS doesn’t guarantee access to requested registration data, and that all communication and data disclosure between the registrars and requestors takes place outside of the system. The service can’t be used to request WHOIS data tied to country-code top level domains (CCTLDs), such as those ending in .de (Germany) or .nz (New Zealand), for example.
The RDRS portal.
As Catalin Cimpanu writes for Risky Business News, currently investigators can file legal requests or abuse reports with each individual registrar, but the idea behind the RDRS is to create a place where requests from “verified” parties can be honored faster and with a higher degree of trust.
The registrar community generally views public WHOIS data as a nuisance issue for their domain customers and an unwelcome cost-center. Privacy advocates maintain that cybercriminals don’t provide their real information in registration records anyway, and that requiring WHOIS data to be public simply causes domain registrants to be pestered by spammers, scammers and stalkers.
Meanwhile, security experts argue that even in cases where online abusers provide intentionally misleading or false information in WHOIS records, that information is still extremely useful in mapping the extent of their malware, phishing and scamming operations. What’s more, the overwhelming majority of phishing is performed with the help of compromised domains, and the primary method for cleaning up those compromises is using WHOIS data to contact the victim and/or their hosting provider.
Anyone looking for copious examples of both need only to search this Web site for the term “WHOIS,” which yields dozens of stories and investigations that simply would not have been possible without the data available in the global WHOIS records.
KrebsOnSecurity remains doubtful that participating registrars will be any more likely to share WHOIS data with researchers just because the request comes through ICANN. But I look forward to being wrong on this one, and will certainly mention it in my reporting if the RDRS proves useful.
Regardless of whether the RDRS succeeds or fails, there is another European law that takes effect in 2024 which is likely to place additional pressure on registrars to respond to legitimate WHOIS data requests. The new Network and Information Security Directive (NIS2), which EU member states have until October 2024 to implement, requires registrars to keep much more accurate WHOIS records, and to respond within as little as 24 hours to WHOIS data requests tied everything from phishing, malware and spam to copyright and brand enforcement.
When KrebsOnSecurity broke the news on Oct. 20, 2023 that identity and authentication giant Okta had suffered a breach in its customer support department, Okta said the intrusion allowed hackers to steal sensitive data from fewer than one percent of its 18,000+ customers. But today, Okta revised that impact statement, saying the attackers also stole the name and email address for nearly all of its customer support users.
Okta acknowledged last month that for several weeks beginning in late September 2023, intruders had access to its customer support case management system. That access allowed the hackers to steal authentication tokens from some Okta customers, which the attackers could then use to make changes to customer accounts, such as adding or modifying authorized users.
In its initial incident reports about the breach, Okta said the hackers gained unauthorized access to files inside Okta’s customer support system associated with 134 Okta customers, or less than 1% of Okta’s customer base.
But in an updated statement published early this morning, Okta said it determined the intruders also stole the names and email addresses of all Okta customer support system users.
“All Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor),” Okta’s advisory states. “The Auth0/CIC support case management system was also not impacted by this incident.”
Okta said that for nearly 97 percent of users, the only contact information exposed was full name and email address. That means about three percent of Okta customer support accounts had one or more of the following data fields exposed (in addition to email address and name): last login; username; phone number; SAML federation ID; company name; job role; user type; date of last password change or reset.
Okta notes that a large number of the exposed accounts belong to Okta administrators — IT people responsible for integrating Okta’s authentication technology inside customer environments — and that these individuals should be on guard for targeted phishing attacks.
“Many users of the customer support system are Okta administrators,” Okta pointed out. “It is critical that these users have multi-factor authentication (MFA) enrolled to protect not only the customer support system, but also to secure access to their Okta admin console(s).”
While it may seem completely bonkers that some companies allow their IT staff to operate company-wide authentication systems using an Okta administrator account that isn’t protected with MFA, Okta said fully six percent of its customers (more than 1,000) persist in this dangerous practice.
In a previous disclosure on Nov. 3, Okta blamed the intrusion on an employee who saved the credentials for a service account in Okta’s customer support infrastructure to their personal Google account, and said it was likely those credentials were stolen when the employee’s personal device using the same Google account was compromised.
Unlike standard user accounts, which are accessed by humans, service accounts are mostly reserved for automating machine-to-machine functions, such as performing data backups or antivirus scans every night at a particular time. For this reason, they can’t be locked down with multifactor authentication the way user accounts can.
Dan Goodin over at Ars Technica reckons this explains why MFA wasn’t set up on the compromised Okta service account. But as he rightly points out, if a transgression by a single employee breaches your network, you’re doing it wrong.
“Okta should have put access controls in place besides a simple password to limit who or what could log in to the service account,” Goodin wrote on Nov. 4. “One way of doing this is to put a limit or conditions on the IP addresses that can connect. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.”
Goodin suggested that people who want to delve further into various approaches for securing service accounts should read this thread on Mastodon.
“A fair number of the contributions come from security professionals with extensive experience working in sensitive cloud environments,” Goodin wrote.
Microsoft today released updates to fix more than five dozen security holes in its Windows operating systems and related software, including three “zero day” vulnerabilities that Microsoft warns are already being exploited in active attacks.
The zero-day threats targeting Microsoft this month include CVE-2023-36025, a weakness that allows malicious content to bypass the Windows SmartScreen Security feature. SmartScreen is a built-in Windows component that tries to detect and block malicious websites and files. Microsoft’s security advisory for this flaw says attackers could exploit it by getting a Windows user to click on a booby-trapped link to a shortcut file.
Kevin Breen, senior director of threat research at Immersive Labs, said emails with .url attachments or logs with processes spawning from .url files “should be a high priority for threat hunters given the active exploitation of this vulnerability in the wild.”
The second zero day this month is CVE-2023-36033, which is a vulnerability in the “DWM Core Library” in Microsoft Windows that was exploited in the wild as a zero day and publicly disclosed prior to patches being available. It affects Microsoft Windows 10 and later, as well as Microsoft Windows Server 2019 and subsequent versions.
“This vulnerability can be exploited locally, with low complexity and without needing high-level privileges or user interaction,” said Mike Walters, president and co-founder of the security firm Action1. “Attackers exploiting this flaw could gain SYSTEM privileges, making it an efficient method for escalating privileges, especially after initial access through methods like phishing.”
The final zero day in this month’s Patch Tuesday is a problem in the “Windows Cloud Files Mini Filter Driver” tracked as CVE-2023-36036 that affects Windows 10 and later, as well as Windows Server 2008 at later. Microsoft says it is relatively straightforward for attackers to exploit CVE-2023-36036 as a way to elevate their privileges on a compromised PC.
Beyond the zero day flaws, Breen said organizations running Microsoft Exchange Server should prioritize several new Exchange patches, including CVE-2023-36439, which is a bug that would allow attackers to install malicious software on an Exchange server. This weakness technically requires the attacker to be authenticated to the target’s local network, but Breen notes that a pair of phished Exchange credentials will provide that access nicely.
“This is typically achieved through social engineering attacks with spear phishing to gain initial access to a host before searching for other vulnerable internal targets – just because your Exchange Server doesn’t have internet-facing authentication doesn’t mean it’s protected,” Breen said.
Breen said this vulnerability goes hand in hand with three other Exchange bugs that Microsoft designated as “exploitation more likely:” CVE-2023-36050, CVE-2023-36039 and CVE-2023-36035.
Finally, the SANS Internet Storm Center points to two additional bugs patched by Microsoft this month that aren’t yet showing signs of active exploitation but that were made public prior to today and thus deserve prioritization. Those include: CVE-2023-36038, a denial of service vulnerability in ASP.NET Core, with a CVSS score of 8.2; and CVE-2023-36413: A Microsoft Office security feature bypass. Exploiting this vulnerability will bypass the protected mode when opening a file received via the web.
Windows users, please consider backing up your data and/or imaging your system before applying any updates. And feel free to sound off in the comments if you experience any difficulties as a result of these patches.