5 ms·

Good fun with bad crypto

58 points by lelf 13y ago

nialo 13y ago
I'd like to try figuring this out myself as an exercise, and therefore haven't read past the introduction of the article. Does anyone know where I can find either the application in question or some other program that will at least encode this format?
- lelf 13y ago
  It's in the post. wget http://lelf.lu/files/MAGF.py http://lelf.lu/files/MAGF.py if you absolutely don't want to spoil it
valarauca1 13y ago
Firefox returns: (Error code: ssl_error_no_cypher_overlap) via https
- kingzero 13y ago
  Same here. So i checked what ciphersuits they use. TLS_RSA_WITH_RC4_128_SHA Too bad they cant correctly set up their servers ...
  - valarauca1 13y ago
    Funny the blog post is about bad crypto and its all they support.
    - deleted 13y ago
      [deleted]
  - RRRA 13y ago
    Funny how I had just disabled RC4 and DES in my browser... I wonder how can that be your only supported crypto in 2014!
    - wiml 13y ago
      For a while, RC4 was recommended because it's immune to the BEAST attack.
      - valarauca1 13y ago
        A new theoretical attack was published in 2013 that showed that RC4 was still weak in TLS. While the attack was more academic, it did raise questions of what else would be possible. We often forget that RC4 is a fundamentally broken algorithm.
luma 13y ago
It's not bad crypto, it's an encoding scheme. It's even in the name! Citrix uses this to pass around credentials between disparate systems which might not be part of the same ActiveDirectory forest preventing the use of OS provided ticketing systems. The traffic carrying these credentials are encrypted with SSL, so you shouldn't be able to pull this in cleartext off the wire. It's obviously not a great system, but it does what it's designed to do. Details on abusing this system are available here[1], but they still require getting access to the unencrypted stream which once again will be passed around the network inside an HTTPS connection. While I'm sure it was an interesting exercise, the author could have saved himself some time and simply Googled the name, there are published scripts and COM objects to deal with this encoding stream such as[2]. [1] http://www.securityfocus.com/archive/1/520869 http://www.securityfocus.com/archive/1/520869 [2] http://www.remkoweijnen.nl/blog/2013/03/19/scriptable-citrix-password-encoder/ http://www.remkoweijnen.nl/blog/2013/03/19/scriptable-citrix...
- jarrett 13y ago
  Good point. What, more specifically, is the purpose of the Citrix encoding system? Is it to map an arbitrary byte string onto a limited range of bytes (ASCII A to P)? If so, any reason base 64 was unsuitable for these applications?
  - taway2012 13y ago
    Base64 can maybe result in strings unsuitable for pasting as-is into bad HTTP servers' URLs (the default character set include '/' and '+'). Using only the uppercase letters lets them worry less about whether the string got mangled because some systems interpreted it as Unicode and some didn't etc. Something like Bitcoin and Flickr's base58 would have also worked, but the encoder and decoder would have been more complicated. They got away with only division by 16. They get a little bit of integrity checking too. Basically, this is base16 with a poor man's integrity checking baked in. Pretty interesting.
    - jarrett 13y ago
      Ah, so the design of this encoding is specifically targeting URLs? That makes a lot more sense. Thanks! Knowing that, it does in fact seem like a sensible encoding for certain applications. Encoding, not encryption, mind you. I assume (or at least hope) the designers intended it as the former only, and never as the latter.
asciimo 13y ago
This article coincides perfectly with the online Stanford Crypto class that just started up: https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto We just covered the principles of good encryption, and this is a great exercise to witness in that context.
teddyh 13y ago
> x = sys.stdin.readline() > while x: > … > x = sys.stdin.readline() Seeing stuff like that makes me sad. This could be more simply be written as: for x in sys.stdin: …
- badman_ting 13y ago
  That doesn't strike me as a very worthwhile criticism of code.
- cratermoon 13y ago
  As written, the code will write the response string out immediately. The for x in version will block until end-of-input.
  - tekacs 13y ago
    Er... no. No it absolutely wouldn't block until end-of-input. If list comprehensions were being used to precompute the output and the whole list printed from (what you seem to be thinking of) then perhaps yes, but any of: for x in sys.stdin: ... or [... for x in sys.stdin] (where ... is print(func(x)) as per the post) as per the GP post will print response strings as the input comes in.
  - teddyh 13y ago
    The two versions are functionally identical, which is why the shorter version without repeated code is better.

58 points by lelf 13y ago

nialo 13y ago

I'd like to try figuring this out myself as an exercise, and therefore haven't read past the introduction of the article. Does anyone know where I can find either the application in question or some other program that will at least encode this format?

lelf 13y ago
It's in the post. wget http://lelf.lu/files/MAGF.py http://lelf.lu/files/MAGF.py if you absolutely don't want to spoil it

valarauca1 13y ago

Firefox returns: (Error code: ssl_error_no_cypher_overlap) via https

kingzero 13y ago
Same here. So i checked what ciphersuits they use. TLS_RSA_WITH_RC4_128_SHA Too bad they cant correctly set up their servers ...
- valarauca1 13y ago
  Funny the blog post is about bad crypto and its all they support.
  - deleted 13y ago
    [deleted]
- RRRA 13y ago
  Funny how I had just disabled RC4 and DES in my browser... I wonder how can that be your only supported crypto in 2014!
  - wiml 13y ago
    For a while, RC4 was recommended because it's immune to the BEAST attack.
    - valarauca1 13y ago
      A new theoretical attack was published in 2013 that showed that RC4 was still weak in TLS. While the attack was more academic, it did raise questions of what else would be possible. We often forget that RC4 is a fundamentally broken algorithm.

luma 13y ago

It's not bad crypto, it's an encoding scheme. It's even in the name! Citrix uses this to pass around credentials between disparate systems which might not be part of the same ActiveDirectory forest preventing the use of OS provided ticketing systems. The traffic carrying these credentials are encrypted with SSL, so you shouldn't be able to pull this in cleartext off the wire. It's obviously not a great system, but it does what it's designed to do. Details on abusing this system are available here[1], but they still require getting access to the unencrypted stream which once again will be passed around the network inside an HTTPS connection. While I'm sure it was an interesting exercise, the author could have saved himself some time and simply Googled the name, there are published scripts and COM objects to deal with this encoding stream such as[2]. [1] http://www.securityfocus.com/archive/1/520869 http://www.securityfocus.com/archive/1/520869 [2] http://www.remkoweijnen.nl/blog/2013/03/19/scriptable-citrix-password-encoder/ http://www.remkoweijnen.nl/blog/2013/03/19/scriptable-citrix...

jarrett 13y ago
Good point. What, more specifically, is the purpose of the Citrix encoding system? Is it to map an arbitrary byte string onto a limited range of bytes (ASCII A to P)? If so, any reason base 64 was unsuitable for these applications?
- taway2012 13y ago
  Base64 can maybe result in strings unsuitable for pasting as-is into bad HTTP servers' URLs (the default character set include '/' and '+'). Using only the uppercase letters lets them worry less about whether the string got mangled because some systems interpreted it as Unicode and some didn't etc. Something like Bitcoin and Flickr's base58 would have also worked, but the encoder and decoder would have been more complicated. They got away with only division by 16. They get a little bit of integrity checking too. Basically, this is base16 with a poor man's integrity checking baked in. Pretty interesting.
  - jarrett 13y ago
    Ah, so the design of this encoding is specifically targeting URLs? That makes a lot more sense. Thanks! Knowing that, it does in fact seem like a sensible encoding for certain applications. Encoding, not encryption, mind you. I assume (or at least hope) the designers intended it as the former only, and never as the latter.

asciimo 13y ago

This article coincides perfectly with the online Stanford Crypto class that just started up: https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto We just covered the principles of good encryption, and this is a great exercise to witness in that context.

teddyh 13y ago

> x = sys.stdin.readline() > while x: > … > x = sys.stdin.readline() Seeing stuff like that makes me sad. This could be more simply be written as: for x in sys.stdin: …

badman_ting 13y ago
That doesn't strike me as a very worthwhile criticism of code.
cratermoon 13y ago
As written, the code will write the response string out immediately. The for x in version will block until end-of-input.
- tekacs 13y ago
  Er... no. No it absolutely wouldn't block until end-of-input. If list comprehensions were being used to precompute the output and the whole list printed from (what you seem to be thinking of) then perhaps yes, but any of: for x in sys.stdin: ... or [... for x in sys.stdin] (where ... is print(func(x)) as per the post) as per the GP post will print response strings as the input comes in.
- teddyh 13y ago
  The two versions are functionally identical, which is why the shorter version without repeated code is better.