Get me the real IP - Game

Get me the real IP http://5fu3ch6kjhdet3l5.onion/ Objetive: You are in a linux shell running "some place", you can use internet, but all the traffic is routed throug TOR, you need to bypass this forced routing and get the ip of server who serves the container.

this is a toughie.

>>3577 Yes, but it has a solution. You need to think out of the stablished ;)

someone got down the server. Please, don't be jerk.

The real IP is 10.46.4.27

How hard would this be for someone who knows only the basics? What do I need to learn?

I opened the terminal and ran some command I found on google. The ip is 127.0.0.1 What now ?

>>3587 https://pastebin.com/YU6J1AH3

>>3589 Can be reduced to >X: wat ur ip >Y: 127.0.0.0 >X: lololol i hax u >X: ur so done kid >[X disconnected]

Come on Lains we can do this. I nmap 10.99.99.1 it has a ton of open ports but I cannot connect to any of them (they close the connection right away). I think it is a troll, the answer is not to break out of the VM.

We have a winner :-)

>>3590 It is a joke as old as time http://bash.org/?38640

>>3586 it's relative hard, this game it's about networking, you must know some about this, and how to search differents ways to connect through the network until find the vulnerability. Knowledges about Linux and command line are necesary too.

>>3592 Your traffic is routed though tor, basicly when you send a syn package this is redirected to TOR who accept the petition, but if you want to connect to some one, TOR can't resolve the class C ip address 10.99.99.1. It's not a troll, and there is already a winner from lainchan :)

>>3585 how'd ya do it?

>>3597 He don't resolved it, that do not is the answer. The true winner is "Klamp".

>>3596 This is the reason why it seems all ports are open on the gateway? That makes more sense.

>>3599 yeah.

Someone wants pentesting on their market lockdown setup.

>>3601 What would that be?

Looks like I am too late. Can you please post the answer for educational reasons?

>>3605 You are on time, I will to getup the challenge for all this week. (I'm exos)

>>3604 The biggest risk with running an onion site is having the real IP address discovered and the server cloned and investigated. Finding an exploit in your website software and then pinging out to get the real IP is one of the most common techniques to do this. OP is clearly working on preventing this from happening, but with a benign page rather than something that would get them arrested.

>>3608 Un this case the website Is only a plain html, when you connect via SSH a new vm is created inner a network who force all traffic by TOR. You have root user, the vuln is in the network.... I'm talking so much :P

>>3609 Someone who exploited your site would get a shell as well. Hopefully not root but you want to prepare for the worst case scenario. This is testing the setup so even if the attacker got a root shell on the VM or box hosting the website they still would be unable to find out the real IP.

>>3621 I'm think the better solution is a secure network, with cgroups, vlans, etc it's reltivelly easy. In a real scenario I would not use docker, this apply his own rules to iptables, but I has good experiencie with lxc. This game Is based in a little configuration error, I don't will to talk too much about it, until the saturday when I will to revel the error for educational purposes. Until that day they have time to keep trying.

Put a Whonix gateway between your site and Internet. Disable SSH. Great, you're fabulous, now no one is gonna hack you unless they're CIA with 0days.

>>3623 Yes, nice, but the objetive of use a paravirtualizated instance with a hard network configuration who only allows you to exit through TOR adds a security layer. Basically you need: * break the hidden service (webshell, RFI, etc) * escalate privileges to execute as root * good! you are root, but in a cgroup's sandbox, you have two options from here; 1- Can jump out from the container, and be root in the host 2- Find some weakness in the host network configuration that allows you to exit to the internet for tracerouting packages that allow you to find the physical location of the server This game is based on the second. Be fun :)

>>3624 Are you gonna reveal the answer, exos? or is it already over?

>>3676 He said it is all about networking. Think about the classic interview question "What happens when you type google.com into your browser's address box and press enter?". How does Tor and the transparent proxying fit in? Are there any possible gaps that let you get data out without Tor?

Has someone cracked this yet?

>>3677 >Has someone cracked this yet? At least one person has.

>>3677 Based on this hint and the tools provided, I'm guessing there's a DNS leak. I don't have the networking skills to confirm though

>>3682 This would be a good opportunity to learn such skills and see if you are right. That's pretty much the point of games like this right?

>>3601 You think it's the same poster as >>>/Ω/7307 ?

Hi! Exos here! Sorry, I was pretty busy, and I forgot this to. :P >>3676 I'm going to reveal this in this post... wherever, I going to maintain up the game some days more to get all you the oportunity of test it. >>3677 You were on the right way, if you separate this by parts, you have the following steps: * Make a DNS request for www.google.com * Send a syn package to the ip of www.google.com port 80 * Establish a new connection * Send a request (a.k.a layer 7 of OSI) In this case we oviate the redirection to https (443). In one of these steeps we have the solution to the problem. >>3678 There was three winners, the first one is "Klamp", came from this site, the seconds one is a co-worker who wants to remain anonymous and the third is a colleague from a team where I participate called KakThePlanet. >>3682 You are right! maybe you needed to read a bit to know how to exploit it. As #3685 says. >>3693 No, I'm not that guy, and if I were I would not publish my recipe in the same place that I confess to having something illegal xD. ---- Finally; The weakness was in the DNS's resolution, all the TCP traffic is going forced through TOR but the UDP that was blocked, except for calls to the port 53 UDP (DNS). All the winners sent a DNS petition to an own server and getting the remote ip with tcpdump, ex: Game container: # dig www.google.com @my.own.host On my.own.host: # tcpdump -i eth0 udp port 53 A solution I would have used is the myip service of opendns: # dig +short myip.opendns.com @resolver1.opendns.com The network configuration for docker network is: # docker network create --subnet=10.99.99.0/24 -o com.docker.network.bridge.name=torbr0 --internal --driver bridge tornet When: * --subnet=10.99.99.0/24: Use this subrange, by default docker takes the *.1 ip for the bridge * --driver bridge: Use bridge driver (this is by default) * -o com.docker.network.bridge.name=torbr0: Send an option to bridge drive for manage this interface with iptables * --internal: Declare the network as "internal" to avoid docker makes the forward rules The script who I use to up the game: #!/bin/bash set -o xtrace # Output iface (the real network interface) OUT=eth0 # Bridge iface (created by docker) TOR=torbr0 docker stop pdnsd || echo -n "" systemctl stop docker sleep 5 iptables -F iptables -t nat -F sysctl net.ipv4.ip_forward=1 systemctl start docker sleep 5 docker start pdnsd sleep 5 # Remove some docker rules iptables -D DOCKER-ISOLATION ! -s 10.99.99.0/24 -o torbr0 -j DROP iptables -D DOCKER-ISOLATION ! -d 10.99.99.0/24 -i torbr0 -j DROP # Redirect all TCP "new" traffic through TOR transparent (port 9040) iptables -t nat -A POSTROUTING -o $OUT -j MASQUERADE iptables -t nat -A PREROUTING -i torbr0 -p tcp --syn -j REDIRECT --to-ports 9040 # Enable UDP prerouting iptables -t nat -A PREROUTING -i torbr0 -p udp -j ACCEPT # Enable all stablish connections iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Finally, accept forwarding of the port 53 UDP iptables -A FORWARD -p udp --dport 53 -j ACCEPT iptables -A FORWARD -p udp --sport 53 -j ACCEPT # But drop all other UDP traffic iptables -A FORWARD -j DROP I hope you have fun PS. Sorry for my poor english :)

>>3696 Damn, that seems like A LOTTA WORK. This just proves that not just anyone can run a tor hs website. You really need to know your soykaf! LIKE REALLY! I wonder haw many DNM's really go the extra mile to ensure their infra is up to the mark. I mean their threat model definitely involves three-letter-agencies and not to mention their competitors.

>>3696 >A solution I would have used is the myip service of opendns: > # dig +short myip.opendns.com @resolver1.opendns.com What? Easy as this? Too bad, I overanalyzed the problem, I thought the vulnerability lies in step RETRACTED, which can be exploited by RETRACTED, but I don't have the time to try it or get my own IP exposed so I gave up. But the actual bug lies in step 1... Anyway thanks for your wargame. Most wargames are just about classic Unix traps and buffer overflows, while I don't have much knowledge on analyzing binaries for buffer overflows and truly need to invest time learning it, but these old-fashioned wargames are clearly boring, this Tor wargame is really creative and relevant to modern Internet. Perhaps I could setup a wargame just like yours, with the vulnerability I just described for people to challenge themselves?

>>3697 >I wonder haw many DNM's really go the extra mile to ensure their infra is up to the mark. It's not rocket science. If you truly want to add the three-letter agencies in your threat model, the solution is extensive, complete isolation rather than find and plug individual security holes that leak the information (see Qubes, it's not the most secure Linux-based system but they survived Meltdown), with careful programming and system administration. The problem is these solutions often have lots of overhead on system performance and sysadmins. The extra security creates inconvenience and real burden for maintenance. For example if you disabled ptrace() for security, one day a program keeps crashing and you can't even use a debugger to find out the reason without rebooting. Or you have to entering your Full Disk Encryption password ever time the server is rebooted, etc. You only know your security is okay when nothing happens anyway, so most people just ignored these possible improvements and protections until it is too late. Also, it is still extremely easy to make a fatal mistake (e.g. accidentally type your own name, or an important password to an untrusted website) even if security is not a problem. But as I stated, good security is not only possible, but also doable for most people with a reasonable sysadmin skill, the toolbox is full of free software and available for everyone. You need to think hard and work hard, but there's no actual technical difficulties such as the understanding how the kernel works.

>>3699 >It's not rocket science. Well, I would say it is close enough to it. Imagine getting everything right from securely setting up the tor hs to practising rigorous OpSec. You cannot get everything right all the time. You make mistakes. This is why you don't run a service for too long. You need to shut it down, before you gain too much heat.

>>3697 > Damn, that seems like A LOTTA WORK. A few months ago I made a recipe (sorry if recipe is not the just word) using bridges and LXC after reading a paper from a guy that used kvm and vlans to isolate the network. I look for doing the same with Docker, once I arrived at an acceptable result, I found it fun to do the wargame. What I'm going, I did not come up with all this for the game exclusively. Thanks for your comment. I'm a curious hacker (M.I.T way definition) that loves doing out of the box things while learning and in some way share those acquired knowledge. For now I have nothing to hide from three-letter-agencies, but I am worried about privacy issues. >>3698 Unfortunately, time is what we all lack. I'm very lazy with reversing, it's a pending knowledge. The attack vectors could be many, so I clarified at a time that was in the networking. > Perhaps I could setup a wargame just like yours, with the vulnerability I just described for people to challenge themselves? Come on! while more challenges more fun! These types of challenges are a good way to play in these times where send a ping to google can be a crime in some countries. >>3699 > If you truly want to add the three-letter agencies in your threat model... I would like to clarify one thing, this model, definitely, IT'S NOT RECOMMENDED. Docker was made for other used cases, and trust your safety in a 10 lines bash script never going to be a good idea. It's true that complexity adds attack vectors, from my point of view, security has to be managed by layers, simples but efficient in their task. One of this layer can be in the network isolation.

>>3701 Exos, this all seems pretty cool and soykafe. But how do you mitigate this kinda stupidity? DNS and Tor don't go really well together. DNS lookups passing through Tor usually fail from time-to-time. Tor only does TCP, whereas port 123(NTP) and DNS port 53 depend on UDP. btw, NTP is this whole other issue that needs to be dealt with while working with Tor HS's!

tl;dr: if you need security set up a hardware whonix gateway or similar design tor-only appliance when you need a complete security without compromise. Virtualization won't save your ass.

>>3700 >It's not rocket science. >Well, I would say it is close enough to it. Imagine getting everything right Yes, I do agree. Sounds more like some serious mechanical and architectural engineering. >>3702 > DNS port 53 depend on UDP. Not true, DNS does have a TCP fallback. and Tor itself supports "DNSPort", though only A and AAAA is supported, but enough to prevent DNS leaks. > btw, NTP is this whole other issue that needs to be dealt with while working with Tor HS's! People do realize this issue. Jacob has written a tlsdate tool to fetch time from the TLS protocol field of well known websites a long time ago, you probably should use sdwdate from Whonix nowadays. Unfortunately they don't give your sub-second accuracy, but suitable for most webservers. https://www.whonix.org/wiki/Sdwdate >> If you truly want to add the three-letter agencies in your threat model.. >I would like to clarify one thing, this model, definitely, IT'S NOT RECOMMENDED. >Docker Don't misunderstand me. Docker is NEVER a security solution. I meant other way for isolation, e.g. several QEMU boxes, definitely not Docker. >>3705 This. and containers != virtualization.

>>3705 Under the Whonix download page the no-host option says it's experimental and it's more suitable for advanced users? It's been like that for many years IIRC. The Whonix vbox images are well maintained though. And I don't think you can run Whonix headless. Can you? It comes pre installed with KDE. Which is just fugly! Although, I trust Whonix to chose that DE coz they always know better.

>>3705 Can a Wi-Fi access point work for this kinda setup? Since the Wi-Fi AP can act as a gateway to any device that connects to it. Maybe choose OpenBSD? Use it's default firewall PF for route everything through Tor? There was this person on the hub who uploaded a very detailed Tor router setup which involved applying grsec patches back when they were "OSS". It was very very detailed though.

>>3709 >applying grsec patches back when they were "OSS" I have been running on grsecurity for years. And now it's a real hard time. Mainline Linux: vulnerable to common root exploits as usual, grsec said the half-baked hardening patches from KSPP may even introduce more of them. Grsecurity: v4.9 backport forever if you don't have 10,000 dollars to pay to Bruce Spendler. It was pretty much okay, but now v4.9 is vulnerable to Meltdown. Or get mainline and vulnerable to privilege escalation attacks... Minipli said he want to packport KAISER or KPTI but no roadmap, depends on his personal interest. Others: NetBSD, HardenedBSD, FreeBSD and other systems are all vulnerable to Meltdown. This makes Qubes the only survivor, Xen is definitely not the best virtualization tech and Qubes is probably not the most secure system, but... We really need a headless version of Qubes, Tails and Whonix. After Meltdown is patches by everyone, we can just go back to use grsec v4.9 and OpenBSD for a while. I wonder if HardenedBSD is going be a long-term solution, they are investigating the possibility to port advanced features such as UDEREF from grsec to FreeBSD kernel.

>>3712 Did grsec pushed changes to its patchset to mitigate spectre/meltdown or did they already forsee that like they did many other exploits. Honestly, Brand and Co are fuarrrking geniuses atleast in context to Exploit Mitigation under *NIX. I do agree on what he said though something under the lines of "Everyone should be involved in security and learn how it works and shouldn't be like I'm gonna apply this patch and call it a day." But then not everyone is that technically competent like he is! Anyhoo, Whonix/Qubes don't have a headless version? I remember reading the whonix wiki on how to compile the entire thing yourself thereby choosing your wm/de. Packages you don't want and soykaf similar to that?

>>3708 The gateway is basically a router with hardened Debian that sends all traffic through tor only. And you can run it headless with serial console for troubleshooting. Only workstation part uses KDE.

>>3712 >gotta switch os to avoid MELTDOWN Just because a bug has a name and logo and theme song doesn't mean you need to base all your decisions around it. It allows code that is already running on your system to very slowly *read* arbitrary memory (assuming the attacker knows enough about your specific system to find anything useful). Chill out. https://xorl.wordpress.com/2018/01/10/thoughts-on-meltdown-spectre/ >>3713 >Did grsec pushed changes to its patchset to mitigate spectre/meltdown The Linux fix for Meltdown is basically a whole new feature, separating kernel space and user space into different page tables. Grsec is just a bundle of patches on top of Linux so if it's fixed in Linux it's fixed in Linux + Grsec. https://lwn.net/Articles/738975/ >or did they already forsee that like they did many other exploits Doubt it but who knows. I stopped following what spender does and says since the last episode of cringy drama. There has been rumblings about these kinds of attacks for the past few years though so I'm sure it didn't surprise most people. https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/

>>3697 >I wonder haw many DNM's really go the extra mile to ensure their infra is up to the mark. I mean their threat model definitely involves three-letter-agencies and not to mention their competitors. Not enough. The original Silk Road didn't even disable requests from outside of Tor, so when the feds got the IP, they confirmed it by visiting the IP over the clearnet and getting the Silk Road homepage. On the /r/onions subreddit, someone posted the IPs of a few hidden services just a couple days ago, each of which can be visited over the clearnet: https://www.reddit.com/r/onions/comments/7qnbt5/deanonymization/ The uncensored hidden wiki is on that list. Which is funny, since the uncensored hidden wiki had their original private key leaked a couple years ago. I guess their opsec hasn't improved much. >>3696 Damn, I was right to guess DNS leak. I wish I would have taken the time to look into exploiting it. >>3698 lainchan war game when?

>>3702 In this case the failure was left consciously, TOR has it own DNS port, securing that rule can be: iptables -t nat -A PREROUTING -i torbr0 -p udp --dport 53 -j REDIRECT --to-ports 5353 And in torrc: DNSPort 5353 In this particular case, NTP doesn't matters because the container depends from the synchronization of the host, In a real isolate network a simple solution can be host an NTP on the GW. About DNS and it problems with TOR, I used to use a configuration with DNS cache server (I use pdnsd), who adds failover and DNSCrypt (lamentably discontinued) who use https (TCP). I wrote a post about it (in spanish): https://wiki.exos.ninja/linux/desk/dnscrypt-pdnsd >>3705 This is a proof of concept, there are projects using Raspys as routers. >>3707 Thank you for the information. > and containers != virtualization. containers = paravirtualization, do not underestimate it

>>3717 >lainchan war game when? Too busy these days, I guess I can set it up before the end of this month, stay tuned...

>>3714 No, even the whonix gw starts up KDE. Doesn't it? You can run headless? How so?

>>3722 Out of curiosity, while I didn't play with the challenge, did you secure it against SCTP escapes as well?

>>3727 SCTP? What's that? and how do you prevent them from escaping? Is it really critical If I one doesn't block them? *Not Op*

>>3729 SCTP is a comparable protocol to TCP or UDP. It's often forgotten, but it's been supported by the Linux kernel for quite some time. You should be able to block SCTP with iptables relatively easily. And it can allow a breakout from a transparently tor proxied environment where you have a shell, etc. It's not much of a concern for the average idiot using Tor, because they fuarrrk up constantly anyway, but it's worth thinking about if you're trying to be serious.

Bumpty-bump-bump! This thread is interesting!

apt-get install iptables-persistent ipv4 > no ipv6 > no Your IP address is 176.223.113.26 in Switzerland if you know how to reinstall the iptables program and debug it you will be just fine

that doesn't work switch. It does not always display "Anonymous Proxy"; but you are still in the tor network

>>3753 176.223.113.26 is a Tor exit node. https://whatismyipaddress.com/ip/176.223.113.26

From what I know about tor , using a transmission-daemon server and adding a torrent would reveal it's ip. (i don't know if an 'attack' is required tho) && the iptables seems to be a dead end since we don't have the permissions to do anything.

>>3756 wll that even work? I mean should you trick the person into downloading a torrent that you created or...? But then the system is transproxied isn't it? how will that reveal the ip address?

>>3771 >how will that reveal the ip address? Bittorrent uses UDP and Tor can't handle UDP so there is a possibility to leak I guess. I think its poor form for >>3756 to not even do a basic level of research before posting.

bump-d.

>>3781 Important question. How does Zeronet work through tor? As I understand it Zeronet is just a special application of the bittorrent system, is it not? Yet they recommend running it in combination with Tor, which in theory should be prone to leakage if it's the actual system which doesn't work. What exactly is it that causes the leakage with Tor?

Not all bittorrent traffic is UDP, in fact it was designed to be TCP at the beginning. The µTP (Micro Transport Protocol) extension and UDP trackers create the UDP traffic, the bitorrent would work fine over Tor if properly isolated with whonix or tomoyo for example.

most of this thread is over my head. Should I just learn general networking or are there any good resources for this type of stuff?

>>4710 TOMOYO?! do anybody even use it anymore(not that someone has used it before) ? I haven't seen anybody use like... ANYWHERE!

its gone