Predictable TCP Initial Sequence Numbers Vulnerability

Hey there,

we´ve been using ipfire for a couple of years now, never had an issue.
Now we need an pci compliant check for creditcard payments(Basically a port scan from an external source). Last years check went through without issues, this year spat out the “Predictable TCP Initial Sequence Numbers Vulnerability”…

Along with some more information:

Details
Kategorie TCP/IP
CVE CVE-1999-0077,CVE-2000-0328,CVE-2000-0916,CVE-2001-0328
CVSS-Basisscore 7.5
Beschreibung Predictable TCP Initial Sequence Numbers Vulnerability
Host XXXX
Bedrohung -
Auswirkung -
Lösung -
PCI-konform Nein
PCI-Details -
Grund -
PCI-Details high
Port -
Hostname XXXX
Host-Betriebssystem -
Ergebnis
Constant changes in initial sequence numbers observed in 22 out of 23 events.
[ Sent Packets Results ]
Packet 1 : TIME[1598275523.153856] SEQ[1441366980] CHANGE[N/A] VARIATION[N/A]
Packet 2 : TIME[1598275523.158843] SEQ[1508402811] CHANGE[67035831] VARIATION[N/A]
Packet 3 : TIME[1598275523.163844] SEQ[1575438642] CHANGE[67035831] VARIATION[0]
Packet 4 : TIME[1598275523.168843] SEQ[1642474473] CHANGE[67035831] VARIATION[0]
Packet 5 : TIME[1598275523.173843] SEQ[1709510304] CHANGE[67035831] VARIATION[0]
Packet 6 : TIME[1598275523.178843] SEQ[1776546135] CHANGE[67035831] VARIATION[0]
Packet 7 : TIME[1598275523.183842] SEQ[1843581966] CHANGE[67035831] VARIATION[0]
Packet 8 : TIME[1598275523.193844] SEQ[1910617797] CHANGE[67035831] VARIATION[0]
Packet 9 : TIME[1598275523.198842] SEQ[1977653628] CHANGE[67035831] VARIATION[0]
Packet 10 : TIME[1598275523.203843] SEQ[2044689459] CHANGE[67035831] VARIATION[0]
Packet 11 : TIME[1598275523.208845] SEQ[2111725290] CHANGE[67035831] VARIATION[0]
Packet 12 : TIME[1598275523.223844] SEQ[2178761121] CHANGE[67035831] VARIATION[0]
Packet 13 : TIME[1598275523.228152] SEQ[2245796952] CHANGE[67035831] VARIATION[0]
Packet 14 : TIME[1598275523.233844] SEQ[2312832783] CHANGE[67035831] VARIATION[0]
Packet 15 : TIME[1598275523.238848] SEQ[2379868614] CHANGE[67035831] VARIATION[0]
Packet 16 : TIME[1598275523.243845] SEQ[2446904445] CHANGE[67035831] VARIATION[0]
Packet 17 : TIME[1598275523.248851] SEQ[2513940276] CHANGE[67035831] VARIATION[0]
Packet 18 : TIME[1598275523.253844] SEQ[2580976107] CHANGE[67035831] VARIATION[0]
Packet 19 : TIME[1598275523.258845] SEQ[2648011938] CHANGE[67035831] VARIATION[0]
Packet 20 : TIME[1598275523.263846] SEQ[2715047769] CHANGE[67035831] VARIATION[0]
Packet 21 : TIME[1598275523.268291] SEQ[2782083600] CHANGE[67035831] VARIATION[0]
Packet 22 : TIME[1598275523.273850] SEQ[2849119431] CHANGE[67035831] VARIATION[0]
Packet 23 : TIME[1598275523.278846] SEQ[2916155262] CHANGE[67035831] VARIATION[0]
Packet 24 : TIME[1598275523.283847] SEQ[2983191093] CHANGE[67035831] VARIATION[0]
CVSS-Basisscore 7.5 - - AV:N/AC:L/Au:N/C:P/I:P/A:P
Temporärer CVSS-Score 5.8 - E:POC/RL:W/RC:UC
Schweregrad 2
Kategorie TCP/IP
CVE ID
CVE-1999-0077
CVE-2000-0328
CVE-2000-0916
CVE-2001-0328
Verkäuferreferenz
MS99-046
cisco-sa-20010301
Bugtraq ID
604
1766
2682
Aktualisierungsdatum 04.06.2019
Bedrohung This server uses TCP/IP implementation that respects the “64K rule”, or a “time dependent rule” for generating TCP sequence numbers. Unauthorized users can predict sequence numbers when two hosts are communicating, and connect to your server from any source IP address. The only difference with a legitimate connection is that the attacker will not see the replies sent back to the authorized user whose IP was forged.
Auswirkung The Initial Sequence Number (ISN) used in TCP/IP sessions should be as random as possible in order to prevent attacks such as IP address spoofing and session hijacking.
If the ISN of an existing or future TCP connection can be determined within some practical range, a malicious agent may be able to close or hijack the TCP connections. If the ISNs of future connections of a system are guessed exactly, an agent may be able to “complete” a TCP three-way handshake, establish a phantom connection, and spoof TCP packets delivered to a victim.
XXXXX
Lösung You may need to upgrade your Operating System to change the behavior of your TCP/IP stack regarding this problem.
This cert advisory describes how to fix this issue : CA-2001-09
XXXXXX
For Microsoft systems you can apply this patch : MS99-046: How to Prevent Predictable TCP/IP Initial Sequence Numbers
XXXXX
For Cisco IOS systems you can apply this patch : cisco-sa-20010301-ios-tcp-isn-random: Cisco IOS Software TCP Initial Sequence Number Randomization Improvements

So, i really don´t know what to make of this, or how to get rid of it… the mentioned CVE is basically 20 years old and should not exist in the current Kernels.

On the other hand, the packet trace shows that there is no variation in between the packets.

The Firewall was updated to core 147 before the check, once again, without any issues.

Would be really great if someone could help me out here.

Cheers.

Hello Simon,

this is very limited information to work with, but my guess would be that the server behind the firewall that was tested is vulnerable for this attack. The firewall would not change any sequence numbers.

Hi all,
according to this doc --> https://resources.sei.cmu.edu/asset_files/whitepaper/2001_019_001_496192.pdf#page=64 the Linux Kernel used a variant of RFC1948 since 1996. In fact you can find ‘RNDADDENTROPY’ in kernel-4.14.184 at line 1957.

May the doc can offer you some more ideas what else could have broke the PCI compliant check ?

Best,

Erik

Hey there,

Micheals guess is right.
I could not get my head around it yesterday, but after some sleep it also came to me.
The one Port forward that is configured on the firewall forwards packets to some security device from an external company in the DMZ. Not completely sure if that is for fire alarms or (physical) intrusion detection, but with that device unplugged the checks runs without complaints. Guess i´ll have to contact those guys and ask if there is an update for that thing…

Anyways, thanks for the input to you two.

cheers

1 Like

So without the pentest you’d probably not know about the existence of that “security” device in your network? That underlines the value of such tests! :slight_smile:

Well… i was fully aware of that device. It´s mounted pretty visibly right next to the Server/Networking cabinet and i even configured that port forward myself some years ago.
I just was stupid :slight_smile:
The pentest did not specify any Port for that vulnerability, so my brain somehow “X”-ed out everything but the firewall…

1 Like