UDP/3478 to Amazon 54.84.9.242 -- got packets? (solved)

Published: 2015-04-29
Last Updated: 2015-04-29 19:30:42 UTC
by Daniel Wesemann (Version: 2)
6 comment(s)

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/

Keywords: amazon STUN
6 comment(s)

Comments

this is how my snort has been flagging this traffic
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
Well you complain about Dan doing this research, but I would be incredibly surprised if that's the only STUN traffic you're seeing. I'm definitely seeing an increasing amount of STUN traffic that can be traced back to malicious activity.
STUN has been being (ab)used by malware pretty consistently now for almost a year, primarily by Dyre/Dyreza. If you're not already blocking STUN packets from all devices other than VoIP and/or videoconferencing gear, and setting alerts on ones that originate within non-VoIP/video devices, you probably should.
i am getting lots of this
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
I have an interesting situation here, and I was surprised to see that this is also traffic to Amazon and STUN:

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.
I would love to look at the pcaps. A lot of these cameras come with a cloud service to review footage. I suspect the traffic you are seeing is the registration with the cloud service. Not sure why the ASA isn't blocking it.

Diary Archives