EvilZone
Hacking and Security => Hacking and Security => : m0l0ko July 27, 2013, 09:17:42 PM
-
The wifi spot I'm using at the moment uses Antamedia to charge people per hour of internet usage. As a learning exercise, I'm pondering possible ways to bypass this. Heres the login page:
(http://gyazo.com/cfd7cb97fc420ed3f6186728a922190f.png)
when you buy internet time, they either give you a username and password, or a ticket number. Heres an example ticket: AXDPGU
For a system like this to work, I'm guessing all internet users have to connect first to a server which has antamedia installed on it, then this server acts like a man in the middle. The login page is located at http://192.168.37 (http://192.168.37).1 so I'm guessing thats the IP of the server. When I run nmap -O on it, it tells me its a Windows Vista machine.
-
Interesting.
Can you ping to 8.8.8.8?
In that case it could be DNS filtering , which is retarded but used often.
You could tunnel DNS traffic over other ports etc.
Are you able to make a TCP handshake with others on the network?
Did you scan that Vista box for open ports/vuln.
Is it plain HTTP or SSL (the login page)
You could sniff traffic to obtain other machines that are loggin in :)
-
The ticket number doesn't look too complex and is probably a randomly generated string. You could easily make a python script to brute the ticket numbers.
Or you could just use "THC Hydra" or "Medusa" (both linux tools) to brute the ticket, but for that you'll need to generate the ticket wordlist anyway.
"Cain&Abel" for windows might be capable of such stuff, but I'm not sure...
-
Yep, I can ping 8.8.8.8. Only when I'm logged in with my ticket, not when I'm just connected to the LAN without being logged in. I don't know what that means, this is the first I hear of this 8.8.8.8 IP. I notice that some web pages are restricted, when I try to visit them I get redirected to a block.opendns.com page. When I'm not logged in with a ticket (or username + pass) and I try to access the internet, wireshark shows DNS requests being sent between my IP and 192.168.137.1. Do these details back up your theory that they are using DNS filtering? Would that mean this Antamedia system works by directing all DNS requests to 192.168.137.1, then checking to see if there is an active ticket/username session, before responding to the DNS request? I'll look into DNS tunneling but I don't think I'm knowledgeable enough yet to be able to figure out what to do here.
I don't know what a TCP handshake is yet, I'll have to look that up. The Vista machine has plenty of open ports, I haven't checked for any vulnerabilities yet. The login page is plain HTTP.
I bet I can hijack other peoples tickets by ARP spoofing an IP that is logged in with their ticket, but that would be sloppy and I wouldn't want to steal other peoples time like that. Brute forcing a ticket would be sloppy too, and they would rapidly figure out that someone is stealing tickets. Plus, most of these tickets are 8 chars long, so it would take me an ungodly amount of attempts before hitting a correct combination of chars. If I was the admin, I would ban any MAC address that makes more than 20 consecutive wrong attempts.
-
Yep, I can ping 8.8.8.8. Only when I'm logged in with my ticket, not when I'm just connected to the LAN without being logged in. I don't know what that means, this is the first I hear of this 8.8.8.8 IP. I notice that some web pages are restricted, when I try to visit them I get redirected to a block.opendns.com page. When I'm not logged in with a ticket (or username + pass) and I try to access the internet, wireshark shows DNS requests being sent between my IP and 192.168.137.1. Do these details back up your theory that they are using DNS filtering? Would that mean this Antamedia system works by directing all DNS requests to 192.168.137.1, then checking to see if there is an active ticket/username session, before responding to the DNS request? I'll look into DNS tunneling but I don't think I'm knowledgeable enough yet to be able to figure out what to do here.
I don't know what a TCP handshake is yet, I'll have to look that up. The Vista machine has plenty of open ports, I haven't checked for any vulnerabilities yet. The login page is plain HTTP.
I bet I can hijack other peoples tickets by ARP spoofing an IP that is logged in with their ticket, but that would be sloppy and I wouldn't want to steal other peoples time like that. Brute forcing a ticket would be sloppy too, and they would rapidly figure out that someone is stealing tickets. Plus, most of these tickets are 8 chars long, so it would take me an ungodly amount of attempts before hitting a correct combination of chars. If I was the admin, I would ban any MAC address that makes more than 20 consecutive wrong attempts.
The fact that you can ping 8.8.8.8 (which is just google's DNS server) means that your able to get out.
Can you set your DNS server to that and see what happens.
Try that first, try DNS tunneling otherwise.
See if you can browse using TOR.
If that doesnt work out let us know, there are more possible approaches, this however would be the easiest.
-
I can only ping 8.8.8.8 when I'm not logged in with a ticket or username/password, otherwise I get no reply. I'm using Tor right now (otherwise the admins would be reading this thread, they blocked a few sites I was browsing before), but it doesn't work when I'm not logged in with my ticket.
I'm on Ubuntu, any idea how I set the DNS server with this OS? Would it be in firefox settings, or network settings or what?
-
http://www.cyberciti.biz/faq/ubuntu-linux-configure-dns-nameserver-ip-address/
First hit on searchengine...
-
I saw that page but wasn't sure if its what I'm looking for. Heres whats in my resolv.conf file:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search mshome.net
Heres the results of a ping sweep of the LAN:
horse@box:~$ nmap -sP 192.168.137.1/24
Starting Nmap 6.00 ( http://nmap.org (http://nmap.org) ) at 2013-07-28 18:04 IST
Nmap scan report for DVD-Inspiron.mshome.net (192.168.137.1)
Host is up (0.0033s latency).
Nmap scan report for android-3172d9a396fe689b.mshome.net (192.168.137.10)
Host is up (0.0082s latency).
Nmap scan report for 192.168.137.33
Host is up (0.056s latency).
Nmap scan report for 192.168.137.34
Host is up (0.056s latency).
Nmap scan report for box.mshome.net (192.168.137.37)
Host is up (0.0011s latency).
Nmap scan report for Plum.mshome.net (192.168.137.47)
Host is up (0.067s latency).
Nmap scan report for 192.168.137.50
Host is up (0.068s latency).
Nmap scan report for HuyPc.de.mshome.net (192.168.137.114)
Host is up (0.053s latency).
Nmap scan report for Fouad-iPad.mshome.net (192.168.137.181)
Host is up (0.0061s latency).
Nmap scan report for Susans-iPhone.mshome.net (192.168.137.189)
Host is up (0.0075s latency).
Nmap scan report for Eeee.mshome.net (192.168.137.254)
Host is up (0.14s latency).
Nmap done: 256 IP addresses (11 hosts up) scanned in 16.48 seconds
So I see the mshome.net part is something to do with this wifi hotspot. The part that has me confused is 127.0.1.1. I'm familiar with 127.0.0.1, I know that it is the same as localhost, but I don't see why my DNS server would be set to that, unless 127.0.1.1 is 192.168.137.1. What should I change the DNS server to?
EDIT: BTW I'm having trouble finding the routers IP. I don't see it in the ping sweep results. Heres the results when I run ifconfig:
wlan0 Link encap:Ethernet HWaddr 00:1b:77:b2:34:23
inet addr:192.168.137.37 Bcast:192.168.137.255 Mask:255.255.255.0
inet6 addr: fe80::21b:77ff:feb2:3423/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21908 errors:0 dropped:0 overruns:0 frame:0
TX packets:27286 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6755830 (6.7 MB) TX bytes:3354183 (3.3 MB)
If I'm not mistaken, Bcast: usually tells you the routers IP. In this case, 192.168.137.255 seems to be down. I want to test out some man in the middle attacks, but usually I go between the target machine and the router. In this case though, I suppose I'd have to go between the target machine and the server (192.168.137.1).
-
The reason it points to localhost is because on Ubuntu you have a dnsmasq server managed by NetworkManager installed there by default. As far as I recall, at least.
Also you can't edit /etc/resolv.conf directly. It's dynamically generated each time, so you need to use the resolvconf utility instead. Before that, there was a technique to edit /etc/dhcp/dhclient.conf to add DNS servers, but I think that's considered bad practice now.
-
I guess I don't see where bruteforcing the ticket numbers would be anyway effective. If they are randomly generated at the time you buy minutes there won't be any left to retrieve from such an attack.
-
I saw that page but wasn't sure if its what I'm looking for. Heres whats in my resolv.conf file:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search mshome.net
Heres the results of a ping sweep of the LAN:
So I see the mshome.net part is something to do with this wifi hotspot. The part that has me confused is 127.0.1.1. I'm familiar with 127.0.0.1, I know that it is the same as localhost, but I don't see why my DNS server would be set to that, unless 127.0.1.1 is 192.168.137.1. What should I change the DNS server to?
EDIT: BTW I'm having trouble finding the routers IP. I don't see it in the ping sweep results. Heres the results when I run ifconfig:If I'm not mistaken, Bcast: usually tells you the routers IP. In this case, 192.168.137.255 seems to be down. I want to test out some man in the middle attacks, but usually I go between the target machine and the router. In this case though, I suppose I'd have to go between the target machine and the server (192.168.137.1).
If you want to find out who the router is , again all you need is wireshark.
A monitor interface could tell you where other direct their traffic to.
Well I dare to bet the Vista machine is the gateway.
As soon as you have a DHCP lease from the server;
route -n
-
I guess I don't see where bruteforcing the ticket numbers would be anyway effective. If they are randomly generated at the time you buy minutes there won't be any left to retrieve from such an attack.
If you are right about that one possible workaround could be to spoof your MAC address.
If a randomly generated key is tied to a specific host and has a limited time that it can be used (the time someone paid for) you first need to obtain this host's MAC address and then begin to brute force the key. You already have the MAC of other connected hosts from your ping sweep.
This, on the other hand, is not super nice to the person who actually paid for this time since he or she are likely to experience severe connection issues during the time you use his/her MAC..
-
If you are right about that one possible workaround could be to spoof your MAC address.
If a randomly generated key is tied to a specific host and has a limited time that it can be used (the time someone paid for) you first need to obtain this host's MAC address and then begin to brute force the key. You already have the MAC of other connected hosts from your ping sweep.
This, on the other hand, is not super nice to the person who actually paid for this time since he or she are likely to experience severe connection issues during the time you use his/her MAC..
No dont think thats gonna do much good.
Bruteforcing 26^6 and than a key that only has such a short lifespan is just not worth it.
Its gonna be a slow and tedious business.
Not to completely crack your statement but stealing someones MAC address is also going to ruin your own connection.
Your only option there is to send deautentication floods if your in physical range , this would make reconnecting for this person impossible.
Hes is likely gonna complain and drawing unwanted attention in your direction.
Just my 2 cents.
-
No dont think thats gonna do much good.
Bruteforcing 26^6 and than a key that only has such a short lifespan is just not worth it.
Its gonna be a slow and tedious business.
Not to completely crack your statement but stealing someones MAC address is also going to ruin your own connection.
Your only option there is to send deautentication floods if your in physical range , this would make reconnecting for this person impossible.
Hes is likely gonna complain and drawing unwanted attention in your direction.
Just my 2 cents.
You are completely right. Although a 26^6 could be brute forced in hours with say a GTX460 it might not be worth the trouble in this particular case. Then comes the issues with the MAC if the key in fact are tied to the MAC address.
-
You are completely right. Although a 26^6 could be brute forced in hours with say a GTX460 it might not be worth the trouble in this particular case. Then comes the issues with the MAC if the key in fact are tied to the MAC address.
This is not local cracking, GPU's have nothing to do with it.
Poor old online cracking against a probably already overloaded box.
If the software is any good it will also limits the attempts.
-
This is not local cracking, GPU's have nothing to do with it.
Poor old online cracking against a probably already overloaded box.
If the software is any good it will also limits the attempts.
Yeah.. I guess that is very true. It will have to be online.
Well in that case we can probably rule out brute force :)
-
Your only option there is to send deautentication floods if your in physical range , this would make reconnecting for this person impossible.
Keep in mind that sending deauthentication floods would also make it impossible for you to connect with a spoofed MAC address, since you are deauthing that MAC address.
-
Keep in mind that sending deauthentication floods would also make it impossible for you to connect with a spoofed MAC address, since you are deauthing that MAC address.
Lol your right :P
Well lets rule that one out aswell.
-
Well, if you have to enter credentials into the browser after connecting to the hotspot it may have some pre-authentication functions still available for such an attack. I however don't know anything about the software as it may just redirect everything to the console.
-
So has anyone got any ideas? I'm thinking I can ARP spoof an IP who is logged in with a ticket, then the router will think I'm logged in with a ticket. Besides that I don't have any ideas.
-
Years ago(2005), I was contracted to create a solution similar to these. The method that I used was simply to route all outgoing traffic to the device itself. Running a webserver on the device, I provided a page that would request a code. Submission of an appropriate code would trigger a CGI to add a rule to the top of the firewall allowing the submitter to jump the reroute rule. The rule added would include the submitter's MAC address so the IP was unimportant. After a configured amount of time, the system would expire old MACs and remove the associated rules. This meant that to continue use of the system, you had to submit a new code which would re-add you. Since the system expired MACs from a timestamp'd list counting only newest entries, a side-effect was that you could 'refresh' your time with every code submission. The time did NOT stack, so I didn't have to worry about someone purchasing 3 items separately at a location and obtaining 3 codes to use successively which would allow them 72 hours of continuous usage. Again, the aforementioned method did NOT work, so the shop owner was secured from such an attempt.
The only way to 'bypass' the firewall was to spoof one's MAC address to that of another existing user. The problem with this method, however, is that the other user had to have active time left and that means potential traffic confusion if the target is still there. However, if they are not there and they still have active time before expiration, then spoofing their MAC would work. Of course, once that rule was expired, another purchase would need to be made OR another target MAC would have to be spoofed. This could result in a very unstable connection, particularly if the router's configured expire time was 1 hour or less.
Overall, the system that I came up with was extremely simple and I only later discovered its elegance. Because it is so simple, the same concept is easily reproduced on many, many different devices of similar purpose.
It should also be mentioned that commercially-supported devices often need maintenance. As such, a commercial entity *may* decide to provide a bypass rule which matches a specific set of MAC addresses. Because MAC addresses are generated per-device, the first few octets represent the producing company, model, series, etc. As such, a maintenance device could match half-open MAC rule which would define a required model, but leave the specific NIC ID as a wildcard. Doing so would permit any maintenance personnel with an appropriately supplied device use of the system for free. Thus, a hacker *could* feasibly spoof a MAC address that matches a maintenance ID and may find a loophole through the system. This is only a possibility, not a definitive approach.