1

I'm testing a webapp as part of a bug bounty program where the value of a product ticket given to clients is being encoded.

FYI, ticket number is given to an user for an adquired product. Webapp has an input field where ticket number can be entered for information on product's status. The ticket number entered is sent to server and encripted, page reloads while emptying said input field, requests ticket number to server, decodes it an puts it back on input field for results page.

For an arbitrary ticket number: 1111111111111, the encripted string looks like this:

2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU%3DvK1%2BrOrlrThJWBCPGY5f2vzfJOFMCGd%2FS5%2BaM%2FX%2F6No%3D

Or this (when decoding the URL characters in it):

2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=

I've dissected this encoded string as follows:

1.

2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU%3D OR 2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=

This appears to be some salt or something like that, as it will appear pre-fixed in other encoded values such as client number.

2.

vK1%2BrOrlrThJWBCPGY5f2vzfJOFMCGd%2FS5%2BaM%2FX%2F6No%3D OR vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=

This is what I would call the "dinamic" part of the encoding, as this varies with ticket number.

Upon testing, I've come to observe the following:

  • It doesn't matter if '%2f' or '%3D' are written as '/' and '=' respectively, as server will decode the string and return the given ticket number in both cases. On the counterpart it does matter if '%2B' is passed as '+' as server will return ticket number's input field empty.

  • The ending '%3D' are necessary for decoding, striping the string from it's ending %3D character will result in an empty input field.

I've triend with onlin decoders with no luck.

Sorry if I extended myself too much, but I wanted to give you as many info as possible as I am not familiar with encoding methods. I hope someone can give a hand with this. Thanks in advance.

Alvaro
  • 11
  • 1
  • You can also try posting in http://crypto.stackexchange.com/ – Azteca Feb 02 '17 at 23:34
  • 2
    These types of questions are off-topic on Crypto SE. – Polynomial Feb 02 '17 at 23:35
  • Thanks for the answers. Specially Polinomyal with the extra efforts on solving. I see that this is a duplicate on another question, so I'm gonna delete this one. But before, I would like to ask if there's any way of finding out what kind of cipher is being used. Thanks again for the help. – Alvaro Feb 03 '17 at 18:30

2 Answers2

2

It's a pair of Base64 strings with a two character prefix:

2c9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=

Is equal to:

2c
9VP8uK6VUJlJR4Lmonwk3wy1UGEBgO4VqUYjUqar6kU=
vK1+rOrlrThJWBCPGY5f2vzfJOFMCGd/S5+aM/X/6No=

These encoded strings expand to the following data:

f5 53 fc b8 ae 95 50 99 49 47 82 e6 a2 7c 24 df
0c b5 50 61 01 80 ee 15 a9 46 23 52 a6 ab ea 45 

bc ad 7e ac ea e5 ad 38 49 58 10 8f 19 8e 5f da
fc df 24 e1 4c 08 67 7f 4b 9f 9a 33 f5 ff e8 da

Both are 32 bytes, which might indicate encrypted data, but it is clearly data with some pattern to it, so I suspect it's not actually a block cipher.

My first though is that the "2c" prefix might be 0x2c for some kind of xor crypto, but I didn't get any results from that. I also tried modulo addition and subtraction, and doing the same between the two string pairs, again with no result.

Unfortunately there's no obvious way to break this without a significant number of plaintext-ciphertext pairs to give us more information.

Polynomial
  • 135,049
  • 43
  • 306
  • 382
-1

Maybe the ticket number is now transformed into a hashed number? As in, it is now a point in a randomized number space. The URL encoded string should be respected since it is not certain that Web browsers or server side apps are able to parse the string correctly.

munchkin
  • 27
  • 2