Lucky13: MissingCommandException: Expected a command, got lucky13

[drwetter]

What did I do wrong?

host:~/TLS-Attacker/apps|% java -jar Attacks.jar poodle -connect localhost:4433
16:40:11 [main] INFO  attacks.Main - Vulnerable:true
host:~/TLS-Attacker/apps|% java -jar Attacks.jar lucky13 -connect localhost:4433 
Exception in thread "main" com.beust.jcommander.MissingCommandException: Expected a command, got lucky13
        at com.beust.jcommander.JCommander.parseValues(JCommander.java:730)
        at com.beust.jcommander.JCommander.parse(JCommander.java:312)
        at com.beust.jcommander.JCommander.parse(JCommander.java:291)
        at de.rub.nds.tlsattacker.attacks.Main.main(Main.java:95)
host:~/TLS-Attacker/apps|1%  xxd -c32 Attacks.jar | grep ucky
000d580: 4c75 636b 7931 3341 7474 6163 6b65 722e 636c 6173 73ad 5a09 785b d595 fe8f 2cf9  Lucky13Attacker.class.Z.x[....,.
001cd80: 2f4c 7563 6b79 3133 436f 6d6d 616e 6443 6f6e 6669 672e 636c 6173 73ad 57f9 571b  /Lucky13CommandConfig.class.W.W.
0026d00: 7461 636b 6572 2f61 7474 6163 6b73 2f69 6d70 6c2f 4c75 636b 7931 3341 7474 6163  tacker/attacks/impl/Lucky13Attac
0027960: 2f63 6f6e 6669 672f 4c75 636b 7931 3343 6f6d 6d61 6e64 436f 6e66 6967 2e63 6c61  /config/Lucky13CommandConfig.cla
host:~/TLS-Attacker/apps|%

[ic0ns]

You did nothing wrong. We disabled lucky13 at the moment since we were not happy with our timing measurements. We are planning on readding this feature though. You can use TLS-Attacker 1.2 if you want the old version which supports lucky13

[drwetter]

thx for you response.

If that'll take longer how about returning a different message to the user?

[ic0ns]

Yes i guess we should do that or atleast remove that part from the documentation

[drwetter]

Hi @ic0ns ,

any update on this? The thing which would be the best of course :-) is Lucky13 would be enabled again.

If the finding is not certain I would be happy with Vulnerable:Uncertain and e.g. if you can exclude it Vulnerable:false.

Cheers, Dirk

[ic0ns]

ẁell the lucky13 attack is a timing issue which is related to the cbc mode. You can exclude a vulnerability if the Server does not support cbc at all. Otherwise it will be very hard to determine if a remote server is vulnerable or not. If we readd this feature it will probably only work "reliably" against local servers.

I hope i can find a student to implement this, but dont expect this feature in the next 1 - 2 months...

[drwetter]

Hi Robert,

I wouldn't have asked in the first place if the remote side has no CBC ciphers. There's an awkward TLS stack I am currently examining. It appears kind of ancient and outdated. It offering CBC ciphers only, moreover it's a commonly used service.

I have interpreted TLS-Attacker as a tool which can detect a Lucky13 vulnerability remotely, for all other means I can use another project (testssl.sh) I started.

Your comment gave me the reason to go back and re-read the original publication from Royal Holloway. I realized that in fact one needs more more request for recovery at least than I remembered. There was still the question to me how many request is needed for a detection only. As you indicated the paper says it's difficult and a good network connection would be needed.

So, thanks for the info, Dirk

[jurajsomorovsky]

Yes, the attack is only hardly detectable in local environments since the differences are very low. The tests I ran previously were on the localhost.

[ic0ns]

The next version updates the wiki to indicate that we disabled this feature