Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: Increase in Protocol 47 denys - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Increase in Protocol 47 denys

ISC reader Scott has indicated that starting on December 27th he has seen a significant increase in Protocol 47 traffic being denied by his firewalls.  He has seen this traffic increasing from a baseline of near zero to 20,000 to 50,000 denies per day.  Protocol 47 traffic is not normally tracked by the ISC, so none of our sensors had detected this uptick.  However a little investigation reveals that firewalls I have access to are also seeing this increase. 

Protocol 47 is “GRE” (Generic Route Encapsulation) . It is commonly used as a Virtual Private Network (VPN). Essentially, GRE can be used to encapsulate any other protocol over IPv4. Sometimes it is used for IPv6 tunneling (instead of the more common IPv6 over IPv4, Protocol 41), and some anti-DDoS mitigation systems use it to route “cleaned” traffic.

I am showing this traffic originating from more than 100 unique sources.  I would like to dig deeper into this, but unfortunately I don't have access to packet captures to take a closer look at the traffic.  If you could let us know whether you are seeing the same thing, or better yet, have access to captures of this traffic, and could share it with us, it would be appreciated.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Rick

263 Posts
ISC Handler
Yes, I believe I have been logging the same increase in activity on my perimeters beginning on Tuesday 12/27 morning. I have been able to acquire many pcaps related to this traffic. Since all of the pcaps are very similar I'll paste one (as text) below. They are all attempting to spoof the true source and destination IPs using encapuslation. What I find strange is that the spoofed source IPs are always in the loopback (127.x), class D (224.x) or class E (240.x) ranges. In the PCAP below the true source IP is 31.168.107.48 and the spoofed source IP is 241.141.248.58 (so in my IPS the source for the below packet is reported as 241.141.248.58 which of course is not accurate). FYI I sanitized the pcap below (removed my IP address and replaced with "1.2.3.4"):

1 0.000000 241.141.248.58 178.177.101.55 UDP 66 10335 → 32698 Len=0

Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 27, 2016 10:35:08.152775000 MST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1482860108.152775000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 66 bytes (528 bits)
Capture Length: 66 bytes (528 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:gre:ip:udp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: CiscoInc_6f:c8:96 (40:55:39:6f:c8:96), Dst: CheckPoi_81:01:3e (00:1c:7f:81:01:3e)
Destination: CheckPoi_81:01:3e (00:1c:7f:81:01:3e)
Address: CheckPoi_81:01:3e (00:1c:7f:81:01:3e)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: CiscoInc_6f:c8:96 (40:55:39:6f:c8:96)
Address: CiscoInc_6f:c8:96 (40:55:39:6f:c8:96)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 31.168.107.48, Dst: 1.2.3.4
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 52
Identification: 0xbfaf (49071)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: Generic Routing Encapsulation (47)
Header checksum: 0x0f36 [validation disabled]
[Good: False]
[Bad: False]
Source: 31.168.107.48
Destination: 1.2.3.4
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Generic Routing Encapsulation (IP)
Flags and Version: 0x0000
0... .... .... .... = Checksum Bit: No
.0.. .... .... .... = Routing Bit: No
..0. .... .... .... = Key Bit: No
...0 .... .... .... = Sequence Number Bit: No
.... 0... .... .... = Strict Source Route Bit: No
.... .000 .... .... = Recursion control: 0
.... .... 0000 0... = Flags (Reserved): 0
.... .... .... .000 = Version: GRE (0)
Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: 241.141.248.58, Dst: 178.177.101.55
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 28
Identification: 0x2854 (10324)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x10cc [validation disabled]
[Good: False]
[Bad: False]
Source: 241.141.248.58
Destination: 178.177.101.55
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 10335 (10335), Dst Port: 32698 (32698)
Source Port: 10335
Destination Port: 32698
Length: 8
Checksum: 0x5613 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 0]
Jac

69 Posts Posts
I noticed that Red Hat just put out a Kernel patch for RHEL 7.1 that addresses CVE-2016-8666 (https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8666) and it seems like it may be related to the uptick in traffic for Protocol 47. Looks like plenty of Linux versions might have an issue and should probably be patched sooner rather than later.
Nick

1 Posts Posts
Interesting bug. It could be related. Now to trigger the vulnerability, a packet would need multiple "GRE->IP->GRE->IP" type headers. The packets we saw only have one GRE header. But the simple GRE packets could be used to find vulnerable hosts.
Johannes

2871 Posts Posts
ISC Handler
The devices sending GRE usually have telnet (TCP/23) and TCP/7968 open. Some seem to be elderly DVRs.
Jens

41 Posts Posts
Have a look at:
http://www.kerneronsec.com/2016/02/remote-code-execution-in-cctv-dvrs-of.html
This seems to match.
Jens

41 Posts Posts
I doubt this is related. The CCTV DVR issue was a web application vulnerability. But they could be used to send this type of traffic. Since Mirai, the main source of CCTV DVR compromises, closes port 23, this would be a different bot/worm.
Johannes

2871 Posts Posts
ISC Handler
Well I took 4 Devices that sent us GRE packets.
Then I used the webbrowser to access them and I got the same Device Kerner showed on his website.
The webserver on those devices says "Cross Web Server".

Interesting is the open port TCP/7968 which is a permutation of the Mirai Port 6789.
Jens

41 Posts Posts
I haven't gotten time to lab this up, but the header stack seems to resemble some spitballing I did a while back on the possibility of using GRE for reflection:

http://blog.slabnet.com/post/gre-reflection/
Hugo

1 Posts Posts
Seems to be from Mirai botnet? The Bot's are able to send GRE flood attacks...

"...encapsulated UDP packet containing 512 bytes of random data."

See: https://security.radware.com/ddos-threats-attacks/threat-advisories-attack-reports/mirai-botnet/
John

1 Posts Posts
Hi All,

Any new information on this?
Anonymous

Posts
Sorry, I am still digging further. We were able to determine that the seemingly random data in the packets was generated by the Mirai generator. That means that this is most likely from Mirai or 1337. Never was able to find a Taiwan based DDOS which was responsible for this traffic, but it is possible it was not big enough to warrant unusual attention.
Rick

263 Posts Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!