update

Author: firefart

.github/workflows/codeql.yml

@@ -37,38 +37,38 @@ jobs:
         # Learn more about CodeQL language support at https://git.io/codeql-language-support
 
     steps:
-    - name: Checkout repository
-      uses: actions/checkout@v4
+      - name: Checkout repository
+        uses: actions/checkout@v4
 
-    - uses: actions/setup-go@v5
-      with:
-        go-version: "stable"
+      - uses: actions/setup-go@v5
+        with:
+          go-version: "stable"
 
-    # Initializes the CodeQL tools for scanning.
-    - name: Initialize CodeQL
-      uses: github/codeql-action/init@v3
-      with:
-        languages: ${{ matrix.language }}
-        # If you wish to specify custom queries, you can do so here or in a config file.
-        # By default, queries listed here will override any specified in a config file.
-        # Prefix the list here with "+" to use these queries and those in the config file.
-        # queries: ./path/to/local/query, your-org/your-repo/queries@main
+      # Initializes the CodeQL tools for scanning.
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v3
+        with:
+          languages: ${{ matrix.language }}
+          # If you wish to specify custom queries, you can do so here or in a config file.
+          # By default, queries listed here will override any specified in a config file.
+          # Prefix the list here with "+" to use these queries and those in the config file.
+          # queries: ./path/to/local/query, your-org/your-repo/queries@main
 
-    # Autobuild attempts to build any compiled languages  (C/C++, C#, or Java).
-    # If this step fails, then you should remove it and run the build manually (see below)
-    - name: Autobuild
-      uses: github/codeql-action/autobuild@v3
+      # Autobuild attempts to build any compiled languages  (C/C++, C#, or Java).
+      # If this step fails, then you should remove it and run the build manually (see below)
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v3
 
-    # ℹ️ Command-line programs to run using the OS shell.
-    # 📚 https://git.io/JvXDl
+      # ℹ️ Command-line programs to run using the OS shell.
+      # 📚 https://git.io/JvXDl
 
-    # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines
-    #    and modify them (or add more) to build your code if your project
-    #    uses a compiled language
+      # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines
+      #    and modify them (or add more) to build your code if your project
+      #    uses a compiled language
 
-    #- run: |
-    #   make bootstrap
-    #   make release
+      #- run: |
+      #   make bootstrap
+      #   make release
 
-    - name: Perform CodeQL Analysis
-      uses: github/codeql-action/analyze@v3
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v3

.github/workflows/go.yml

@@ -1,5 +1,5 @@
 name: Go
-on: [push, pull_request]
+on: [ push, pull_request ]
 jobs:
   build:
     name: Build

.github/workflows/golangci-lint.yml

@@ -1,5 +1,5 @@
 name: golangci-lint
-on: [push, workflow_dispatch]
+on: [ push, workflow_dispatch ]
 jobs:
   golangci:
     name: lint

.idea/.gitignore

@@ -3,15 +3,21 @@
 Stunner is a tool to test and exploit STUN, TURN and TURN over TCP servers.
 TURN is a protocol mostly used in videoconferencing and audio chats (WebRTC).
 
-If you find a misconfigured server you can use this tool to open a local socks proxy that relays all traffic via the TURN protocol into the internal network behind the server.
+If you find a misconfigured server you can use this tool to open a local socks proxy that relays all traffic via the
+TURN protocol into the internal network behind the server.
 
-I developed this tool during a test of Cisco Expressway which resulted in some vulnerabilities: [https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/](https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/)
+I developed this tool during a test of Cisco Expressway which resulted in some
+vulnerabilities: [https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/](https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/)
 
-To get the required username and password you need to fetch them using an out-of-band method like sniffing the Connect request from a web browser with Burp. I added an [example workflow](#example-workflow) at the bottom of the readme on how you would test such a server.
+To get the required username and password you need to fetch them using an out-of-band method like sniffing the Connect
+request from a web browser with Burp. I added an [example workflow](#example-workflow) at the bottom of the readme on
+how you would test such a server.
 
 # LICENSE
 
-This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
+This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view
+a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/ or send a letter to Creative Commons, PO
+Box 1866, Mountain View, CA 94042, USA.
 
 # implemented RFCs
 
@@ -27,7 +33,8 @@ TURN Extension for IPv6: [RFC 6156](https://datatracker.ietf.org/doc/html/rfc615
 
 ## info
 
-This command will print some info about the stun or turn server like supported protocols and attributes like the used software.
+This command will print some info about the stun or turn server like supported protocols and attributes like the used
+software.
 
 ### Options
 
@@ -47,7 +54,9 @@ This command will print some info about the stun or turn server like supported p
 
 ## range-scan
 
-This command tries several private and restricted ranges to see if the TURN server is configured to allow connections to the specified IP addresses. If a specific range is not prohibited you can enumerate this range further with the other provided commands. If an ip is reachable it means the TURN server will forward traffic to this IP.
+This command tries several private and restricted ranges to see if the TURN server is configured to allow connections to
+the specified IP addresses. If a specific range is not prohibited you can enumerate this range further with the other
+provided commands. If an ip is reachable it means the TURN server will forward traffic to this IP.
 
 ### Options
 
@@ -78,7 +87,12 @@ UDP based TURN connection (connection from you the TURN server):
 
 ## socks
 
-This is one of the most useful commands for TURN servers that support TCP connections to backend servers. It will launch a local socks5 server with no authentication and will relay all TCP traffic over the TURN protocol (UDP via SOCKS is currently not supported). If the server is misconfuigured it will forward the traffic to internal adresses so this can be used to reach internal systems and abuse the server as a proxy into the internal network. If you choose to also do DNS lookups over socks, it will be resolved using your local nameserver so it's best to work with private IPv4 and IPv6 addresses. Please be aware that this module can only relay TCP traffic.
+This is one of the most useful commands for TURN servers that support TCP connections to backend servers. It will launch
+a local socks5 server with no authentication and will relay all TCP traffic over the TURN protocol (UDP via SOCKS is
+currently not supported). If the server is misconfuigured it will forward the traffic to internal adresses so this can
+be used to reach internal systems and abuse the server as a proxy into the internal network. If you choose to also do
+DNS lookups over socks, it will be resolved using your local nameserver so it's best to work with private IPv4 and IPv6
+addresses. Please be aware that this module can only relay TCP traffic.
 
 ### Options
 
@@ -101,21 +115,29 @@ This is one of the most useful commands for TURN servers that support TCP connec
 ./stunner socks -s x.x.x.x:3478 -u username -p password -x
 ```
 
-After starting the proxy open your browser, point the proxy in your settings to socks5 with an ip of 127.0.0.1:1080 (be sure to not set the bypass local address option as we want to reach the remote local addresses) and call the IP of your choice in the browser.
+After starting the proxy open your browser, point the proxy in your settings to socks5 with an ip of 127.0.0.1:1080 (be
+sure to not set the bypass local address option as we want to reach the remote local addresses) and call the IP of your
+choice in the browser.
 
-Example: https://127.0.0.1, https://127.0.0.1:8443 or https://[::1]:8443 (those will call the ports on the tested TURN server from the local interfaces).
+Example: https://127.0.0.1, https://127.0.0.1:8443 or https://[::1]:8443 (those will call the ports on the tested TURN
+server from the local interfaces).
 
-You can also configure `proxychains` to use this proxy (but it will be very slow as each request results in multiple requests to enable the proxying). Just edit `/etc/proxychains.conf` and enter the value `socks5 127.0.0.1 1080` under `ProxyList`.
+You can also configure `proxychains` to use this proxy (but it will be very slow as each request results in multiple
+requests to enable the proxying). Just edit `/etc/proxychains.conf` and enter the value `socks5 127.0.0.1 1080` under
+`ProxyList`.
 
-Example of nmap over this socks5 proxy with a correct configured proxychains (note it's -sT to do TCP syns otherwise it will not use the socks5 proxy)
+Example of nmap over this socks5 proxy with a correct configured proxychains (note it's -sT to do TCP syns otherwise it
+will not use the socks5 proxy)
 
 ```bash
 sudo proxychains nmap -sT -p 80,443,8443 -sV 127.0.0.1
 ```
 
 ## brute-transports
 
-This will most likely yield no useable information but can be useful to enumerate all available transports (=protocols to internal systems) supported by the server. This might show some custom protocol implementations but mostly will only return the defaults.
+This will most likely yield no useable information but can be useful to enumerate all available transports (=protocols
+to internal systems) supported by the server. This might show some custom protocol implementations but mostly will only
+return the defaults.
 
 ### Options
 
@@ -138,7 +160,8 @@ This will most likely yield no useable information but can be useful to enumerat
 
 ## brute-password
 
-This command tries all passwords from a given file for a username via the TURN protocol (UDP). This can be useful when analysing a pcap where you can see the username but not the password.
+This command tries all passwords from a given file for a username via the TURN protocol (UDP). This can be useful when
+analysing a pcap where you can see the username but not the password.
 Please note that an offline bruteforce is much more faster in this case.
 
 ### Options
@@ -163,7 +186,10 @@ Please note that an offline bruteforce is much more faster in this case.
 ## memoryleak
 
 This attack works the following way:
-The server takes the data to send to `target` (must be a high port > 1024 in most cases) as a TLV (Type Length Value). This exploit uses a big length with a short value. If the server does not check the boundaries of the TLV, it might send you some memory up the `length` to the `target`. Cisco Expressway was confirmed vulnerable to this but according to cisco it only leaked memory of the current session.
+The server takes the data to send to `target` (must be a high port > 1024 in most cases) as a TLV (Type Length Value).
+This exploit uses a big length with a short value. If the server does not check the boundaries of the TLV, it might send
+you some memory up the `length` to the `target`. Cisco Expressway was confirmed vulnerable to this but according to
+cisco it only leaked memory of the current session.
 
 ### Options
 
@@ -182,8 +208,9 @@ The server takes the data to send to `target` (must be a high port > 1024 in mos
 
 ### Example
 
-To receive the data we need to set up a receiver on a server with a public ip. Normally firewalls are configured to only allow highports (>1024) from TURN servers so be sure to use a high port like 8080 in this example when connecting out to the internet.
-
+To receive the data we need to set up a receiver on a server with a public ip. Normally firewalls are configured to only
+allow highports (>1024) from TURN servers so be sure to use a high port like 8080 in this example when connecting out to
+the internet.
 
 ```bash
 sudo nc -u -l -n -v -p 8080 | hexdump -C
@@ -199,7 +226,10 @@ If it works you should see big loads of memory coming in, otherwise you will onl
 
 ## udp-scanner
 
-If a TURN server allows UDP connections to targets this scanner can be used to scan all private ip ranges and send them SNMP and DNS requests. As this checks a lot of IPs this can take multiple days to complete so use with caution or specify smaller targets via the parameters. You need to supply a SNMP community string that will be tried and a domain name that will be resolved on each IP. For the domain name you can for example use burp collaborator.
+If a TURN server allows UDP connections to targets this scanner can be used to scan all private ip ranges and send them
+SNMP and DNS requests. As this checks a lot of IPs this can take multiple days to complete so use with caution or
+specify smaller targets via the parameters. You need to supply a SNMP community string that will be tried and a domain
+name that will be resolved on each IP. For the domain name you can for example use burp collaborator.
 
 ### Options
 
@@ -252,10 +282,22 @@ Same as `udp-scanner` but sends out HTTP requests to the specified ports (HTTPS
 
 Let's say you find a service using WebRTC and want to test it.
 
-First step is to get the required data. I suggest to launch Wireshark in the background and just join a meeting via Burp to collect all HTTP and Websocket traffic. Next search your burp history for some keywords related to TURN like `3478`, `password`, `credential` and `username` (be sure to also check the websocket tab for these keywords). This might reveal the turn server and the protocol (UDP and TCP endpoints might have different ports) and the credentials used to connect. If you can't find the data in burp start looking at wireshark to identify the traffic. If it's on a non standard port (anything else then 3478) decode the protocol in Wireshark via a right click as `STUN`. This should show you the username used to connect and you can use this information to search burps history even further for the required data. Please note that Wireshark can't show you the password as the password is used to hash some package contents so it can not be reversed.
-
-Next step would be to issue the `info` command to the turn server using the correct port and protocol obtained from burp.
-
-If this works, the next step is a `range-scan`. If this allows any traffic to internal systems you can exploit this further but be aware that UDP has only limited use cases.
-
-If TCP connections to internal systems are allowed simply launch the `socks` command and access the allowed IPs via a browser and set the socks proxy to 127.0.0.1:1080. You can try out 127.0.0.1:443 and other ips to find management interfaces.
+First step is to get the required data. I suggest to launch Wireshark in the background and just join a meeting via Burp
+to collect all HTTP and Websocket traffic. Next search your burp history for some keywords related to TURN like `3478`,
+`password`, `credential` and `username` (be sure to also check the websocket tab for these keywords). This might reveal
+the turn server and the protocol (UDP and TCP endpoints might have different ports) and the credentials used to connect.
+If you can't find the data in burp start looking at wireshark to identify the traffic. If it's on a non standard port (
+anything else then 3478) decode the protocol in Wireshark via a right click as `STUN`. This should show you the username
+used to connect and you can use this information to search burps history even further for the required data. Please note
+that Wireshark can't show you the password as the password is used to hash some package contents so it can not be
+reversed.
+
+Next step would be to issue the `info` command to the turn server using the correct port and protocol obtained from
+burp.
+
+If this works, the next step is a `range-scan`. If this allows any traffic to internal systems you can exploit this
+further but be aware that UDP has only limited use cases.
+
+If TCP connections to internal systems are allowed simply launch the `socks` command and access the allowed IPs via a
+browser and set the socks proxy to 127.0.0.1:1080. You can try out 127.0.0.1:443 and other ips to find management
+interfaces.

.idea/modules.xml

@@ -13,7 +13,7 @@ tasks:
       - go mod tidy -v
 
   build:
-    aliases: [default]
+    aliases: [ default ]
     cmds:
       - go fmt ./...
       - go vet ./...