2

I have a sync app that doesn't work and the developer asked me to try and perform a sync with Wireshark capturing the data and send the Wireshark log to him.

I noticed that Wireshark saves sensitive data in the log, like the MAC address of both my devices involved in the sync process. Is there a built-in feature with which I can strip all this sensitive data out of the log I need to hand over to the developer? Any external tools?

Bonus question: Developer has a good reason to ask for this data, but he didn't tell me anything about the fact that the log would contain sensitive data. What should I do? Are this data really that important? Should have he warned me?

  • What kind of traffic? – curiousguy Oct 22 '14 at 11:38
  • Samba connection to access files shared on a pc from a smartphone – doplumi Oct 22 '14 at 11:41
  • There is probably much more than MAC addresses in the log file. – curiousguy Oct 22 '14 at 11:45
  • @curioisguy i don't know about that, the smb connection fails, that's why i have to send the log. Basically the dev wants to know why the connection fails on my particular machine. – doplumi Oct 22 '14 at 12:40
5

Are you sure that the data in the capture is sensitive data? If it's the MAC address that you are worried about, I can assure you that it is not sensitive, and not useful at all to any potential attacker.
MAC addresses are not traceable nor are they used for any kind of authentication (besides WIFI whitelists, which would require the technician to actually be within range of your WIFI network).
Infact, in the normal run of things, the MAC address never leaves your local network (I.E. It never gets to the internet).

Similarly, local IP addresses will not go out to the internet, and will be changed by your router/modem.

  • I was wondering if someone wants to mask himself as me, he would change its mac address to mine. But I am not sure. Are all of the possible mac addresses valid? If so, I wouldn't worry about someone stealing in particular mine. I dont know the reply to your last answer because I am by no means expert in the inf sec field. So, what sensitive data could a failed connection attempt to a smb file sharing connection contain? – doplumi Oct 22 '14 at 12:44
  • 1
    Well, assuming you turned it on, tried to connect and then turned it off again (I.E. There's nothing but the attempted connection and failure) then I would think it would contain no sensitive information. As for MAC addresses, they only uniquely identify your device within your own network. So it couldn't be used to impersonate you on the internet. There's no reason to worry about a MAC address being leaked. – Chris Murray Oct 22 '14 at 13:00
  • When you say your network, do you mean my LAN? I thought it would expand to the internet as well since I read about certain websites banning users by mac address because of dynamic IPs changing and things like that. Was that something made up (maybe they just wanted to scare people up)? – doplumi Oct 22 '14 at 13:05
  • 1
    @domenicop, I do indeed mean your LAN. It's not possible to ban users by MAC address, as the MAC address is constantly changing. The way the internet works, the "message" that you send is picked up and forwarded on by several devices between you and the final destination. Each one of these devices change the MAC address to their own. Even if the server could see your MAC address and ban it, it's very easy for a user to change their MAC address (it takes seconds) so it wouldn't be a very good ban anyway. – Chris Murray Oct 22 '14 at 13:20
2

You could run sanitize against your capture. Depending on what you want to sanitize, there is a pseudo-workaround for doing this with perl, however what you'd end up doing is mangling things if not done properly. Let's assume you wanted to sanitize on a known known - let's say an IP (10.1.1.2)

(Copy original so you don't mess things up beforehand)

perl -pi -e 's:31 30 2e 31 2e 31 2e 32:31 32 37 2e 30 2e 30 2e 33:g' your.pcap

This will convert the hex of 10.1.1.2 into 127.0.0.3 no matter where it's seen. The issue would be any overlapping hex. You could run tcpdump on the fly and convert it as well: e.g.

tcpdump -R yourfile.pcap | perl -p -e 's:31 30 2e 31 2e 31 2e 32:31 32 37 2e 30 2e 30 2e 33:g' >> new.pcap

Both I have done before with success, however there is room for mangling things. (overlapping hex).


EDITED TO ANSWER YOUR BONUS QUESTION

While it is better to be safe than sorry, you have to have some form of confidence in your vendor otherwise there are bigger problems. The quick non technical solution for this is to ensure any contractual lingo contains information related to privacy either way of an NDA or other legal safeguards.

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.