Hacking Out of a Network - Computerphile
ฝัง
- เผยแพร่เมื่อ 26 ส.ค. 2021
- Multiple ways to break through restrictions in a network* demonstrated by Dr Richard G Clegg of Queen Mary University London.
*Please only try these methods on machines where you have permission.
Richard has kindly prepared some notes: bit.ly/C_RichCleg_HackOut
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computer Science at the University of Nottingham: bit.ly/nottscomputer
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharan.com
“Only do this at home” 1min later… “imagine you are in a train”…
Imagine you are on a train -- but actually you are at home not violating the terms of service of a train company -- that's my official position. :-)
You don't have trains in your house?
I just use node vpn😅
Yes.. "imagine" is the keyword here
I think he means "Practice that at home"...:-)
"do not try this at home" "no, only try this at home", lmao, I am somewhat conflicted on this
Try at home in you home lab. Lol
Here I will simplify it.
Rule 1: Don’t try this at home
Rule 2: Try this at home
But its back to "Do not try this at home if your parents have put locks in place for a reason" :)
Arent we working from home?
Only try This at home =/= Try this Only at home
Didn't he say the second(as in, not on the net)?
We need more technical content like this! Great job!
Students are the best people to ask about how to bypass networks.
This format of screen-sharing is soooo much better than other videos. Please maintain this format of showing everything on the screen. So helpful and so much easier to understand
"Let's get the OHP up."
Smacked me right back to elementary school.
I didn't understand could you explain?
@@violet_flower And private schools
OHP isn't hacked since 1920
My professor 2 years ago tried to explain ssh tunneling for the same length of time as this video and failed miserably. Dr. Clegg explained in half the time and even talked about other ways of doing this while being easy to comprehend. Great video
Or maybe between the two your brain put it together?
I feel like this is how many kids get interested in computers.
Just for educational purposes only... ;-)
During high school, it was incredible to see how even the least tech-interested kids figured out network shares and a bunch of other things when it let them play games in class etc lol
04:35 UFW is actually _Uncomplicated Firewall_ . It's "only" a Python "wrapper" for iptables.
Tnx, I was scrolling to see if anyone else had noted this.
@@kevinjones5001 Same! Glad someone(s) was on it haha
@@kevinjones5001 there are 17 people who noted this in the comments :)
I remember using proxy tunnels way back in the early 2000s. I found a bank in France that had full internet access and proxied in to that over port 8080.
10:54 Unfortunately, this whole section here about TCP over TCP is incorrect in this case. Yes, if you're tunneling raw IP packets over TCP (and there are ways to do this with SSH, for instance using the -w option, running PPP over SSH, or with OpenVPN over TCP, as well as a million other ways), you do end up with the TCP-over-TCP meltdown you are explaining quite correctly. But, if you're using SSH's "dynamic port forwarding" mode which emulates a SOCKS proxy, there is no TCP over TCP at all going on.
There's TCP running between your client software and the SSH client's SOCKS proxy emulator, TCP running between your SSH client and the remote SSH server, and also TCP running from the remote SSH server to the tunnel destination. These are all seperate TCP connections, and none of them of them running "over" each other. They're conseptually connected end to end, not over each other.
There's no raw IP packets going over the SSH tnnel, and thus no TCP. Only the data beloning inside the stream as multiplexed as multiple channels in SSH. TCP retransmissions will happen on every TCP stream, but there's no redunant layer of TCP happening end-to-end over the actual tunnel, and no duplication of retransmission for that reason.
That said, because everything you're doing ends up passing through a single TCP connection, that can definitely be a bottleneck, but for other reasons.
Hmm... The version I show via the proxy is using netcat to transfer data - that certainly is TCP over TCP no? But in the simpler version where do you think the code opening the TCP connection to the final destination runs? At the same side of the firewall as the web browser or at the same side of the firewall as the web server? I can't easily find an answer to that. If that TCP connection originates outside the firewall you are right but I did not think that was how it is working.
I think you may be right here. It shows even when you use tools for many years you can still learn things. When I was reading for this article I came across many pages confidently claiming that ssh -D was TCP over TCP but I think you are correct.
@@richardclegg8027 Hi! Proxy using netcat is also not TCP over TCP. Same as with ssh -D, it's not a TCP session inside a TCP session, it's data exiting from one TCP session and then entering another TCP session. I.e. you're only tunneling the actual data inside the session, you're not tunneling the TCP headers or the retransmssions. The only way you'd get TCP over TCP is if you're running IP over TCP, for example if you're using some kind of VPN software that uses TCP as a transport for IP packets.
To be clear, none of the scenarios you've shown in this video will do IP over TCP and thus not TCP over TCP.
You are right. In days past a similar thing was done with ppp or slirp over ssh which did work like that. I guess this is why the TCP over TCP idea propagated for ssh -D (not helped by the sshtunnel docs which while correct don't clarify). When I read about it lots of places made the claim your explanation is correct.
Ah yes, spent a while troubleshooting that ovpn over tcp a few weeks ago...
Thanks for the knowledge!
One of the very few videos I have watched more than once. Please do more high quality content.
Really nice video. This is what inspires people.
And then you introduce a NGFW with SSL and SSH decryption and loose all the magic.
that's how network engineers are born.... trying to bypass censorship
"The Net interprets censorship as damage and routes around it" - John Gilmore
@@jursamaj when do we bypass musk's twitter?
@@thewhitefalcon8539 Whenever you decide to quit using Twitter.
Yes, TCP over TCP is bad. But there is no TCP over TCP in this case. There are just 2 TCP connections in serial. If you use ssh -w, that would create a tunnel where you are doing tcp over tcp.
Right on, this part is just completely wrong.
4:32 Nope, it's "Uncomplicated FireWall"
Ultimate firewall seems pretty cool though
My apologies for this! You are of course correct.
I've used iodine DNS tunnel for years. It's not fast or efficient but it works. Nobody has ever noticed and none of the many environments I am familiar with monitor DNS traffic for stuff like this.
I just run a VPN server at home, and anywhere I've been (including China) I can just VPN back home and get full normal access to everything.
Haven’t been to China … but yes, I do the same and it works quite nicely :)
Same. I actually had to do this to get around some UDP throttling that a hotel in London was doing to prevent people from using their WiFi for VoIP and video chat.
Wireguard FTW
It even works on airline wifi.
@@Centigradius I also use a site-to-site IPSec VPN between two UDM Pros. No matter where I am, I'm always connected to my home network, which is also connected to the other house network. It's nice to avoid all the guest network monitoring and tracking.
I did this years ago to get around my University's firewalls to play games online... :D
Ah back in the days of Flash games...
I used to do the opposite
hosting a game server on school machine
and tunnel it out with ssh tunneling
and my fds and I can all enjoy free game server hosting
hehehe
So did I, back in 2005.
Why were they blocking online games?
I'm impressed by the fact that his computer is named for a character from Mervyn Peake's Gormenghast novel. Not that your presentation wasn't interesting, Dr Clegg, but my excitement that I'd found another Peake fan eclipsed all else!
I generally call the largest machine I own gormenghast, the cutest fuschia and the smallest barquentine. :-)
We used to do this SSH tunnel way back in 2007 to break out of the NHS network to connect to home. Was a 2nd line engineer and sick of 3rd line monitoring anything you did. Got more work done with that tunnel than without it.
I really enjoy the networking Videos! Hoping for more :)
I traveled around Turkey this month. I had a local sim card for data (Vodafone). There was one region (Antalya) where it wouldn't allow me to connect to my home wireguard peer. Also VPN provider websites had been blocked e.g. Mullvad. This wasn't the case in Istanbul, Mersin or Fethiye regions, very strange.
I'm using a non-default port for wireguard, maybe I should try port 443.
Great Resource 🙌🏻🙌🏻
transmitting data as a subdomain to bypass a firewall is the most hacky janky thing I've ever heard of and I love it.
"try this at home but not anywhere else at all" ---> "so now let's imagine you're on a train or in an airport where the administrator is not giving you full access..."
That escalated quickly.
Wow, this video really highlights the high quality of comp. sci. coming out of Nottingham University compared to others!
Dr Clegg is from Queen Mary University, London
@@johnvonhorn2942 my point exactly 😉
DNS tunneling was used in the SUNBURST (Solarwinds) attack last year, so not sure a normal admin would have detected that method.
If you have your alerts popping on known TTPs, even on simple things like duration, or constant dns traffic from a single endpoint that deviates from the baseline configuration, you can at least look at it and see if that is explained behavior or not and adjust your alerts accordingly. But to your point, it often takes a mature SOC dedicated to notice these things,
So as a network engineer having to defend these issues when setting up networks like such as a "guest" network. For this, I don't use a layer 4 firewall(such as an ASA without firepower) which is what seems to be on the topic for this video. More used in this situ' is a layer 7 Firewall(such as a Palo Alto) where you can allow based on application rather than "Service Port" for "guest" network on a Palo only allow the following applications: dns, web-browsing & ssl. Another option could be adding in decryption for other networks, it doesn't really work for a guest network. Also, I would like to see what you suggest for application(L7) firewalls and to bypass these...
This was fascinating.
Him: Hey, Internet, don't use this exciting information in any way.
Internet: 👍🤔😏
hes talking about very basic things you learn on day 1 networking.
really liked this video, also i like richards way of explaining this stuff. :)
Yeaa.. it remember me the day our IT teacher had to explain how to bypass the school proxy server to setup our own proxy lab. Using proxy for home purposes is irrelevant these days in my option. VPN over 443 and remote sessions (can also be 443) are way more secure and reliable.
Just a quick note.
We are going to try everything you are saying here
19:10 So for the web proxy protection explanation, the workaround where the exit address gets remapped to :22 only works if you have admin control over the web proxy itself right?
First!
No TH-cam? I'm definitely doing this... just to watch Computerphile. Just that. Honestly.
Besides the interesting topic, i like the sound effect used for the firewall at 1:53 xD
Someone I know did that a century ago. (A bit more sophisticated, it was encapsulating everything in multiple TLS streams.) IT security can break normal work so easily. A few years after he established this, someone contacted me. Asking why there was so much traffic to that address from that machine. I said it was a leftover test that seemed to be still running and I cut it down. Since then our security got much better, much more defined and more relaxed. No need to tunnel, no need to dig holes, everyone is happy and safe. Too much security is as dangerous as too less security.
Anyone else notice port 456 blocked "related to mail" (at 4:48)? Me neither. :)
Almost certaionly meant to be port 465, for SMTP over implicit SSL/TLS.
Is smtp not related to mail?
@@teh_jibbler Very, but port 456 is (commonly) not. Looks like Richard needs to change that to 465 to refer to the common SMTPS port.
The word "Disclamer" made me enthusiastic.
Thank you 🙏
I love this video. Though he left out the part about the best tool for tunneling out of a network: GCC and a copy of Stevens.
Hah... that is the advanced edition ofthis video.
Ok. I ssh'ed into Dr. Clegg's home server. Who are all the babes you have 1TB of pictures of?
BTW: Thank you very much for your time you spent with explaining this Dr.
With great power, comes great responsibility 👍
This gave me flashbacks to using 'cu' to hop around different machines on our LAN. ~.
when i was in college in the mid 2000s they tried banning bit torrent in the dorms, but they weren't very secure back then so I just tunneled out using UDP and was able to access non-throttled internet speeds too (15kbps wired in the dorms for all data, 20mbps after tunneling out) stuff is more complicated now though i think, but i thought i was a badass back then haha XD
Is the computer connected to internet and firewall not allowing you to go anywhere ? Can you advise please
I like that last point!
I would really like to know whether I can reach my server via ssh from inside a network which only lets ports 80 and 443 pass - but without having to change the port my ssh server is listening to. What would be needed for that?
in the video he only router a port to point to the port 22, he didn t change the port of his ssh
@@luxraider5384 Yes, that was my question: What if port 22 is blocked in a network, and I need to ssh into my server? I did actually configure my NAT in such a way that incoming traffic goes through another port than 22 (because of the massive load of annoying attempts to log in with a password and some random username, which was never active in the first place). So my question is: Is there a way to have a packet go out on port 80 on my machine and arrive on port, let's say 18650 (for example) on my home server? If so, I'd love the syntax for that ssh commnand - I only know the option -P for the general port (outgoing and incoming). But I'm not sure whether TCP is even capable of having a packet go out on port x and arrive on port y?
Good video
Correct me if I am wrong, but I don't think ssh tunnel is TCP over TCP. ssh tunnel acts like a normal TCP proxy, only that the connection in between the ssh client and ssh server is encrypted, it does not preserve the original TCP header.
You are not wrong. You are in fact absolutely correct.
“lets get the ohp up”
something i haven’t heard in a loooong time
for those who don’t know, ohp: over head projector (made with lights, magnifying lenses and mirrors)
Yes -- showing my age a bit.
I’m sure students do this a lot. What are the consequences? At uni for example, would they be in trouble? I noticed libraries lock well
this is better than most network course labs
A few comments on the last part - not entirely true - in modern web traffic, it's extremely difficult to differentiate between a "normal" ssl websocket traffic and a long-living tunnel. It can be done by pattern analysis, but I doubt train ISP providers monitor for that.
I think you're thinking of websites like gmail that keep alive a long-lived connection. The normal case for SSL is that you make a connection download the website and close the connection. Gmail (and a few other sites) keep the connection alive for extended periods in order to avoid the connection overhead of SSL set up -- but they are the exception more than the rule and their traffic pattern is quite distinctive.
@@richardclegg8027 many websites keep long-running connections - for example notifications, event tracking, data streaming, etc. Also, you have to consider the new technologies coming like spdy and http/2 which (very simplistically said) relies on long-lived connections to minimize roundtrips to the server.
These days though I think most traffic to Google (certainly from Chrome) is actually over QUIC and they deprecate SPDY.
@@richardclegg8027 you're right. I've not followed things recently. I see QUIC runs on UDP, which again can be a carrier for a vpn tunnel. In this case too, you need a pretty sophisticated analytics to pick a tunnel from regular traffic. Maybe it'd be even more difficult as everything is split and mangled in a ton of UDP datagrams. The most important thing is practicality :) If a very simple proxy would keep 99.99% of teenagers from watching 4k youtube on the free wifi, I don't think someone would invest in traffic pattern recognition for those cases :) The cost of running this would certainly outweigh simply providing fast free wifi...
How will any of this work if you don't have local device admin rights and network authentication prohibits LAN devices that don't match a specific criteria i.e. MAC address?
mac spoofing is trivial, and you could either get that from the original machine or sniff it. you'd probably have to power it off if you wanted a reliable connection though
Vpn over port 53. Can even bypass a lot of wifi paywalls iirc because they still allow DNS requests
Many internet service providers here in the United States will reroute any UDP/53 traffic to their preferred nameserver to facilitate user tracking. Other "better" internet service providers will merely monitor UDP/53, but then frequently deny packets that aren't legitimate DNS requests.
As nice and decentralized as our modern internet is, there's some of the worst, most power-hungry people in the world acting as gatekeepers to it.
@@Phroggster So if you want to use Google DNS for example, they will send requests to their private DNS Server? is that even legal?
@@Phroggster VPN over DNS uses valid DNS packets (query/answer), so it looks correct on inspection. Except the fields contain some gibberish data (data encoded with uuencode or some similar encoding). The way a next gen firewall can stop it is with "Domain reputation" - your domain may not be known enough, or not part of the allowed categories. Also intermediary servers may cache replies longer than the TTL value, which can cause mayhem.
Dr Richard Clegg looks like a magician
There are also solutions like guacamole that you can run on the target machine and just serve it under a simple web service. (VNC/RDP or an ssh console)
I hadn't come across guacamole -- thanks for the recommend.
What about arp cache poisoning? Does that still work as a man-in-the-middle route traffic bypass?
That takes me back.. used to have quite a bit of fun with that in the XP days. Haven't tried it in a while for anything, but I would imagine it would attract a lot of attention.
Is it possible to block the application/ssh communication based on what ssh is sending rather than simply blocking a port?
There are firewalls that examine the packets and block based on the type of communication it matches.
Cheers... off to try this on my mates computer now
Love it !
I just set my home firewall to listen on 443, and forward via NAT to my ssh server. So in a nutshell, just set your ssh server to listen on port 443 instead of 22. It's not that complicated.
Very secure networks will close your connection after about 30 seconds, and you'll have to create a script to re-init the ssh tunnel, and close it, over and over.
Also, most networks other than maybe a work network, which still could probably be argued in court, have you agree to not access certain things via their network. If your house isn't one of those things, then technically ssh to your own home server is fair game. Where you go from home isn't technically in their jurisdiction. If their machine is only connecting to yours, then you have ground to stand on. What your machine connects to, is none of their business. But make damn sure your DNS requests are also going to and through your home machine.
Most companies now have a catch all policy that includes not using their provided computers to access XYZ sites. So at that point, you may be hosed. In the end, any admin with enough time on their hands to see that you are using port 443 for different amounts of time, or triggering a disconnect time out rule, is going to have such a hard time proving the rest, plus all the extra hassle of doing so. They're probably going to just pull you aside and say, please don't keep doing this, because eventually I'm going to have to explain it to someone and force it to stop.
I would do this almost everywhere but certainly not in a work environment - an encrypted connection to an unknown destination out of a company network is a big no (could be company secrets) - if I REALLY need access to X I will let IT know and escalate it if necessary 😊
Reliable protocol doesnt need the loss :) - it only can accomodate to the loss - its not needed - if you have a local 10mbps link in your computer - you can set it up to send with that rate, choose any buffer (at home....ofc :) ) and tcp will be working very much without a loss on a connected switch 1gbps inter-network - local IP stack implementation will not allow that TCP connection to start getting congested at 10mbps (of course if your 1gbps inter-network wont start getting congested, or switch power ASIC capacitors wont stop being congested :)
I've never had to go much further than SOCKS over an SSH tunnel on a nonstandard port to bypass poorly-monitored outgoing firewalls. Mostly useful for large businesses with many locations, who provide internet access as a perk to their customers, where individual locations rarely have a dedicated IT staff (restaurants, bars, coffee shops, department stores, salons, spas, outpatient clinics, etc.). Use with caution, and only on the isolated guest wifi, if you're stuck in a hospital and have to get actual work done.
Yes, but have you got fork handles?
Great explanations. Also a light noise reduction would be amazing.
The U in UFW stands for Uncomplicated, not Ultimate.
Yes apologies for the mistake. I am blushing. Should have checked even though it is a tool I use all the time
Wish I could draw that fast in Visio.... Also sudo assumes the right access, ssh assumes the right RBAC in that environment
I guess blocking port 456 is a typo. SMTPs is on port 465 instead
A Stalag 17 special!
Ok mad points for the old school dot matrix printer paper.
If they are using a firewall with a whitelist, doesn't that mean that you need to have your proxy whitelisted?
You must have missed him waving his hands.
Isn't ufw "uncomplicated firewall"?
"Don't try this at home"
*teenagers with school computers* okay lol
Nice!
Closing port 22 is one of the first things I do when setting up a new install :)
It doesn't make your Security better at all... Eventually you face Problems one by one
@@president8 Certainly, but it will remain on my checklist of things to do.
The best set up is blocking every port by default, & only opening the exact ones you need, & only then when you've done your best to protect those particular ports. Eg; only opening SSH after you've created a white-list of permitted SSH source / destination sites.
@@bjarkih1977 but why at all?
@@president8 It's the most obvious place to attack for unsophisticated attacks. Also, why not?
The web proxy thing wasn't explained well. If everything is blocked how do you reach the web proxy? What exactly is it? No explanation was given at all.
Man, this seems so clever and scary to me at the same time.
its very nicely presented here.frankly this is something my school mates and I have used to check social media,in school computer lab , since it was heavyly firewalled network.
4:34 UFW = Uncomplicated Firewall :)
Yup -- sorry for that. You are correct.
I don't think that SSH+SOCKS run TCP inside TCP. The TCP is unpacked on your own computer and the actual data is sent directly over SSH.
Actually, "Uncomplicated FireWall" - not as exciting
The SSHawshank Redemption
my man
6:58 should have edited out that “uuum” … that would have been funny 😂
I'm just wondering why he chose port One Oh Eight Oh
4:40 UFW is Uncomplicated Fire Wall or at least that’s how I’ve seen it
There are other ways for TCP to know it is congested, change in delay or ECN (Explicit Congestion Notification).
so where is the part that you mention VPN
Did anyone get the part where he talked about how to tunnel your way out of a network that only allows you to go through a proxy?
One time at work we wanted to access some site to view various things. Turns out their firewall was only plain text, using the IP address directly worked a charm
It has become necessary (in this day and age) to change your exposed ssh port anyway in order to avoid a few thousand attempted malicious logins everyday anyway. Making ssh available on something like port 62244 keeps your auth.log from growing too large.
That's nuts!
The last element, that the attackee needs to get lucky every time, is actually a reversal of the better-accepted aphorism:
A well motivated attacker will always win, because they only need to succeed once. Defenders must win all the time.
Now for egress I can see some of the logi in the statement made by the blue team guy, but the solutions are relatively straightforward for me:
hide in plain sight
go low & slow
live off the land
ensure you only depend on things the target can't take away without committing self-harm
(Full disclosure: I'm a red teamer, not a criminal 😁)
Now you need a part 2: "How to hack out of a system with no Networking hardware."
Skynet would love that. And i know is possible(the spontaneous creation of life kind of possible(we are here so it is possible) or at least half way to that) though highly unlikely, like trough the electrical grid or with flicking the display on and off of the system at a camera connected to the internet.
It's a bit more than "cheating" in inverted commas. You manipulated the web proxy, something you typically have no access to. Better would have been to run SSH on port 443 on the twisted server.
TCP over UDP over TCP
dns tunnel pretty simple to setup , I find the ssh tunnelling frys my brain half the time
Would not work against any next gen firewall that does application traffic matching