Hello, Thanks for all the prior help this board has provided. I am working on a follow up from post https://ask.wireshark.org/questions/48464/snmp-string-with-displayed-as-23. TL;DR - I think this vendors software has issues handling characters typed into their web form with special characters (!#$%^&). From what I can tell, these special characters are manipulated to hex values. Though I am still dealing with this vendor who is insistent that we are typing characters into their web form incorrectly. To prove them incorrect, I made the 2 videos which I think is sufficient to prove my claim (6 mins total). Can anyone help point out why this would not be sufficient evidence to support my claim if you can think of any other possibilities? Entering data in the webform on the local host of webserver and wireshark showing manipulation: https://www.youtube.com/watch?v=WdlBWTZl0zA&feature=youtu.be I even made a 2nd video that I hope further proves this with switch debugging: https://www.youtube.com/watch?v=lZnvoXzwWQM asked 08 Jan '16, 08:03  crknipe123 edited 08 Jan '16, 08:04 |
2 Answers:
Yeah, sure, "Wireshark is wrong" - nice try, lazy $vendor. While your capture method isn't 100% optimal (only using a dedicated professional capture device with a Full Duplex TAP would be 99.999999% accurate), it is good enough for a simple reason: you're looking at application content, not timings, broken packets, out-of-orders, etc. So I rule it's valid as evidence in your case. Now, Wireshark may or may not decode things correctly, but if you decode the hex view (by hand, if necessary) and get the same result, Wireshark can't be wrong. And, in your case, it isn't wrong. Their web front end is manipulating your input before sending it, probably because they apply URI encoding routines by mistake. You should be able to find this in the client side Javascript if you look at the form action. answered 08 Jan '16, 08:47  Jasper ♦♦ |
Your videos are showing clearly that the HEX values of the community string are being modified. This is probably a result of web application security gone wrong. They might have tried to apply OWASP10 recommendations and failed to "normalize" input strings in a proper way.
Well, run a browser plugin (like Firedebug) to show them your input. Combined with the pcap file, they should accept that something is actually wrong in their tool. Just to be sure: There is no security device (firewall, proxy, etc.) between your browser and the device where you are entering the SNMP community in the web GUI, right?
As your video shows 5 (or 6) input characters in the browser, but a few more characters in the HEX dump of the community string, it's pretty obvious that the software is doing something wrong. As you are running the software in a VM, you could try to get access to the web GUI code (maybe python or PHP) and show them where they fail ;-) BTW: What kind of software is this? Regards answered 08 Jan '16, 15:30  Kurt Knochner ♦ |
Thanks again. I am pulling my hair out with their responses and this helps my confidence level.
Also if the function is failing on the snmp devices, then you either have the web front-end being incorrect or Wireshark and the snmp devices being incorrect. Occam's razor indicates it's likely to be the web front-end.
@crknipe if you can, send me an email with the name of the vendor and the product to jasper[ät]packet-foo.com
often it's just the first line support, who has no idea at all what Wireshark is and how to interpret the technical details. I suggest to escalate the ticket to the next level, where you usually find people with better technical skills ;-) This is (sadly) true for most vendors...