Live data from Hacker News

Black Hat 2024: Secure Shells in Shambles [pdf]

i.blackhat.com

21–30 of 33 posts

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#21
post #20
post #19

Earlier quoted context omitted.

Reading your comment I was putting my money on a customized glances - but after checking the slide... Nope, that's just the default view for btop++ (first screenshot in the link) https://github.com/aristocratos/btop

Wow, thank you so much for showing me this. I'll check out glances, too. Any other badass TUI dashboards out there? I wish there were a way to expose these as webpages.

Glances can be started in server mode/exposed as website

https://glances.readthedocs.io/en/latest/quickstart.html#web...

Wrt other CLI apps: the only way to find out about them is to randomly explore, check out projects. I.e. take anything from here https://github.com/agarrharr/awesome-cli-apps

Most people call that procrastinating though ◉ ‿ ◉

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#24
post #21
post #20

Earlier quoted context omitted.

Wow, thank you so much for showing me this. I'll check out glances, too. Any other badass TUI dashboards out there? I wish there were a way to expose these as webpages.

Glances can be started in server mode/exposed as website https://glances.readthedocs.io/en/latest/quickstart.html#web... Wrt other CLI apps: the only way to find out about them is to randomly explore, check out projects. I.e. take anything from here https://github.com/agarrharr/awesome-cli-apps Most people call that procrastinating though ◉ ‿ ◉

;) thanks for making my day ffsm8, cheers.

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#25

Earlier quoted context omitted.

So instead of exposing thoroughly tested OpenSSH to the web, I’m exposing this thing, which can also run shell commands…

Just had a random thought… what about port knocking, but the combination was TOTP’d? Port knocking is visible to third parties… but if the combination was a TOTP nonce, guessing the correct combination would be fairly difficult.

Didn’t have a beef with the general idea or the cryptography (assuming that some form of replay protection was already baked-in) so much as the idea that exposing a novel, less-tested, non-trivial service is a security win. If the implementation (TOTP or not) were dead-simple, I think SPA would be a win, but as soon as we get to dynamic cross-platform firewall-fiddling and custom commands, we are no longer in “dead-simple” territory.

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#26

SSH and other services can be further protected by Single Packet Authentication (SPA), https://github.com/mrash/fwknop > SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to conne…

So instead of exposing thoroughly tested OpenSSH to the web, I’m exposing this thing, which can also run shell commands…

[deleted]

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#27

SSH and other services can be further protected by Single Packet Authentication (SPA), https://github.com/mrash/fwknop > SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to conne…

That is interesting! Is this widely used or are there downsides I am not seeing?

> is this widely used

Single Packet Authorization (SPA) is an architectural pattern of modern cloud security ("Software-Defined Perimeter"), with multiple OSS and proprietary implementations, https://cloudsecurityalliance.org/artifacts/software-defined...

  UDP-based SPA provides the following security benefits to the SPA-protected server:

  ● Blackens the server: The server will not respond to any attempted connections from any remote system until they have provided an authentic SPA that is valid for that SDP system. Specifically, the host will not respond to a TCP SYN, thereby avoiding the disclosure of any information to a potential attacker.

  ● Mitigates Denial of Service attacks on TLS: Internet-facing servers running the HTTPS protocol are highly susceptible to Denial-of-Service (DoS) attacks. SPA mitigates these attacks because it allows the server to reject unauthorized connection attempts before incurring the overhead of establishing a TCP or TLS connection and therefore allowing authorized connections during and in spite of DoS attacks.

  ● Attack detection: The first packet to an AH from any other host must be a SPA packet. If an AH receives any other packet, it should be viewed as an attack. Therefore, the SPA enables the SDP to determine an attack based on a single malicious packet.

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#28
post #20
post #19

Earlier quoted context omitted.

Reading your comment I was putting my money on a customized glances - but after checking the slide... Nope, that's just the default view for btop++ (first screenshot in the link) https://github.com/aristocratos/btop

Wow, thank you so much for showing me this. I'll check out glances, too. Any other badass TUI dashboards out there? I wish there were a way to expose these as webpages.

[deleted]

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#29
post #10

Earlier quoted context omitted.

I didn't realise the old ssh.com codebase was patented, apart from crypto patents like RSA (or IDEA?)

See perhaps: * https://www.ssh.com/legal/patents/ * https://patents.justia.com/assignee/ssh-communications-secur...

Those are all dated after the OpenSSH fork

Re: Black Hat 2024: Secure Shells in Shambles [pdf]

#30
post #4

SSH and other services can be further protected by Single Packet Authentication (SPA), https://github.com/mrash/fwknop > SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to conne…

Every now and then I use GnuPG encrypted emails (or a web form) to my servers to open the firewall for certain IP addresses. If the server can decrypt such a message it can safely act on it. The server's default is to only allow certain network ranges to access certain ports, e.g. from my local providers or employers networks.

Presumably you sign the emails rather than encrypt them?

Otherwise anyone who knew the public key of the server (which shouldn't be presumed secret) could send an encrypted instruction, and it would be acted upon, and past encrypted instructions could be replayed.

Post reply on HN