0

I am trying to retrieve a username and password send over the network. I was able to capture the following using Wireshark:

GET /rcp_tunnel HTTP/1.0
Host: ***.***.***.***
Authorization: Basic dXNlcjo=

.......0...............%...0............4cd465f6567a1ff0....^...1...........J.....8....
.
.
F   .+user:4cd465f6567a1ff0:243a7d22820e68e7ff51588b1df80dd1+.......1...................&...1......................
.
.
F   ........0...................1.......................0.................
    .0................  ..0................
F.0...............(
..0...................................(

Looking at the header, it looks like Basic Authentication is used, however, when decoding dXNlcjo= from base64 to ascii I only get the username and colons, user:.

I am unsure about the remaining data that was send. It looks like that,

+user:4cd465f6567a1ff0:243a7d22820e68e7ff51588b1df80dd1+

could be a combination of username and the password.

I have tried to find an explanation, however, without success. Has anyone seen this authentication process before and could tell me how username and passwords are send?

  • 1
    It is supposed to be a base64 encoding in the format username:password however it really depends on the application and server. – Jonathan Gray Jan 15 '16 at 17:35
  • Thanks for you reply. I know about the username and password combination, but I think the actual password is in the other part. – Petee Jan 15 '16 at 17:40
1

The request you captured indicates that the username user with an empty password was used for HTTP authentication.

As you stated correctly, the Basic authentication scheme works by base64-encoding <username>:<password> in the Authorization header. So the rest of your capture likely doesn't belong to the HTTP request or the authentication protocol. In general, GET requests are very uncommon to contain a message body - which had to be signaled by a Content-Length or Transfer-Encoding header in the first place.

That said, it is hard to draw conclusions from the rest of your dump because all bytes without an ASCII representation are displayed as dots. A hexdump might be more informative.

  • Here is the packet, it looks like the password is not send directly. code Hypertext Transfer Protocol GET /rcp_tunnel HTTP/1.0\r\n [Expert Info (Chat/Sequence): GET /rcp_tunnel HTTP/1.0\r\n] Request Method: GET Request URI: /rcp_tunnel Request Version: HTTP/1.0 Host: ..***.***\r\n Authorization: Basic dXNlcjo=\r\n Credentials: user: \r\n [Full request URI: http://***.***.***.***/rcp_tunnel] [HTTP request 1/1] – Petee Jan 15 '16 at 18:23
  • Here is also the hex dump of the packet: ` 0000 00 07 5f 88 54 be 00 22 19 2f 5a 8b 08 00 45 00 0010 00 78 43 14 40 00 80 06 00 00 82 d1 f8 01 82 d1 0020 f6 01 da 75 00 50 a1 4f 38 01 72 81 ab d6 50 18 0030 fd 80 f4 10 00 00 47 45 54 20 2f 72 63 70 5f 74 0040 75 6e 6e 65 6c 20 48 54 54 50 2f 31 2e 30 0d 0a 0050 48 6f 73 74 3a 20 31 33 30 2e 32 30 39 2e 32 34 0060 36 2e 31 0d 0a 41 75 74 68 6f 72 69 7a 61 74 69 0070 6f 6e 3a 20 42 61 73 69 63 20 64 58 4e 6c 63 6a 0080 6f 3d 0d 0a 0d 0a ` – Petee Jan 15 '16 at 18:25
  • I am able to open user@***.***.***.*** from my web browser, however, it then asks me to enter username and password. I am assuming that is similar to what happens when I use the application. The username is send with the basic authentication and then username and password are send separately. Would that make sense? – Petee Jan 15 '16 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.