You are here >  theory >  security

Passwords on the wire

For any online access to resources, storage or anything that involves remote connectivity, passwords have been sent over the wire, directly or indirectly. By indirectly, we mean password HASH or some other form or value computed by a function [implementation of an algorithm] that does not let password go on the wire, be it clear or encrypted. That being said, let us look at some of the applications in the real world scenario, where your application would be using or sending passwords on the wire for authenticating the user(s):

  • Instant Messaging [MSN, Yahoo, Live, etc.].
  • 3rd Party Instant Messaging [Trillian, Adium, etc.].
  • FTP Tools [Pure-FTPd, etc.].
  • SSH Tools [WinSCP, etc.].
  • Applications that run on Browser [Email Accounts(gmail, Yahoo!, etc.) and other applications].
  • and others.

We took a couple of scenarios where an applications are trying to authenticate a user online and captured PCAPs to see what is on the wire during this authentication process. The first scenario is where a user is signing into MSN Live Messenger and authenticating himself with “PassTest123” as the user name. Our intent is to show how password got traversed through the Internet, and if we could see it in the PCAP we captured during the process, or if the password even go in the wire. When we captured the PCAP and applied the corresponding filters to see only the traffic logs that corresponds to the MSN traffic, we observe the following:


*To zoom in - click the image*
Figure 1: Sessions and Streams for Initial Handshake.


The following is the expanded view of the first traffic log of what you see in Figure 1 [in the above snapshot]:

No. : 11
Time : 0.809550
Source : 192.168.1.102
Destination : 65.54.165.175
Protocol : TCP
Info : 49357 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2

Frame 11 (66 bytes on wire, 66 bytes captured)
Arrival Time: Jul 19, 2010 08:42:46.529811000
[Time delta from previous captured frame: 0.001359000 seconds]
[Time delta from previous displayed frame: 0.809550000 seconds]
[Time since reference or first frame: 0.809550000 seconds]
Frame Number: 11
Frame Length: 66 bytes
Capture Length: 66 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: HTTP]
[Coloring Rule String: http || tcp.port == 80]
Ethernet II, Src: HonHaiPr_8f:b6:07 (00:26:5e:8f:b6:07), Dst: Cisco-Li_06:79:e8 (68:7f:74:06:79:e8)
Destination: Cisco-Li_06:79:e8 (68:7f:74:06:79:e8)
Address: Cisco-Li_06:79:e8 (68:7f:74:06:79:e8)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: HonHaiPr_8f:b6:07 (00:26:5e:8f:b6:07)
Address: HonHaiPr_8f:b6:07 (00:26:5e:8f:b6:07)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.102 (192.168.1.102), Dst: 65.54.165.175 (65.54.165.175)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 52
Identification: 0x09ff (2559)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x47d1 [correct]
[Good: True]
[Bad : False]
Source: 192.168.1.102 (192.168.1.102)
Destination: 65.54.165.175 (65.54.165.175)
Transmission Control Protocol, Src Port: 49357 (49357), Dst Port: http (80), Seq: 0, Len: 0
Source port: 49357 (49357)
Destination port: http (80)
[Stream index: 2]
Sequence number: 0 (relative sequence number)
Header length: 32 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgement: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish request (SYN): server port http]
[Message: Connection establish request (SYN): server port http]
[Severity level: Chat]
[Group: Sequence]
.... ...0 = Fin: Not set
Window size: 8192
Checksum: 0x41ec [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Options: (12 bytes)
Maximum segment size: 1460 bytes
NOP
Window scale: 2 (multiply by 4)
NOP
NOP
SACK permitted

 68 7f 74 06 79 e8 00 26 5e 8f b6 07 08 00 45 00   h.t.y..&^.....E.
 00 34 09 ff 40 00 80 06 47 d1 c0 a8 01 66 41 36   .4..@...G....fA6
 a5 af c0 cd 00 50 ed 23 b5 f4 00 00 00 00 80 02   .....P.#........
 20 00 41 ec 00 00 02 04 05 b4 01 03 03 02 01 01    .A.............
 04 02                                             ..

In the above, users could see the packet layer-by-layer. That is, starting from the Ethernet protocol[Data-link Layer] where you could see the frame-details Mac address and so on, to the Internet Protocol [IP layer] to the Transmission Control Protocol [TCP layer] along with other details that includes TTL, Window Size, etc. and the above information is only for one single packet. If you multiply this by the number of packets per session, you would wonder how much of information you have in your hands to analyze your possibilities from. Figure 1 shows the session being initiated, along with the traffic logs of initial handshake. The Hexdump of the traffic logs in Figure 1, look like this:


*To zoom in - click the image*
Figure 2: Hexdump of Initial Handshake.


From Figure 2, one might understand that when a user types in their username and password, MSN Live messenger calls the login.live.com/ppcrlcheck.srf with the User-Agent indicating that it is from msnmsgr.exe and the content with the configration information. Once the initial handshake is done and the call is made, the next thing we noticed is that the channel gets encrypted as shown below:


*To zoom in - click the image*
Figure 3: Encryption Call.


The hexdump or raw data of the above session seen in Figure 3, is as shown in Figure 4.


*To zoom in - click the image*
Figure 4: Raw data of Encryption Call.


As you can see, the text in Figure 4 is not plain/human-readable text, although some parts of it is human-readable text such as Verisign, Microsoft, etc. where it indicates “For authorized use only”. Since this is done as soon as the initial call is made, we can safely assume that the password is either sent over the encrypted tunnel or is modified to some other form [using an encryption algorithm] and sent in some other form to verify the authenticity of the user. Once this is done, we observed what is seen in Figure 5.


*To zoom in - click the image*
Figure 5: SSO Raw Data.


In here, we observed a key word in front of the user name “SSO” which stands for Single Sign-On. Once the single sign-on is done, we observed that there was a policy exchange as shown in Figure 6. In here, we observed several file-frames that are base64 encoded and sent.


*To zoom in - click the image*
Figure 6: Policy Exchange.


Once the policy exchange is made, call to an advertisement banner is made and then the messenger shows the status as signed-in at the user side. Hence, under the assumption that this is how most of the messengers authenticate users with communication to authentication servers, we would like to consider a scenario that is totally different from this one. We have known ever since the creation of File Transfer Protocol [FTP] sends passwords in clear text. We wanted to find out if every implementation, or in other words the application that are using FTP to connect to servers and update files authenticate in plain-text. In this example, we used EditPlus that uses FTP for connecting to the servers, if people/developers would like to edit their files.


*To zoom in - click the image*
Figure 7: Pure-FTPd called from EditPlus.


The username in the above is “current”, the password is “current location” and as you can see both are seen in plain-text in the PCAP, which also means that they are sent in plain-text over the wire. This is exactly why, many articles on the Internet tell you why one should use SSH over FTP. This also does not mean that anyone on your corporate network can sniff and take note of your passwords. This is not how exactly it works on a switched network [where in, each user/system is connected to each port and hence broadcasting as well as sniffing is not possible].

Now that you have seen a couple of scenarios, you should have understood how passwords can be viewed in the network. This does not mean that this would be the same in every case for every application. Each application is unique in its own way depending on various factors, such as the protocol used, the implementation and various other factors. But in an overall, the question is whether passwords are sent in the wire or not and how is it being sent [clear or encrypted] and even if they are not sent, what are the other modes in which passwords could be modified into something [MD5 or SHA1 hash] that could be used for authentication. That being the case, one might wonder the best place for retrieving passwords for applications that send passwords over encrypted tunnels. The best place to look for is the memory space in which this application is running, although applications zero-out or encrypt the passwords even in the system memory, and in such cases we could look else where [which is not in the scope of this article].

EvilFingers Arsenal






























Socialize with RootkitAnalytics

Twitter Feed Blogspot

Socialize with EvilFingers

Twitter Feed Blogspot LinkedIn Delicious Google

Tweets