Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Timothy_Hall
Champion
Champion

IPS Update Failure due to ISP Enforcement - Workarounds?

So a customer a mine mentioned that they were having IPS update problems.  After taking a look we realized that this behavior started when their ISP made some changes.  The ISP appears to be blocking the IPS update metadata request which is being accomplished via the http protocol, not via https which is why the ISP can see and block it as some kind of "script execution" vulnerability or so they claim.  The IPS update attempt dies very quickly implying an active reject of the traffic by the ISP rather than a silent drop, which is demonstrated below.

First off I find it a bit disturbing that this IPS update metadata request is made by the Check Point firewall using http in the clear, even though the update itself appears to be encrypted at rest before being transferred via http.  I realize the IPS blade was around long before https became the norm for web traffic, but this is a security enforcement device we are talking about here.

While the answer may well be to tell the ISP to relax their enforcement a bit, I need to tell them exactly *what* to relax as they are just claiming the vague "script execution" vulnerability.  After some playing around with packet captures and curl_cli it seems that the ISP device has a problem with the ".upf" file extension in a URL.  This extension has a couple of uses but the most security-relevant one appears to be "Unified Power Format File" which I assume has some SCADA implications.  The other two uses involved a Microstation CAD drawing program and Panono Panorama mode or something which seems unlikely.

So I see two ways forward here:

1) Somehow force the IPS metadata update check to use https instead of http (which frankly it should be doing already) so the ISP cannot see and block it

2) Identify the exact CVE/signature/vulnerability involved here so we can make a specific request of the ISP for an exception (the ISP is using a non-Check Point firewall)

Below shows that when the &xtn=.upf is included at the end of the HTTP GET, the ISP firewall starts tampering with the stream and a bunch of TCP RST's occur.  When the &xtn=.upf is excluded, no interference occurs. For our two captures below dl3.checkpoint.com resolved to two different IP addresses, but the behavior is the same no matter what IP it resolves to.

Anyone know why a firewall would block a URL referencing a .upf?  What signature is it?  IP addresses and portions of the URL below have been obscured.

 

curl_cli -v http://dl3.checkpoint.com/paid/3f/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/sd_updates.upf?HashKey=xxxxxxxxx...\&xtn=.upf

Expert# tcpdump -ni eth1 host 104.94.231.69
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:58:29.691799 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [S], seq 2147528982, win 27200, options [mss 1360,sackOK,TS val 1745876721 ecr 0,nop,wscale 10], length 0
14:58:29.714437 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [S.], seq 3316572147, ack 2147528983, win 65160, options [mss 1392,sackOK,TS val 155428073 ecr 1745876721,nop,wscale 7], length 0
14:58:29.714619 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [.], ack 1, win 27, options [nop,nop,TS val 1745876744 ecr 155428073], length 0
14:58:29.714715 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [P.], seq 1:203, ack 1, win 27, options [nop,nop,TS val 1745876744 ecr 155428073], length 202: HTTP: GET /paid/3f/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/sd_updates.upf?HashKey=xxxxxxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&xtn=.upf HTTP/1.1
14:58:29.738203 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], ack 203, win 508, options [nop,nop,TS val 155428097 ecr 1745876744], length 0
14:58:29.758136 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 1:1349, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP: HTTP/1.1 200 OK
14:58:29.758294 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [.], ack 1349, win 30, options [nop,nop,TS val 1745876788 ecr 155428116], length 0
14:58:29.758456 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [F.], seq 203, ack 1349, win 30, options [nop,nop,TS val 1745876788 ecr 155428116], length 0
14:58:29.758459 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 1349:2697, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.758520 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.758866 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 2697:4045, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.758910 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.759696 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 4045:5393, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.760299 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.760731 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 5393:6741, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.760765 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.761128 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 6741:8089, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.761162 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.761523 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 8089:9437, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.761574 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.761839 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 9437:10785, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.761869 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.762104 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 10785:12133, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.762131 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.762256 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 12133:13481, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.762283 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.762438 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 13481:14829, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.762505 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.762613 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 14829:16177, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.762640 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.762898 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 16177:17525, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.762924 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.763184 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 17525:18873, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.763211 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.763363 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 18873:20221, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.763369 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 20221:21569, ack 203, win 508, options [nop,nop,TS val 155428116 ecr 1745876744], length 1348: HTTP
14:58:29.763398 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.763421 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.783864 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 21569:22917, ack 203, win 508, options [nop,nop,TS val 155428142 ecr 1745876788], length 1348: HTTP
14:58:29.783891 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [P.], seq 22917:24265, ack 203, win 508, options [nop,nop,TS val 155428142 ecr 1745876788], length 1348: HTTP
14:58:29.784264 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.784273 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529185, win 0, length 0
14:58:29.823939 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], ack 204, win 508, options [nop,nop,TS val 155428183 ecr 1745876788], length 0
14:58:29.824021 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529186, win 0, length 0
14:58:29.833979 IP 104.94.231.69.http > xxx.xxx.xxx.5.12416: Flags [.], seq 24265:25613, ack 204, win 508, options [nop,nop,TS val 155428193 ecr 1745876788], length 1348: HTTP
14:58:29.834067 IP xxx.xxx.xxx.5.12416 > 104.94.231.69.http: Flags [R], seq 2147529186, win 0, length 0


curl_cli -v http://dl3.checkpoint.com/paid/3f/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/sd_updates.upf?HashKey=xxxxxxxxx...

Expert# tcpdump -ni eth1 host 23.50.39.38
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
15:01:26.079293 IP xxx.xxx.xxx.5.46741 > 23.50.39.38.http: Flags [S], seq 1888979845, win 27200, options [mss 1360,sackOK,TS val 1746053108 ecr 0,nop,wscale 10], length 0
15:01:26.103555 IP 23.50.39.38.http > xxx.xxx.xxx.5.46741: Flags [S.], seq 563459961, ack 1888979846, win 65160, options [mss 1392,sackOK,TS val 4127032619 ecr 1746053108,nop,wscale 7], length 0
15:01:26.103743 IP xxx.xxx.xxx.5.46741 > 23.50.39.38.http: Flags [.], ack 1, win 27, options [nop,nop,TS val 1746053133 ecr 4127032619], length 0
15:01:26.103850 IP xxx.xxx.xxx.5.46741 > 23.50.39.38.http: Flags [P.], seq 1:194, ack 1, win 27, options [nop,nop,TS val 1746053133 ecr 4127032619], length 193: HTTP: GET /paid/3f/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/sd_updates.upf?HashKey=xxxxxxxxxxxx_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1
15:01:26.128103 IP 23.50.39.38.http > xxx.xxx.xxx.5.46741: Flags [.], ack 194, win 508, options [nop,nop,TS val 4127032644 ecr 1746053133], length 0
15:01:26.130158 IP 23.50.39.38.http > xxx.xxx.xxx.5.46741: Flags [P.], seq 1:199, ack 194, win 508, options [nop,nop,TS val 4127032646 ecr 1746053133], length 198: HTTP: HTTP/1.1 302 Moved Temporarily
15:01:26.130278 IP xxx.xxx.xxx.5.46741 > 23.50.39.38.http: Flags [.], ack 199, win 28, options [nop,nop,TS val 1746053160 ecr 4127032646], length 0
15:01:26.130390 IP xxx.xxx.xxx.5.46741 > 23.50.39.38.http: Flags [F.], seq 194, ack 199, win 28, options [nop,nop,TS val 1746053160 ecr 4127032646], length 0
15:01:26.154105 IP 23.50.39.38.http > xxx.xxx.xxx.5.46741: Flags [F.], seq 199, ack 195, win 508, options [nop,nop,TS val 4127032670 ecr 1746053160], length 0
15:01:26.154312 IP xxx.xxx.xxx.5.46741 > 23.50.39.38.http: Flags [.], ack 200, win 28, options [nop,nop,TS val 1746053184 ecr 4127032670], length 0

Tagging @PhoneBoy for R&D assist.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
3 Replies
PhoneBoy
Admin
Admin

The actual stream is encrypted, as you said, so there's not a real need for HTTPS.
Not aware of a way to force these updates to occur over HTTPS.
A possible workaround for this would be getting offline IPS updates and applying manually.
That requires signing a EULA, which can be done through the local office. 

As for what to tell the ISP to exclude, I have no idea and would most likely depend on the security device in question.

0 Kudos
Vladimir
Champion
Champion

I guess the question is why does Check Point not serve these updates over HTTPS to begin with in 2022?

The suggestion to download the IPS updates for offline installation may require a trip to a friendly neighborhood Starbucks until, that is, their ISP will start blocking those 🙂

(1)
PhoneBoy
Admin
Admin

HTTPS is just extra, unnecessary overhead when the underlying data is encrypted and signed already.
At least that's been the response from R&D when this has been raised in the past.
Outside of this particular issue...I tend to agree.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events