![winebottler explorer winebottler explorer](https://i.blogs.es/31253c/iemac/450_1000.jpg)
: Tried to establish initial contact with the developer using Facebook.If you have any ideas I would love to hear them. Maybe this issue speeds up this process.Īs blocking the request to stalls WineBottler I can think of no reliable way to work around this issue. The author already mentioned that he is planing to do so in the future. To demonstrate the attack here’s a video showing the above mitmproxy script in action.Īll request should be carried out over encrypted communication channels like HTTPS.
#WINEBOTTLER EXPLORER DOWNLOAD#
However I think they only download and run winetricks on their first launch. This in turn greatly limits the attack surface. “Bundles” are basically Windows applications wrapped by WineBottler so that you can use them as if they were OS X applications. I verified that they are also affected by this issue. The next logical step was to verify the bundles that have been created using WineBottler.
#WINEBOTTLER EXPLORER CODE#
Calculator.app is executed to proof that remote code execution has been gained. Tada, after launching WineBottler the script is downloaded and executed.
#WINEBOTTLER EXPLORER MANUAL#
Simply launch mitmproxy using the following command and redirect all HTTP traffic to it (either by using ARP spoofing or by simply setting a manual proxy for testing). With decoded(flow.response): # automatically decode gzipped responses.į = "" # replace original script to launch Calculator.appį += '#!/bin/sh'+NEWLINEį += '/usr/bin/open /Applications/Calculator.app' If = "" and _code = 301 and ="GET":į_code=200 # overwrite 301 status code to 200 This can be carried out by using for example ARP spoofing or by providing a malicious “free” Wifi hotspot.Īnyhow, by replying to the initial request with a valid Terminal script, remote commands can be injected.Īs the script is also immediately executed this is a reliable way to overtake a system as shown below.Īs I had a little time spare, I automated the attack using mitmproxy and the following custom script named “drunken_winebottler.py”. However as the first request is initiated using unencrypted HTTP we can intercept and modify all further requests.Īn attacker can thereby modify the unsecured HTTP connection using a man-in-the-middle attack. įurther investigation showed that after a redirect, a Terminal script is served over HTTPS from there. Thereby I discovered the following request to. So I launched Burp and started to analyse the HTTP network traffic. However, after LittleSnitch informed me that WineBottler tried to connect to using unsecured HTTP, I got a little skeptical: What is WineBottler downloading from there? I have been using it since many years and I’m pretty happy with it! However this also makes this vulnerability something special: It’s the first time I’m disclosing a vulnerability affecting an OS X application! Here it goes…Ī few weeks ago I thought about using WineBottler (in the current then version 1.8-rc4) – a graphical Wine front-end for OS X – to build myself a KeePass OS X application.