Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp with Azure iotedge

floyd | Last updated: Oct 02, 2023 09:58AM UTC

I tried to use Burp with an Azure IOT edge client. It's a special kind of software that is for example installed on a VM that should talk to Azure. Of course it talks HTTP/HTTPS and even supports proxying. However, I couldn't make it work with Burpsuite. What I tried: Configure Proxy according to https://learn.microsoft.com/en-us/azure/iot-edge/how-to-configure-proxy-support?view=iotedge-1.4 Additionally, I also installed the certificate in the CA root store of the Ubuntu VM and for IOT edge according to https://learn.microsoft.com/en-us/azure/iot-edge/how-to-manage-device-certificates?view=iotedge-1.4&tabs=ubuntu . I also added an additional transparent proxy listening port 443 and an entry for my REDACTED-REDACTED.azure-devices.net in /etc/hosts that points to that IP. Just to make sure if that there would be any non-proxy aware connection I would see it (but this steps seems unnecessary as the client supports proxying). At first this looked promising, the proxy configuration seemed to have worked and the TLS certificate was accepted: GET /devices/REDACTED-REDACTED/modules?api-version=2017-11-08-preview HTTP/1.1 authorization: SharedAccessSignature sr=REDACTED-REDACTED.azure-devices.net/devices/REDACTED-REDACTED&sig=REDACTED%3D&se=REDACTED host: REDACTED-REDACTED.azure-devices.net Connection: close And I also got a response back just fine. However, I found out that AMQP is directly connecting to a TCP port on Azure, but also supports proxying via Websockets, so I did as explained on the Microsoft website: "UpstreamProtocol" = "AmqpWs" However, then I only see the following request/response where the VM seems to be stuck: GET /$iothub/websocket HTTP/1.1 Host: REDACTED-REDACTED.azure-devices.net Connection: Upgrade Upgrade: websocket Sec-WebSocket-Version: 13 Sec-WebSocket-Key: REDACTED Sec-WebSocket-Protocol: AMQPWSB10 HTTP/1.1 101 Switching Protocols Upgrade: websocket Server: Microsoft-HTTPAPI/2.0 Sec-WebSocket-Protocol: AMQPWSB10 Connection: close Sec-WebSocket-Accept: REDACTED Date: Mon, 02 Oct 2023 09:47:44 GMT But this is repeated over and over and it doesn't work, there is no Websocket connection in the Websocket tab of Burp. There are also Burp Dashboard errors: [6] The client failed to negotiate a TLS connection to, REDACTED-REDACTED-REDACTED.azure-devices.net:443: Insufficient buffer remaining for AEAD, cipher fragment (2). Needs to be more than tag size (16) Here's what the status on the VM says: $ sudo iotedge check Configuration checks (aziot-identity-service) --------------------------------------------- √ keyd configuration is well-formed - OK √ certd configuration is well-formed - OK √ tpmd configuration is well-formed - OK √ identityd configuration is well-formed - OK √ daemon configurations up-to-date with config.toml - OK √ identityd config toml file specifies a valid hostname - OK ‼ aziot-identity-service package is up-to-date - Warning Installed aziot-identity-service package has version 1.4.5 but 1.4.6 is the latest stable version available. Please see https://aka.ms/aziot-update-runtime for update instructions. √ host time is close to reference time - OK √ preloaded certificates are valid - OK √ keyd is running - OK √ certd is running - OK √ identityd is running - OK √ read all preloaded certificates from the Certificates Service - OK √ read all preloaded key pairs from the Keys Service - OK √ check all EST server URLs utilize HTTPS - OK √ ensure all preloaded certificates match preloaded private keys with the same ID - OK Connectivity checks (aziot-identity-service) -------------------------------------------- × host can connect to and perform TLS handshake with iothub AMQP port - Error Could not connect to REDACTED-REDACTED.azure-devices.net : could not complete TLS handshake √ host can connect to and perform TLS handshake with iothub HTTPS / WebSockets port - OK × host can connect to and perform TLS handshake with iothub MQTT port - Error Could not connect to REDACTED-REDACTED.azure-devices.net : could not complete TLS handshake Configuration checks -------------------- √ aziot-edged configuration is well-formed - OK √ configuration up-to-date with config.toml - OK √ container engine is installed and functional - OK √ configuration has correct URIs for daemon mgmt endpoint - OK ‼ aziot-edge package is up-to-date - Warning Installed IoT Edge daemon has version 1.4.16 but 1.4.20 is the latest stable version available. Please see https://aka.ms/iotedge-update-runtime for update instructions. √ container time is close to host time - OK ‼ DNS server - Warning Container engine is not configured with DNS server setting, which may impact connectivity to IoT Hub. Please see https://aka.ms/iotedge-prod-checklist-dns for best practices. You can ignore this warning if you are setting DNS server per module in the Edge deployment. ‼ production readiness: logs policy - Warning Container engine is not configured to rotate module logs which may cause it run out of disk space. Please see https://aka.ms/iotedge-prod-checklist-logs for best practices. You can ignore this warning if you are setting log policy per module in the Edge deployment. ‼ production readiness: Edge Agent's storage directory is persisted on the host filesystem - Warning The edgeAgent module is not configured to persist its /tmp/edgeAgent directory on the host filesystem. Data might be lost if the module is deleted or updated. Please see https://aka.ms/iotedge-storage-host for best practices. ‼ production readiness: Edge Hub's storage directory is persisted on the host filesystem - Warning The edgeHub module is not configured to persist its /tmp/edgeHub directory on the host filesystem. Data might be lost if the module is deleted or updated. Please see https://aka.ms/iotedge-storage-host for best practices. √ Agent image is valid and can be pulled from upstream - OK ‼ proxy settings are consistent in aziot-edged, aziot-identityd, moby daemon and config.toml - Warning The proxy setting for IoT Edge Agent "http://192.168.183.11:8888", IoT Edge Daemon "http://192.168.183.11:8888", IoT Identity Daemon "", and Moby "" may need to be identical. Connectivity checks ------------------- √ container on the default network can connect to upstream AMQP port - OK × container on the default network can connect to upstream HTTPS / WebSockets port - Error Container on the default network could not connect to REDACTED-REDACTED.azure-devices.net:443 √ container on the default network can connect to upstream MQTT port - OK × container on the IoT Edge module network can connect to upstream AMQP port - Error Container on the azure-iot-edge network could not connect to REDACTED-REDACTED.azure-devices.net:5671 × container on the IoT Edge module network can connect to upstream HTTPS / WebSockets port - Error Container on the azure-iot-edge network could not connect to REDACTED-REDACTED.azure-devices.net:443 × container on the IoT Edge module network can connect to upstream MQTT port - Error Container on the azure-iot-edge network could not connect to REDACTED-REDACTED.azure-devices.net:8883 24 check(s) succeeded. 7 check(s) raised warnings. Re-run with --verbose for more details. 6 check(s) raised errors. Re-run with --verbose for more details. Have you every tried this? Any idea on why the Websocket part does not work?

Dominyque, PortSwigger Agent | Last updated: Oct 02, 2023 12:39PM UTC

Hi Floyd Can you please email support@portswigger.net with the following: 1) Could you send me your diagnostics information? You can find this by going to "Help > Diagnostics" within Burp. 2) Screenshots of the event log (with the debug filter enabled) when you encounter the error 3) Screenshots of your TLS settings and any upstream proxies you have set.

floyd | Last updated: Oct 02, 2023 04:17PM UTC

TL;DR: I fixed it. The setting 'Set response header "Connection: close"' completely breaks the WebSocket feature in Burp (I can see why...). There is no warning on the setting, there is no warning in the Dashboard (you could monitor for "HTTP/1.1 101 Switching Protocols" responses and alert the user if the settings is on). Please change this and put a warning on this setting! Here's the full story: I just wanted to send it to you when I realized that would have been useless, because I looked at the information and there was nothing suspicious in it. Additionally, as an extension developer I know that my custom extensions would be blamed for any bugs. So once again, I thought I'll give it a go and tried to produce a minimize reproduced. I think this is how you should tell people to debug Burp. For every step, check if the problem persist. If it persists you know where the problem is (this only works for Burp Pro because otherwise you don't have projects): 1) Double check for stupid things such as upstream proxy settings, Interception being turned on, scope incorrectly set, etc. 2) Disable DOMInvader in the Burp browser (eval hooking might break the website) 3) Unload extensions. 4) Close Burp and reopen the project. 5) Close Burp, start Burp from the command line and reopen the project. Check if there are errors on the command line when you load your Burp project. 6) Configure your "Scope" in the project to only include the problematic area. Go to "Project - Save copy". Enable "Save in-scope items only". 7) Empty your scope and set your scope to something you haven't requested (e.g. https://example.org). Repeat step 4 but this time, do not tick any of the tools! Enable "Save in-scope items only". This actually means you are creating a project that is empty, but your project settings are in there. The funny part is that's actually not true, there are still some requests in there (I guess depending on extensions you've used). 8) In your empty project, go to "Settings - Proxy - Miscellaneous" and use the "Restore defaults" option. 9) Repeat step 6 with all possible settings. That's how I figured it out in step 8.

floyd | Last updated: Oct 03, 2023 08:33AM UTC

To be fair, I'm the idiot because there is https://portswigger.net/burp/documentation/desktop/troubleshooting/troubleshooting that would have found the issue with step 7

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.