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: Remote Client code Execution

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.

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.

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 .

It is possible to use the same bug to get code execution on all connected clients .

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 the rest of the bugs were found to make the first bug more dangerous .

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 ]

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.

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.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. .

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

"
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.

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.

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.

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.

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.

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.