1 / 23

Gateway Cryptography

Gateway Cryptography. Hacking Impossible Tunnels Through Improbable Networks with OpenSSH et al. Originally By Dan Kaminsky, CISSP http://www.doxpara.com Shamelessly mangled, retargeted, and reissued by Titus Winters. Summary. This is not how to crack SSH. This is SSH on crack.

Download Presentation

Gateway Cryptography

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gateway Cryptography Hacking Impossible Tunnels Through Improbable Networks with OpenSSH et al. Originally By Dan Kaminsky, CISSP http://www.doxpara.com Shamelessly mangled, retargeted, and reissued by Titus Winters

  2. Summary • This is not how to crack SSH. This is SSH on crack. • 1) How to get there from here • 2) What to do once you get there • 3) Making getting there easier

  3. The Basics • Bringing people up to speed • This is not another talk about the wonders of a simple local port forward • What OpenSSH does • Forwards a shell (w/ transparent X support) • Forwards a single command (with full stdio) • Forwards a single TCP port

  4. SSH under Windows • 1) Install Cygwin from www.cygwin.com • 2) Create a shortcut to rxvt • C:\cygwin\bin\rxvt.exe -rv -sl 20000 -fn “Courier-12" -e /usr/bin/bash • bash doesn’t work under whistler yet, so use zsh if you want to retain your tab-completion sanity • 3) Finally enjoy a usable Unix environment under Win32 • Everything in this talk is cross platform, as long as you’ve made Windows cross to another platform • (Still some other things you can do, more on this later.)

  5. Forwarding Shells • ssh user@host • Encryption: 3DES/Blowfish/AES • Authentication: Password, RSA/DSA • Key Generation • ssh2: ssh-keygen –t dsa • Key Authorization • ssh2: cat ~/.ssh/id_dsa.pub | ssh user@host ‘umask 0600; mkdir .ssh; cat >> authorized_keys2’ • SSH 1 / 2: Separate auth – so remember ssh -1 and ssh -2

  6. Forwarding Commands • ssh user@host lsssh –t user@host top • Fully 8 bit clean for most commands, supports (unclean) TTYs for anything that wants to redraw screen (like top) using –t • Full STDIO(stdin/stdout/stderr) support • Allows pipelines across multiple systems

  7. Command Forwarding:CD Burning Over SSH • mkisofs reads in files and spits out a burnable image • cdrecord burns the image. • Normal CD Burningmkisofs –JR files | cdrecord dev=#,#,# speed=# - • Remote CD Burningmkisofs –JR files | ssh user@host cdrecord dev=#,#,# speed=# - • Remote CD Burning From Windowsmkisofs.exe –JR files | ssh.exe user@host cdrecord dev=#,#,# speed=# -

  8. Command Forwarding:File Transfer w/o SCP • # GETalicehost$ ssh alice@bobhost “cat file” > file# PUTfalicehost$ cat file > ssh alice@bobhost “cat > file”# LISTalicehost$ ssh alice@bobhost “ls”# MGETalicehost$ ssh alice@bobhost “tar -cf - /etc” | tar -xf –# RESUME GETalicehost$ ssh alice@bobhost “tail –c 231244 file” >> file

  9. Forwarding Ports • ssh user@host -L8000:127.0.0.1:80ssh user@host -R80:127.0.0.1:8000 • Separates into “listener” vs. “location” • If local listens, the destination is relative to the remote location • If remote listens, the destination is relative to the local location

  10. Limitations on Port Forwards • By default, only the systems directly hosting the listener can connect to it • Local forwards can be made public using the –g option, but remote “gateway ports” must be enabled using GatewayPorts Yes • Destination locations are unrestricted

  11. Accessing a Port Forward • Application Layer • Connect Directly to 127.0.0.1 or “localhost” • Operating System Layer (“systemspace”) • Pre-empt DNS lookup in hosts file • Unix: /etc/hosts • Win95: \windows\hosts • WinNT: \WINNT\system32\drivers\etc\hosts • All forwards must be preannounced, and share the same IP (127.0.0.1)

  12. Problem:Static Forwards Are Inflexible • Work decently only when: • Each port is only used once • Passes: • Mail(smtp, pop3, imap) • Simple Web(HTTP) • Fails: • Web Surfing Multiple Sites (HTTP) • P2P File Transfer(Napster, Gnutella), • Ports are predictable in advance • Fails miserably • FTP, both Active and Passive

  13. Solution:Dynamic Forwarding w/ SOCKS • ssh user@host -D1080 • SOCKS4/5: An in-band protocol header, nothing more, that allows the client to very quickly tell a proxy server where its actual destination was • SOCKS4 is extraordinarily simple • ~9 bytes from Client, 8 byte response, and the client has informed the “proxy” where it actually wants to go! • “Library Preloads” are excessive • The idea: Run a trivial SOCKS daemon in the ssh client; use it to redirect the destination of each channel.

  14. Dynamic Forwarding:Application Support • Most major Windows applications support SOCKS proxies directly • Internet Explorer, CuteFTP, IM Clients, P2P Clients(Napster, Gnutella) • Dialpad (Voice over IP to a telephone for free over SSH!) • SocksCap32 can be used to “Socksify” remaining apps on Windows • Outlook Express, LeechFTP, Media Player, etc. • Unix applications can be reasonably socksified too

  15. ProxyCommand:Blind Proxying w/ SSH • ssh -o 'ProxyCommand arbitrary_tool proxy %u %h %p' user@10.1.0.1 • A ProxyCommand is an arbitrary tool that, after it finishes executing, leads to an 8 bit clean path to an SSH daemon • OpenSSH's excuse for SOCKS support :-) • Allows end-to-end crypto through any 8bit clean link • Like SSL over HTTP Connect

  16. No Internet Accessible Bastion Proxy: Now What? • proxy$ ssh user@client -R2022:127.0.0.1:22client$ ssh user@127.0.0.1 -o "HostKeyAlias proxy" -L8000:www-internal:80 • Turns inability to trust into irrelevancy of trust • Negative: “You can’t trust the addresses of x, y, or z!” • Positive: “It doesn’t matter if you think you’re talking to the addresses of x, y, or z.” • MUST CHECK HOSTKEY – it’ll work even if you don’t

  17. Cross-Connecting Mutually Firewalled Hosts • server$ ssh proxyuser@proxy -R10022:127.0.0.1:22client$ ssh -o 'ProxyCommand ssh proxyuser2@proxy ‘nc 127.0.0.1 10022' user@serveror in my syntaxclient$ ssh proxyuser2@proxy/10022 user@server • Again, as long as IP addresses cannot be trusted, it doesn’t matter that you’re talking to the proxy and connecting through one of its ports.

  18. Expanding Escape Syntax • noname# ~?Supported escape sequences:~. - terminate connection~R - Request rekey (SSH protocol 2 only)~^Z - suspend ssh~# - list forwarded connections~& - background ssh (when waiting for connections to terminate)~? - this message~~ - send the escape character by typing it twice(Note that escapes are only recognized immediately after newline.) • Eventual goal: Port both ssh_config syntax and ssh command line syntax to the escape character mode • Allow on-demand things like activation of X forwarding

  19. ((Secure SU:The Battle Against Direct Root • Most “security gurus” will decry direct root login • Holdover from the battle against admins doing everything as root • SU is a painless enough context switch • If it hurts to switch, people will just do it all as root • Advantages to being forced to switch accounts • Inertia • Emotion – significance of the action is emphasized • Accounting – logs show who used root • Even though it essentially reduces the security of the root account to the security of the Alice account, even OpenBSD (2.7, at least) still exhorts users not to ssh directly to root, and instead to use SU.

  20. Secure SU:The Near-Perfect Compromise • alicehost$ ssh alice@bobhost -t “su –l root”SSHD creates a secure execution environment when commands are explicitly specified • Shell configuration files not loaded • su, as a setuid app, can’t generally be traced by ordinary users • User logs in as normal, is safely prompted for the root password, gets a root shell without having to “slum” in through insecure space

  21. Secure SU:Developing: Individuated Root • Individual Public Keys For Root Access • Nobody learns root password • authorized_keys contains list of identities allowed to connect as root to the system • SSHD modified to log who connected to root • Scales to multiple security-critical accounts • Root can modify its own authorized_keys, but other accounts could have root owned, root readable authorized_keys files. • Individual Root Accounts • Multiple accounts all set to same UID, but with different passwords • Alice_Root, Bob_Root, etc. • Really only works for root

  22. Stranded? • mindterm – Java applet with full port forwarding / proxying capabilities. • Google for “mindterm”, find an available installation of the applet. • If you’ve got web and outgoing SSH, you’ve got access to the world.

  23. Conclusion • ssh is powerful • ssh is flexible • ssh is fun. • any questions? any requests?

More Related