burp-configuration-for-ios.md (15602B)
1 --- 2 title: "iOS Burp Suite Configuration" 3 section: "Mobile" 4 sectionSlug: "mobile-pentesting" 5 sourcePath: "src/mobile-pentesting/ios-pentesting/burp-configuration-for-ios.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/mobile-pentesting/ios-pentesting/burp-configuration-for-ios.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # iOS Burp Suite Configuration 14 15 ## Installing the Burp Certificate on iOS Devices 16 17 For secure web traffic analysis and SSL pinning on iOS devices, the Burp Suite can be utilized either through the **Burp Mobile Assistant** or via manual configuration. Below is a summarized guide on both methods: 18 19 ### Automated Installation with Burp Mobile Assistant 20 21 The **Burp Mobile Assistant** simplifies the installation process of the Burp Certificate, proxy configuration, and SSL Pinning. Detailed guidance can be found on [PortSwigger's official documentation](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing).<sup>[[7]](#references)</sup> 22 23 ### Manual Installation Steps 24 25 1. **Proxy Configuration:** Start by setting Burp as the proxy under the iPhone's Wi-Fi settings. 26 2. **Certificate Download:** Navigate to `http://burp` on your device's browser to download the certificate. 27 3. **Certificate Installation:** Install the downloaded profile via **Settings** > **General** > **VPN & Device Management**, then enable trust for the PortSwigger CA under **Certificate Trust Settings**. 28 29 ### Configuring an Interception Proxy 30 31 The setup enables traffic analysis between the iOS device and the internet through Burp, requiring a Wi-Fi network that supports client-to-client traffic. If unavailable, a USB connection via usbmuxd can serve as an alternative. PortSwigger's tutorials provide in-depth instructions on [device configuration](https://support.portswigger.net/customer/portal/articles/1841108-configuring-an-ios-device-to-work-with-burp) and [certificate installation](https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device).<sup>[[8]](#references)[[9]](#references)</sup> 32 33 ### Transparent Proxying via OpenVPN + `iptables` REDIRECT 34 35 If the target app ignores the configured HTTP proxy, an alternative is to place the iOS device behind a **researcher-controlled VPN gateway** and transparently redirect the traffic into Burp or `mitmproxy`.<sup>[[3]](#references)</sup> 36 37 This is **not a certificate pinning bypass by itself**. It only solves the network plumbing so the device traffic reaches your interception proxy without configuring a per-app or per-device proxy. If the app performs real certificate pinning, HTTPS decryption will still fail until pinning is bypassed separately. 38 39 Typical flow: 40 41 1. Run an **OpenVPN** server on a Linux host and connect the iOS device so its traffic arrives on `tun0`. 42 2. Bind Burp or `mitmproxy` to the VPN listener IP on port `8080`. 43 3. Enable **invisible proxying** in Burp because redirected clients are not proxy-aware and will talk as if they were connecting directly to the destination.<sup>[[4]](#references)</sup> 44 4. Redirect TCP `80` and `443` arriving on `tun0` to the local proxy listener. 45 5. Add a `POSTROUTING` **MASQUERADE** rule on the egress interface so proxied traffic can leave the gateway and replies return through the VPN. 46 6. Install and trust the interception proxy CA on the iOS device so apps that rely only on the system trust store accept the generated leaf certificates. 47 48 Example rules: 49 50 ```bash 51 # Redirect VPN client traffic into the local interception proxy 52 iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 80 -j REDIRECT --to-ports 8080 53 iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 443 -j REDIRECT --to-ports 8080 54 55 # Allow VPN client traffic to egress back to the Internet 56 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE 57 ``` 58 59 Notes: 60 61 - This is useful when you want **forced interception** without changing the target app or configuring an explicit proxy in iOS Wi-Fi settings. 62 - Redirecting `443` to Burp only works for apps that trust the installed CA or for apps where TLS validation / pinning has already been bypassed. 63 - The upstream repository example script takes an IP and appends `/24` in the `POSTROUTING` rule. In practice, use the **actual VPN client subnet** instead of assuming a fixed `/24`. 64 - If you use Burp, enable **Proxy --> Options --> Edit listener --> Request handling --> Support invisible proxying**. 65 - `mitmproxy` can be used in the same layout if it is bound to the VPN listener IP and transparent-mode requirements are satisfied. 66 67 ### Transparent Proxying via MikroTik RouterOS `dst-nat` 68 69 If you control the **wireless router**, you can transparently force a test phone, tablet, or IoT device through Burp without configuring a manual proxy on the client. This is useful when the app **ignores system proxy settings**, is **not proxy-aware**, or the device does not expose any proxy configuration at all.<sup>[[5]](#references)</sup> 70 71 This is still **not a certificate pinning bypass**. It only forces the TCP flow through Burp. HTTPS interception still requires the Burp CA to be trusted by the device, and pinned apps will still reject the MITM until pinning is bypassed separately. 72 73 Typical layout: 74 75 1. The **MikroTik** hosts the test Wi-Fi and provides Internet access. 76 2. The **tester laptop** joins the same Wi-Fi and runs Burp on its LAN IP (for example `192.168.23.10:8123`). 77 3. The **target device** also joins that Wi-Fi and is added to a RouterOS **address list** such as `Proxy me!`. 78 4. A `dstnat` rule redirects the selected client's TCP `80,443` traffic to the Burp listener. 79 5. A second NAT rule **masquerades** traffic destined to the Burp listener so RouterOS connection tracking keeps the return path stable. 80 6. If the device has IPv6 connectivity, **block or separately intercept IPv6**, otherwise it may bypass your IPv4-only NAT rules. 81 82 Burp listener requirements: 83 84 - Bind the listener to the **laptop LAN IP** on the MikroTik network, not only to `127.0.0.1`. 85 - Enable **Support invisible proxying** because redirected clients are not sending explicit proxy requests.<sup>[[4]](#references)</sup> 86 87 Example RouterOS rules: 88 89 ```bash 90 # Address list entry (can be kept disabled until needed) 91 /ip firewall address-list add list="Proxy me!" address=192.168.23.50 comment="iPad" disabled=yes 92 93 # Redirect HTTP/HTTPS from listed clients into Burp 94 /ip firewall nat add chain=dstnat src-address-list="Proxy me!" protocol=tcp dst-port=80,443 action=dst-nat to-addresses=192.168.23.10 to-ports=8123 95 96 # Masquerade packets sent to Burp so replies map back to the original client 97 /ip firewall nat add chain=srcnat protocol=tcp dst-address=192.168.23.10 dst-port=8123 action=masquerade 98 ``` 99 100 Operational notes: 101 102 - Enabling/disabling the address-list entry becomes a **one-click interception toggle**. 103 - This works well for **plain HTTP**, **HTTPS apps that trust your CA**, **non-proxy-aware apps**, and **low-level OS traffic** that would normally miss a manually configured proxy. 104 - This only catches traffic matching the NAT rule. If the app moves to **QUIC/UDP**, other TCP ports, or **IPv6**, add blocking or extra interception rules as needed. 105 106 ### Automating the RouterOS toggle via REST API 107 108 RouterOS exposes a REST API on the management web server, so the interception toggle can be scripted.<sup>[[6]](#references)</sup> A practical pattern is to identify the address-list entry by its comment and then patch its `disabled` property.<sup>[[5]](#references)</sup> 109 110 ```bash 111 ID=$(curl -s -u admin:yourpass \ 112 -X GET 'https://192.168.23.1/rest/ip/firewall/address-list' \ 113 -H 'Content-Type: application/json' \ 114 | jq -r '.[] | select(.comment == "iPad") | .[".id"]') 115 116 curl -k -u admin:yourpass \ 117 -X PATCH "https://192.168.23.1/rest/ip/firewall/address-list/$ID" \ 118 -H 'Content-Type: application/json' \ 119 --data '{ "disabled": "false" }' 120 ``` 121 122 This makes it easy to wire the toggle into a shell script, hotkey, hardware button, or test harness. 123 124 ### Flutter iOS apps that ignore the system proxy 125 126 Some **Flutter-based iOS applications** do not send traffic through the usual iOS Wi-Fi proxy settings because their networking lives inside **Dart `HttpClient` / BoringSSL** instead of the common native `NSURLSession` stack. In that situation, installing the Burp CA and configuring the Wi-Fi proxy can fail even on **non-jailbroken** devices.<sup>[[1]](#references)</sup> 127 128 A practical workaround is to move interception **below the app proxy layer** and force the traffic through a **VPN-style proxy app** (for example, **Potatso**) that forwards device traffic to Burp. This recovers visibility when the app bypasses the explicit proxy configuration, but it is still **not a universal certificate-pinning bypass**: if the Flutter app performs hardcoded certificate/public-key validation, you will still need patching or instrumentation. 129 130 Typical workflow: 131 132 1. First try the normal iOS Wi-Fi proxy + trusted Burp CA setup. 133 2. If the Flutter app still does not appear in Burp, create a **manual HTTP proxy profile** in Potatso pointing to your Burp listener: 134 135 ```text 136 Type: HTTP 137 Host: <Burp listener IP> 138 Port: <Burp listener port> 139 ``` 140 141 3. Connect the device through that Potatso profile so traffic is routed via the VPN/network layer instead of relying on the app to honor iOS proxy settings. 142 4. In Burp, enable **Proxy --> Options --> Edit listener --> Request handling --> Support invisible proxying** on that listener.<sup>[[4]](#references)</sup> 143 5. Relaunch the target Flutter app and confirm whether requests now reach Burp. 144 145 Notes: 146 147 - This is mainly useful for **Flutter apps that ignore the explicit system proxy**; it complements, but does not replace, CA installation and classic SSL-pinning bypasses. 148 - Potatso currently supports **manual HTTP(S)/SOCKS-style upstream proxy definitions** and, per the App Store listing used for this note, **requires iOS 17.0 or later**.<sup>[[2]](#references)</sup> 149 - If the target device runs an older iOS release, the technique still applies conceptually with any equivalent **VPN-based transparent forwarding tool** that can send device traffic to Burp/mitmproxy. 150 - Burp invisible proxying matters here because the traffic is **transparently redirected**, so the client is not behaving like a normal proxy-aware browser. 151 152 153 ### Advanced Configuration for Jailbroken Devices 154 155 For users with jailbroken devices, SSH over USB (via **iproxy**) offers a method to route traffic directly through Burp: 156 157 1. **Establish SSH Connection:** Use iproxy to forward SSH to localhost, allowing connection from the iOS device to the computer running Burp. 158 159 ```bash 160 iproxy 2222 22 161 ``` 162 163 2. **Remote Port Forwarding:** Forward the iOS device's port 8080 to the computer's localhost to enable direct access to Burp's interface. 164 165 ```bash 166 ssh -R 8080:localhost:8080 root@localhost -p 2222 167 ``` 168 169 3. **Global Proxy Setting:** Lastly, configure the iOS device's Wi-Fi settings to use a manual proxy, directing all web traffic through Burp. 170 171 ### Full Network Monitoring/Sniffing 172 173 Monitoring of non-HTTP device traffic can be efficiently conducted using **Wireshark**, a tool capable of capturing all forms of data traffic. For iOS devices, real-time traffic monitoring is facilitated through the creation of a Remote Virtual Interface, a process detailed in [this Stack Overflow post](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819).<sup>[[10]](#references)</sup> Prior to beginning, installation of **Wireshark** on a macOS system is a prerequisite. 174 175 The procedure involves several key steps: 176 177 1. Initiate a connection between the iOS device and the macOS host via USB. 178 2. Ascertain the iOS device's **UDID**, a necessary step for traffic monitoring. This can be done by executing a command in the macOS Terminal: 179 180 ```bash 181 $ rvictl -s <UDID> 182 Starting device <UDID> [SUCCEEDED] with interface rvi0 183 ``` 184 185 3. Post-identification of the UDID, **Wireshark** is to be opened, and the "rvi0" interface selected for data capture. 186 4. For targeted monitoring, such as capturing HTTP traffic related to a specific IP address, Wireshark's Capture Filters can be employed: 187 188 ## Burp Cert Installation in Simulator 189 190 - **Export Burp Certificate** 191 192 In _Proxy_ --> _Options_ --> _Export CA certificate_ --> _Certificate in DER format_ 193 194  195 196 - **Drag and Drop** the certificate inside the Emulator 197 - **Inside the emulator** go to _Settings_ --> _General_ --> _Profile_ --> _PortSwigger CA_, and **verify the certificate** 198 - **Inside the emulator** go to _Settings_ --> _General_ --> _About_ --> _Certificate Trust Settings_, and **enable PortSwigger CA** 199 200  201 202 **Congrats, you have successfully configured the Burp CA Certificate in the iOS simulator** 203 204 > [!TIP] 205 > **The iOS simulator will use the proxy configurations of the MacOS.** 206 207 ### MacOS Proxy Configuration 208 209 Steps to configure Burp as proxy: 210 211 - Go to _System Preferences_ --> _Network_ --> _Advanced_ 212 - In _Proxies_ tab mark _Web Proxy (HTTP)_ and _Secure Web Proxy (HTTPS)_ 213 - In both options configure _127.0.0.1:8080_ 214 215  216 217 - Click on _**Ok**_ and the in _**Apply**_ 218 219 ## References 220 221 - [1] [Bypassing SSL Pinning in Flutter-Based iOS Applications](https://medium.com/@drhatab/bypassing-ssl-pinning-in-flutter-based-ios-applications-54f420d2f1a1) 222 - [2] [Potatso App Store listing](https://apps.apple.com/us/app/potatso/id1239860606) 223 - [3] [SSL Pinning Bypass for iOS -- iptables](https://github.com/SahilH4ck4you/iOS-SSL-pinning-bypass-without-jalibreak) 224 - [4] [Invisible proxying - PortSwigger](https://portswigger.net/burp/documentation/desktop/tools/proxy/invisible) 225 - [5] [Mobile device interception with MikroTik](https://sensepost.com/blog/2026/mobile-device-interception-with-mikrotik/) 226 - [6] [MikroTik RouterOS REST API](https://manual.mikrotik.com/docs/developer-guides/rest-api) 227 - [7] [Installing Burp's CA certificate with the Burp Mobile Assistant - PortSwigger](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing) 228 - [8] [Configuring an iOS device to work with Burp - PortSwigger](https://support.portswigger.net/customer/portal/articles/1841108-configuring-an-ios-device-to-work-with-burp) 229 - [9] [Installing Burp's CA certificate in an iOS device - PortSwigger](https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device) 230 - [10] [Capturing mobile phone traffic on Wireshark - Stack Overflow](https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark/33175819#33175819)