UDP/3478 to Amazon 54.84.9.242 -- got packets? (solved)
Several readers are reporting UDP/3478 (STUN) traffic to Amazon AWS address 54.84.9.242. If you "got packets" or know what it is, please share below.
Update Apr 29 19:30 UTC:
Thanks everyone for pitching in and providing packets and logs! With your help, we were able to link these requests to a project conducted by Dan Kaminsky at White Ops. Dan provided the following explanation:
At White Ops, we've been exploring some of the more interesting corners of web browsers, and what they expose via JavaScript, to detect the presence of some of the more interesting abusers of web browsers, i.e. bots. Turns out no matter how clever an exploit is, it tends not to teleport the attacker in front of the machine, so if you can detect automation and remote control, you can detect entire classes of otherwise unknown malware.
STUN, as part of the new WebRTC protocol stack, actually exposes certain classes of bot behavior. People are welcome to contact me privately if they're concerned about that; if it was dangerous to users, we'd file the bugs ourself.
In general, network administrators should expect a significant increase in STUN (and UDP) traffic over the next year that will ultimately be traced to web browsers. TCP has been a fantastic workhorse but between the rise of videoconferencing (which requires entirely different network topologies in order to provide reasonable latencies and echo cancellation) and the constant push of the web away from request/response and towards push semantics for web apps, WebRTC will likely take a position alongside other normal protocols like HTTP, DNS, etc.
There is also a discussion thread on this in the SANS ISC Forum at https://isc.sans.edu/forums/STUN+traffic/745/ and https://isc.sans.edu/forums/STUN+traffic/745/2/
Comments
its been driving me crazy for two weeks.
thanks dan kaminsky
[1:2016149:2] ET INFO Session Traversal Utilities for NAT (STUN Binding Request) [Classification: Attempted User Privilege Gain] [Priority: 1]: {UDP} 192.168.1.160:49901 -> 54.84.9.242:3478
Anonymous
Apr 30th 2015
9 years ago
Anonymous
May 4th 2015
9 years ago
Anonymous
May 19th 2015
9 years ago
54.172.47.69
ET INFO Session Traversal Utilities for NAT (STUN Binding Request) - 06/21/16-12:26:51
ET INFO Session Traversal Utilities for NAT (STUN Binding Response) - 06/21/16-12:26:20
Anonymous
Jun 21st 2016
8 years ago
Last week I purchased a Reolink IP camera on Amazon. Excellent camera, however I had a problem with some artifacting at the top and I contacted support for help. They were quick to respond and asked for the UID of the camera and the password of the Admin account. I was afraid I was going to find out exactly what I found out when they didn't ask for an IP address. Much like Logmein, the camera is checking in for connections on (roughly) a constant 2 minute schedule. At first it was checking into APNIC registered 116.0.0.0/8 IPs, and then to 54.0.0.0/8 Amazon IPs.
I was a little baffled and a lot angry, but it got worse. Hopefully someone here can help me sort this out.
My internal subnet is 10.3.8.0/24
Camera = 10.3.8.110
My PC = 10.3.8.5
On my ASA 5505, I allow all traffic from the camera to my PC. Next line in the ACL blocks the camera from going anywhere at all. But I run a capture and low and behold, the camera is still communicating to 54.86.23.37, 54.72.248.104, 54.179.151.251 and a bunch of others over STUN. I was looking to see if there's something else that needs to be enabled to block STUN packets, but apparently it's not capable at all.
I've been a network security engineer for many years and this is extremely troubling. If this device is able to have open access through STUN to any network it chooses, we have a major security breach in the works. I have captures if anyone wants to work with me on this.
Anonymous
Oct 31st 2016
8 years ago
Anonymous
Oct 31st 2016
8 years ago