# SN 792: NAT Firewall Bypass

**URL:** <https://www.twit.community/t/sn-792-nat-firewall-bypass/8516>\
**Category:** Security Now\
**Tags:** episode\
**Created:** [November 11, 2020, 4:57am UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516 "2020-11-11T04:57:48Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Leo](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/leo/32/16203_2.png) [@Leo](https://www.twit.community/u/Leo)\
**Post date:** [November 11, 2020, 4:57am UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/1 "2020-11-11T04:57:48Z")

</div>

Beep boop - this is a robot. A new show has been posted to TWiT…

> **[NAT Firewall Bypass | TWiT.TV](https://twit.tv/shows/security-now/episodes/792)**
>
> SlipStream NAT firewall bypass, MS Police use Ring doorbell cams.

What are your thoughts about today’s show? We’d love to hear from you!

---

<div class="post-metadata">

**Author:** ![big\_D](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/big_d/32/1023_2.png) [@big\_D](https://www.twit.community/u/big_D)\
**Post date:** [November 11, 2020, 9:33am UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/2 "2020-11-11T09:33:58Z")

</div>

With regard to the root certificate that Let’s Encrypt used for cross-signing:

That also means all sites that bought certificates from that authority will also stop working (and other root certificates will also start to slowly become invalid on those old devices).

A second point, many apps use encrypted transport (hopefully all of them), which means that all of those apps will also stop working, if the servers are using Let’s Encrypt to provide their certificates (most use https to transfer their data back and forth).

---

<div class="post-metadata">

**Author:** ![PHolder](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/pholder/32/2439_2.png) [@PHolder](https://www.twit.community/u/PHolder)\
**Post date:** [November 11, 2020, 12:21pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/3 "2020-11-11T12:21:10Z")

</div>

> [@big\_D](#):
>
> means all sites that bought certificates from that authority will also stop working

Usually a CA has multiple root certs valid at the same time. They should NEVER issue a cert for a site without an expiry that is less than the expiry of the signing CA cert. I believe CA cross-signing may be an odd duck exception… not that aware of the rules in that regard.

---

<div class="post-metadata">

**Author:** ![big\_D](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/big_d/32/1023_2.png) [@big\_D](https://www.twit.community/u/big_D)\
**Post date:** [November 11, 2020, 12:23pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/4 "2020-11-11T12:23:45Z")

</div>

Yes, but those devices haven’t received any root cert updates since 2016. That is the point any set to die, like the one mentioned, will stop working and, although the CA might have issued new certs between 2016 and 2020, they won’t have found their way onto those devices.

This is a general problem for these devices, it doesn’t just affect Let’s Encrypt.

---

<div class="post-metadata">

**Author:** ![PHolder](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/pholder/32/2439_2.png) [@PHolder](https://www.twit.community/u/PHolder)\
**Post date:** [November 11, 2020, 12:25pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/5 "2020-11-11T12:25:02Z")

</div>

Well all certs have an expiry… all I’m saying is the sub-cert will always expire before the CA cert that signed it.

---

<div class="post-metadata">

**Author:** ![big\_D](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/big_d/32/1023_2.png) [@big\_D](https://www.twit.community/u/big_D)\
**Post date:** [November 11, 2020, 12:34pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/6 "2020-11-11T12:34:41Z")

</div>

Yes, but that will always be renewed against the new root cert, so will also be invalid on those older devices, even though they are valid.

---

<div class="post-metadata">

**Author:** ![PHolder](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/pholder/32/2439_2.png) [@PHolder](https://www.twit.community/u/PHolder)\
**Post date:** [November 11, 2020, 2:19pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/7 "2020-11-11T14:19:10Z")

</div>

I just don’t understand your point. Certs expire. They always have. They always will. A device needs to have support for updating any certs is uses and an OS needs to have support for updating CA certs it trusts. The warning about Android is merely because old versions of Android have no way to update their CA cert list. There is nothing new to see here.

---

<div class="post-metadata">

**Author:** ![big\_D](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/big_d/32/1023_2.png) [@big\_D](https://www.twit.community/u/big_D)\
**Post date:** [November 11, 2020, 2:25pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/8 "2020-11-11T14:25:38Z")

</div>

Correct. But Steve’s point, or rather his re-iteration of the Let’s Encrypt EOL on Android pre-2016 makes it sound like it is a LE-only problem. I was just pointing out that it affects all CAs on those devices, whose root certs are expiring.

---

<div class="post-metadata">

**Author:** ![maguswine](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/maguswine/32/10091_2.png) [@maguswine](https://www.twit.community/u/maguswine)\
**Post date:** [November 13, 2020, 7:19pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/9 "2020-11-13T19:19:43Z")

</div>

All the vulnerabilities in WordPress show show is how popular WordPress is. I’m sure that Xenforo has the same number of issues should anyone go looking for them. The only truely secure websites would, in my opinion, be Web 1.0 sites. WordPress may even be mire secure because, like I said, due to it’s popularity; people are going out of their way to find these bugs.  
Having to wait a year between each Peter F Hamilton book is nothing… I first heard about The Dresden Files series in 2017 and I finished reading them in mid-2018. Then we had to wait until this September before we got another two Dresden Files book.

---

<div class="post-metadata">

**Author:** ![Saguaro](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/saguaro/32/9736_2.png) [@Saguaro](https://www.twit.community/u/Saguaro)\
**Post date:** [November 17, 2020, 2:59pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/10 "2020-11-17T14:59:14Z")

</div>

@Leo I’m in the middle of installing a Ubiquiti home network (UDM, 24-port-poe, cameras, FlexHD APs, etc) in a client’s home, so I perked up when you mentioned mitigating “Slipstream” on you network. I can’t test the Unifi instructions because the UDM-Pro is in a box awaiting on-site install, but I did this on my own Edgerouter. There are two relevant discussions on disabling the ALGs running on Ubiquiti kit…

> **[NAT Slipstream Vulnerability | Ubiquiti Community](https://community.ui.com/questions/NAT-Slipstream-Vulnerability/d33422bd-af15-4208-9ccf-4bc4e89d7891)**
>
> New vulnerability exploiting ALG functionality - https://samy.pl/slipstream/Curious how this affects USG or similar Ubiquiti routing solutions? Has anyone parsed this and come up with places to look to ensure the ALG (if any) helpers are...

> **[r/Ubiquiti - Securing an Edgerouter against the NAT slipstreaming attack?](https://www.reddit.com/r/Ubiquiti/comments/jpojhi/securing_an_edgerouter_against_the_nat/)**
>
> 101 votes and 27 comments so far on Reddit

Seems pretty straightforward for Unifi. Only 10% more difficult on EdgeRouter… Cheers!

---

<div class="post-metadata">

**Author:** ![Leo](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/leo/32/16203_2.png) [@Leo](https://www.twit.community/u/Leo)\
**Post date:** [November 17, 2020, 4:24pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/11 "2020-11-17T16:24:26Z")

</div>

Yeah it looks like the only ALG on the UDM is SIP and that’s off by default. Whew!

---

<div class="post-metadata">

**Author:** ![Saguaro](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/saguaro/32/9736_2.png) [@Saguaro](https://www.twit.community/u/Saguaro)\
**Post date:** [November 17, 2020, 10:08pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/12 "2020-11-17T22:08:59Z")

</div>

Yeah, its strange that it’s disabled on Unifi, but enabled on EdgeOS. That means everyone with the cheap-o ER-X device as firewall has SIP (and FTP, TFTP, H.323, and more) enabled by default…

---

<div class="post-metadata">

**Author:** ![PHolder](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/pholder/32/2439_2.png) [@PHolder](https://www.twit.community/u/PHolder)\
**Post date:** [November 17, 2020, 10:18pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/13 "2020-11-17T22:18:21Z")

</div>

> [@Saguaro](#):
>
> everyone with the ER-X device has ALG’s enabled by default

If they’re expecting the same person to buy one who would by a consumer router then that fits with the competition. (Not saying that’s good, but am saying it’s not unexpected.)

---

<div class="post-metadata">

**Author:** ![Saguaro](https://sea2.discourse-cdn.com/flex020/user_avatar/www.twit.community/saguaro/32/9736_2.png) [@Saguaro](https://www.twit.community/u/Saguaro)\
**Post date:** [November 17, 2020, 10:21pm UTC](https://www.twit.community/t/sn-792-nat-firewall-bypass/8516/14 "2020-11-17T22:21:22Z")

</div>

The ER-X is rather a loss-leader, and is certainly a hardware dead-end, for Ubiquiti. I was not aware all these ALG services were running by default. It’s a rather crazy choice by Ubiquiti.
