search

PortSwigger / http-request-smuggler

https://portswigger.net/blog/http-desync-attacks
Other
952 stars 101 forks source link

Problems with x509 client auth #62

Closed drwetter closed 1 year ago

drwetter commented 1 year ago

Hi,

thanks for the HTTP request smuggling extension which I use frequently.

Recently I was testing an mTLS enabled API from a customer. In order to get to the destination IP I had to tunnel all requests to a SOCKS proxy (via SSH).

However I had a problem executing the majority of requests when choosing a POST Request ==> Extensions --> HTTP Request Smuggler --> Launch all scans. They timed out like (output tab):

    Updating active thread pool size to 8
    Loop 0
    Queued 1 attacks from 1 requests in 0 seconds
    Kicking off request scans
    Queueing reuest scan: Header removal
    Queueing reuest scan: CL.0
    Queueing reuest scan: Client-side desync
    Thread failed to connect
    Thread failed to connect
    Queueing reuest scan: Pause-based desync
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
    Thread failed to connect
[..]

Logger++ showed me like ~9 requests only, Also I got a Java errors in the output tab like

Thread-29
    native=true, suspended=false, block=0, wait=6
    lock=null owned by null (-1), cpu=4, user=0
    [java.base@17.0.7/sun.nio.ch.Net.connect0](mailto:java.base@17.0.7/sun.nio.ch.Net.connect0)(Native Method)
    [java.base@17.0.7/sun.nio.ch.Net.connect](mailto:java.base@17.0.7/sun.nio.ch.Net.connect)(Net.java:596)
    [java.base@17.0.7/sun.nio.ch.Net.connect](mailto:java.base@17.0.7/sun.nio.ch.Net.connect)(Net.java:585)
    [java.base@17.0.7/sun.nio.ch.NioSocketImpl.connect](mailto:java.base@17.0.7/sun.nio.ch.NioSocketImpl.connect)(NioSocketImpl.java:588)
    [java.base@17.0.7/java.net.SocksSocketImpl.connect](mailto:java.base@17.0.7/java.net.SocksSocketImpl.connect)(SocksSocketImpl.java:327)
    [java.base@17.0.7/java.net.Socket.connect](mailto:java.base@17.0.7/java.net.Socket.connect)(Socket.java:633)
    [java.base@17.0.7/sun.security.ssl.SSLSocketImpl.connect](mailto:java.base@17.0.7/sun.security.ssl.SSLSocketImpl.connect)(SSLSocketImpl.java:304)
    [java.base@17.0.7/sun.security.ssl.SSLSocketImpl](mailto:java.base@17.0.7/sun.security.ssl.SSLSocketImpl).<init>(SSLSocketImpl.java:184)

    [java.base@17.0.7/sun.security.ssl.SSLSocketFactoryImpl.createSocket](mailto:java.base@17.0.7/sun.security.ssl.SSLSocketFactoryImpl.createSocket)(SSLSocketFactoryImpl.java:137)
    burp.ThreadedRequestEngine.sendRequests(ThreadedRequestEngine.kt:143)
    burp.ThreadedRequestEngine.access$sendRequests(ThreadedRequestEngine.kt:17)
    burp.ThreadedRequestEngine$1.invoke(ThreadedRequestEngine.kt:50)
    burp.ThreadedRequestEngine$1.invoke(ThreadedRequestEngine.kt:49)
    kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)

Intruder, proxy, repeater and all standard requests worked fine. Also as far as I saw extensions. The JDK was from a Linux distro. Above. In order to exclude probs with the JDK I was using I also used the full BurpPro downloads including Java 19 on Linux and Mac and there was no difference I noticed.

The client certificate I used imported just fine:

image

The file a was able to export using Burp looked fine too:

[
[
  Version: V3
  Subject: CN=Dirk Wetter, OU=REDACTED Staging, O=REDACTED GmbH, L=Hamburg, ST=Hamburg, C=DE
  Signature Algorithm: SHA512withRSA, OID = 1.2.840.113549.1.1.13

  Key:  Sun RSA public key, 2048 bits
  params: null
  modulus: 23861147390845856260098616939018666338199764841098197713674305436345953983290495704853931905064175903164610812351074983903010493456663241815550334098692875949561965930827790031179927982836328735603045503389534698448408197056837601027821367904848003986470139651949072303568291129966418090306478455227010808030068961437642118696546342951561630394294709199881505142992615419879953357552905401370491266907654100726173267098315583626682894982112492873297608943873851522445034508794560295318346482674023731522463862537603952261823391927779444078666746146833310986136981851867105910755390256100750719890869627596634982514189
  public exponent: 65537
  Validity: [From: Thu Jun 08 14:54:00 CEST 2023,
               To: Sat Jun 07 14:54:00 CEST 2025]
  Issuer: CN=REDACTED Test Sender Intermediate CA G01, O=REDACTED GmbH, L=Hamburg, C=DE
  SerialNumber: [    0339fb08 4021e644 01a376bf b85bfe2f 71f9bf9c]

Certificate Extensions: 6
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 72 67 D8 A6 F6 CB BA 96   F2 F0 55 A2 B9 7C F2 C5  rg........U.....
0010: C5 34 D0 5B                                        .4.[
]
]

[2]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:false
  PathLen: undefined
[..]

As a baseline I tried to scan a node with Nginx and Apache, both requiring not a client certificate and it worked fine. Apache threw some similar SSLSocketFactory stack traces and a few requests timed out but Logger++ showed >~600 requests instead of 9.

I filed this also with support (06ff6abde82f6f666e16:6ndi). As requested by support I am filing the issue also here.

Thanks, Dirk

PS: I don't have access to the server requiring the certificate anymore.

albinowax commented 1 year ago

Unfortunately this is expected behaviour. Some request smuggler checks have to use Turbo Intruder's network stack (ThreadedRequestEngine). This stack doesn't support any of Burp's settings, including client TLS and SOCKS proxying.