Problems with Port Explorer Socket Spy - Best viewer for capture.bin - Alternatives?

Discussion in 'Port Explorer' started by Devinco, Jun 1, 2006.

Thread Status:
Not open for further replies.
  1. Devinco

    Devinco Registered Member

    Joined:
    Jul 2, 2004
    Posts:
    2,524
    Problems with Port Explorer Socket Spy - Best viewer for capture.bin?

    I am packet sniffing a process during a session which is communicating over port 443 (sometimes over port 80) to see if the process is leaking the username and password (and other info) in the clear (plain text), when it should be encrypted.
    When I open capture.bin with notepad, I am able to search for the specific keywords in the whole session (user and pass) and find that the processs is leaking the info in the clear. But when I manually step through each packet in socket spy (it really needs a session search capability for the spied on process/socket and sorting ability), I cannot find the same leaked username and password.
    The capture.bin is in a custom format with most of it being gibberish in notepad. When I find the leak in capture.bin, there is no identifying number to match it up with socket spy to help narrow down where and when the leak is coming from. This makes packet sniffing a process and finding where the leak is difficult.
    Is there a superior viewer for capture.bin (other than notepad) that will show the log in the best way with search capability and some identifying number so I can match the packet up in socket spy?

    Thank you.
     
    Last edited: Jun 1, 2006
  2. Devinco

    Devinco Registered Member

    Joined:
    Jul 2, 2004
    Posts:
    2,524
    Re: Problems with Port Explorer Socket Spy - Best viewer for capture.bin - Alternativ

    I've tried a hex editor to view capture.bin, but it still doesn't show any identifying packet info surrounding the leaked data so that I can match it up in socket spy and find out where the leaked data is being sent to.
    Is it posssible for the leaked data to appear in capture.bin but not socket spy?

    I've also tried Ethereal, but I am too much of a newbie with it to get the results I need to identify the source of the data leak. Ethereal won't open port explorer's capture.bin format.

    Ethereal let's you sniff everything going through the NIC, but can it be limited down to the process in question?

    Any ideas or help are appreciated.
     
  3. Devinco

    Devinco Registered Member

    Joined:
    Jul 2, 2004
    Posts:
    2,524
    Re: Problems with Port Explorer Socket Spy - Best viewer for capture.bin

    I've been able to isolate the data leak in the process by using Port Explorer Socket Spy.
    The packet containing the plain text username and password is inbound on port 443 (supposed to be HTTPS) from the secure remote website communicating to the process. The process contains an integrated browser (most likely IE) and this inbound plain text user and password packet occurred directly after logging in to the secure site with the same username and password with the integrated browser.
    Needless to say, this is very surprising as usually the only plain text packets I see in an SSL session are the certificate exchange info and some non-sensitive data.

    The socket spy did contain the plain text user name and password packet, I missed it as I was stepping through all the other packets. This is where a session search feature in socket spy would really come in handy. But it is not an error in Port Explorer.

    The method used to isolate the data leak was to just step by step go through the session rather than analyze the whole session at once. After one step (like loading the secure site but before logging in) search the contents of capture.bin in notepad. Then close notepad, click Remove All (Packet Data) in the socket spy window and do the next step (log in) and repeat.

    I repeated the same packet sniffing steps with plain IE logging into same secure website and there were no plain text user names or passwords.

    Unless I am doing something wrong in my analysis, here are my conclusions:
    1. Just because a program claims to be secure, is communicating via SSL, HTTPS, port 443, shows a padlock, or any other illusory icon of security, it does not guarantee your connection is encrypted. Some or all of the data may well be sent plain text in the clear. This program was purchased from the company directly so could not have been tampered with by a 3rd party. The only way to be sure is to packet sniff the communications the process makes. If I had not decided to packet sniff the session carefully, I would never have noticed this glaring security flaw. The flaw is not in Port Explorer, it is in the other (un-named) program I purchased and/or the way it communicates with the secure website. The company will be notified of the flaw.

    2. Beware of "secure" programs with integrated IE browsers. Maybe there is a way to program it securely, but it seems like it creates a lot of extra exploitable avenues.

    For what it's worth...
     
  4. Devinco

    Devinco Registered Member

    Joined:
    Jul 2, 2004
    Posts:
    2,524
    Re: Problems with Port Explorer Socket Spy - Best viewer for capture.bin - Alternativ

    Still having problems with this.
    I've been using Port Explorer Socket Spy and the same program in question with the integrated browser that appears to be leaking data.
    I've tried a totally different secure website with the program and got more data leaks, different info, but same result.
    So it seems that it is not the website but rather how the program with the integrated browser communicates with the sites.

    Now to throw a monkey wrench into the whole works!
    It appears like it is the program, but I wanted to confirm it by using Ethereal to packet sniff the same step by step login process. NO DATA LEAKS!
    So, either I am missing the data leak in Ethereal because I don't know how to use it well enough yet or Port Explorer is somehow displaying the contents of an encrypted packet in its port to process mapping method (and displays it because the integrated browser program confuses it). Either way I can't resolve whether the problem lies in Port Explorer (falsely showing the integrated browser program as the data leaker) or the integrated browser program itself. The program in question is widely used so it is important that this is resolved. And I can't contact the company until I can confirm the results.

    This is troubling because using Port Explorer, I've noticed a similar data leak when using Mozilla Thunderbird to access secure mail servers with TLS. SSL connections to the mail servers showed no leaks, but TLS would reveal a surprising amount of info in plain text on several different servers. Now with these irregularities, I don't know if that was in fact true, or just a bug in Port Explorer showing more than would be visible to a packet sniffer out on the internet.

    DiamondCS...any ideas on what is causing this?
    Is this a bug in Port Explorer or the normal way it works showing the contents of an encrypted packet?
    I've been using Port Explorer to detect what info a process might be sending or receiving from a remote site (particularly secure sites) that would be visible on the internet when it shouldn't.
    Is Port Explorer the right tool for this particular job?
    If not, what is the best tool for this job?

    I like Port Explorer, have purchased several licenses, and have recommended it to many friends. But If I cannot trust the results that Port Explorer Socket Spy is providing, I can't use it or recommend it.
     
  5. Devinco

    Devinco Registered Member

    Joined:
    Jul 2, 2004
    Posts:
    2,524
    Re: Problems with Port Explorer Socket Spy - Best viewer for capture.bin - Alternativ

    Perhaps this has something to do with the way Port Explorer handles TLS packets and exposes the packet contents locally when out on the internet they are encrypted?
    Ethereal showed the session to contain TLS packets. Also during the Thunderbird data leak, it was using TLS.
     
Thread Status:
Not open for further replies.