Increase in Protocol 47 denys

Published: 2016-12-29
Last Updated: 2016-12-29 19:39:08 UTC
by Rick Wanner (Version: 1)
11 comment(s)

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)

Keywords: GRE
11 comment(s)

Comments

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]
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.
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.
The devices sending GRE usually have telnet (TCP/23) and TCP/7968 open. Some seem to be elderly DVRs.
Have a look at:
http://www.kerneronsec.com/2016/02/remote-code-execution-in-cctv-dvrs-of.html
This seems to match.
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.
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.
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/
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/
Hi All,

Any new information on this?

Diary Archives