Related
I am doing some penetration testing, and im trying to find out, if i can get the IP address of an router if i got the bssid, or any i can get with the AIR tools?
I use Linux Kali with the Air tools atm.
I would say this is pretty damn bad if its possible. Basicly most people´s rounters can be reached through their outside IP. Even companies. :O
So far i tried:
- Passive TCPDUMP
- Active scanning
So basicly, is there a way, if so please give me a hint or the answer :-)
I am 100% refering to some sort of scanning. All kind of cracking, bruteforce, password guessing, access stealing is not what im asking about :-)
You can't do that if target access point is protected with WPA/WPA2.
This is why. Getting WiFi to work involves following steps:
Associate with target access point. If access point is using WPA/WPA2 and you don't know the password, then you cannot proceed to further steps, and certainly cannot know anything about IP address of target access point.
After association, your client (which is typically configured to use DHCP) has no IP address assigned (its IP address is 0.0.0.0). Technically, you can use sniffer at this stage to scan the network and find out IP addressed used, but most sniffers don't like to work with 0.0.0.0 address. To proceed further, your client sends DHCP request, which is served by access point. After getting successful DHCP ack with new IP address, client can proceed to next step.
After getting IP address, client can talk to access point and finally knows its IP address (it was served as default router in DHCP ack) - and that would be the answer to your question (yes, that late in the game!). However, even at that point, full network connectivity cannot be assumed. If access point implements captive portal, then your network access may be restricted until you open up web browser and (depending on wireless provider) either accept usage terms, provide some credentials or pay with credit card.
After passing captive portal, it is possible (but not common) that access point automatically re-associates and gives you completely different IP address (and access point also has different IP address now, from completely different subnet). This would mean that IP address you learned in previous steps was completely useless to you in terms of knowing actual network infrastructure.
You would need a Firewalking tool to get past the 0.0.0.0 you would essentially also need a password cracker that attempts different brute forcing to get the matching wep password for example, if there are not max tries it could work.
so suppose I detect a user's ip using some code to perform restrictions....
is there a way for a user to circumvent this by arbitrarily setting their ip to any ip they want anytime they want (eg. via proxy server or something) hence allowing them to choose a specific ip to be displayed when I detect it
There are several tunneling and proxy-based techniques that will effectively present a different IP address for any HTTP requests than the one belonging to the originating computer. I have mentioned several methods in this answer, as well as here. In many cases it is actually impossible to tell apart a relayed connection from the real thing...
In general you cannot forge the source of a TCP connection on the Internet to be an arbitrary address for a number of reasons, some of which are:
TCP is a stateful protocol and packets go back and forth even in order to establish the connection. Forging an IP source address means that you cannot get any packets back.
Some ISPs will drop packets generated within their own network that do not have a source IP within the proper subnet. This is usually done at the client connection level to protect the ISP network and prevent random packets from leaking client information to the Internet due to simple misconfiguration issues client-side.
ISP filters will also prevent users from just setting an arbitrary IP - if not for any other reason, then just because ISPs sell connections with static IP addresses at significantly higher prices and having users set their own IPs would spoil that. Not to mention the mess that would result if there could be IP conflicts among the clients of an ISP...
So in general you cannot just spoof the source of a TCP connection. You have to use an intermediate computer to relay the connection.
Keep in mind, however, that motivated and experienced attackers may have at their disposal botnets that consist of millions of compromised computers belonging to innocent users. Each and every one of those computers could theoretically be used as a connection relay, thus allowing a potential attacker quite a wide variety of IP addresses to chose from.
The bottom line is that simple IP-based checks and filters cannot in any form ensure the legitimacy of a connection. You should be using additional methods to protect your service:
HTTPS and proper user accounts.
Extensive logging and monitoring of your service.
Intrusion detection systems and automatic attack responders (be careful with those - make sure you don't lock yourself out!).
We cannot really provide a more concrete answer unless you tell us what service you are providing, what restrictions you want to apply and what kind of attacks you are so worried about...
Sort of - as you mentioned, proxies are a risk, however it makes life a wee bit harder for the attacker so it is still worth using IP bans.
Monitor your logs, automate alerts and if attacks come from another IP - ban it too. If you make life hard enough for an attacker they may give up.
Let's say I want to make an application where stored data is encrypted so only my application is able to read it.
But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.
The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.
Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.
Cheers.
More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.
But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.
Interesting problem.
Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".
However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.
If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.
The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.
As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.
Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.
With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.
You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.
As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.
Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.
Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.
Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:
-----------------------------------
/ IPSec tunnel \
+---------+ \
A | IPSec | B Untrusted \
trusted network -------| capable |------- Networks ----------- Your application
| router | Internet, etc.
+---------+
The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.
If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.
You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.
I'm developing an application that accepts connections from clients over the internet. All these clients are on fixed IP addresses and will establish a non-encrypted TCP connection.
The current plan is for the server to check which IP the connections come from and allow only client connections from a list of know IPs?
How safe is that against IP spoofing?
My reasoning is that since this is a TCP connection, an attacker couldn't just fake its sender IP (which is easy), but would have to assure that the packets travel back to him and thus he would have to hack all routers on the path, which seems rather hard.
I know I could use encryption, like SSH, but lets stick with the question of how safe the plain TCP connection would be.
Restricting connections by IP address is generally a good practice when practical, as it greatly reduces the attack surface and makes the complexity of an attack much higher. As stated in other answers, you would now have to do something like IP spoofing, or attacking the network itself (false BGP routes, etc).
That said, IP address restriction should be used as one layer of a defense-in-depth approach. Could you encrypt the TCP stream without too much rework? Maybe SSL? If you can't modify the program, how about the network? Site ti site IPSEC VPN tunnels are not difficult to establish, as almost any commercial firewall supports them. Even some soho routers can be modified to support IPSEC (with OpenWrt plus OpenSwan, for example).
Lastly, could you require the client and server to mutually authenticate?
Not safe. BGP gateways are not immune to attack, and with that, false routes can be advertised and IPs can be spoofed.
First of all, using the IP you are not identifying the client, but just some numbers. Even if the IP is right, there still can be a troyan on user's computer, authenticating in place of the user itself (as I don't know what kind of service you provide, I assume that this might make sense).
Now, if one has access to one of the routers via which the packets between the client and the server go, then he can do almost anything - he can send and receive packets in the name of the client or he can modify them (as the data goes unencrypted). Moreover, the attacker doesn't need to hack all or one of routers - he just needs to have access (including legitimate one) to the channel where the data goes, be it the router itself or the cable (which can be cut and the router can be inserted).
So to summarize, IP can be used as one of the component that hardens spoofing to some extent, but it can't be the main security measure.
I'm planning to deploy an internal app that has sensitive data. I suggested that we put it on a machine that isn't exposed to the general internet, just our internal network. The I.T. department rejected this suggestion, saying it's not worth it to set aside a whole machine for one application. (The app has its own domain in case that's relevant, but I was told they can't block requests based on the URL.)
Inside the app I programmed it to only respect requests if they come from an internal I.P. address, otherwise it just shows a page saying "you can't look at this." Our internal addresses all have a distinct pattern, so I'm checking the request I.P. against a regex.
But I'm nervous about this strategy. It feels kind of janky to me. Is this reasonably secure?
IP filtering is better than nothing, but it's got two problems:
IP addresses can be spoofed.
If an internal machine is compromised (that includes a client workstation, e.g. via installation of a Trojan), then the attacker can use that as a jump host or proxy to attack your system.
If this is really sensitive data, it doesn't necessarily need a dedicated machine (though that is best practice), but you should at least authenticate your users somehow, and don't run less sensitive (and more easily attacked) apps on the same machine.
And if it is truly sensitive, get a security professional in to review what you're doing.
edit: incidentally, if you can, ditch the regex and use something like tcpwrappers or the firewalling features within the OS if it has any. Or, if you can have a different IP address for your app, use the firewall to block external access. (And if you have no firewall then you may as well give up and email your data to the attackers :-)
I would rather go with SSL and some certificates, or a simple username / password protection instead of IP filtering.
It depends exactly HOW secure you really need it to be.
I am assuming your server is externally hosted and not connected via a VPN. Therefore, you are checking that the requesting addresses for your HTTPS (you are using HTTPS, aren't you??) site are within your own organisation's networks.
Using a regex to match IP addresses sounds iffy, can't you just use a network/netmask like everyone else?
How secure does it really need to be? IP address spoofing is not easy, spoofed packets cannot be used to establish a HTTPS connection, unless they also manipulate upstream routers to enable the return packets to be redirected to the attacker.
If you need it to be really secure, just get your IT department to install a VPN and route over private IP address space. Set up your IP address restrictions for those private addresses. IP address restrictions where the routing is via a host-based VPN are still secure even if someone compromises an upstream default gateway.
If your application is checking the IP Address, then it is extremely vulnerable. At that point you don't have any protection at the router which is where IP filtering really needs to be. Your application is probably checking HTTP header information for the sending IP address and this is extremely easy to spoof. If you lock the IP address down at the router, that is a different story and will buy you some real security about who can access the site from where.
If are you are doing is accessing the application internally, then SSL won't buy you much unless you are trying to secure the information from parties internal to the organization, or you require client certificates. This is assuming you won't ever access the site from an external connection (VPNs don't count, because you are tunneling into the internal network and are technically part of it at that point). It won't hurt either and isn't that hard to setup, just don't think that it is going to be the solution to all your problems.
IP Whitelisting is, as others have mentioned, vulnerable to IP spoofing and Man-in-the-Middle attacks. On an MITM, consider that some switch or router has been compromised and will see the "replies". It can either monitor or even alter them.
Consider also vulnerabilities with SSL encryption. Depending on the effort, this can be foiled in a MITM as well, as well as the well-known gaffs with the reuse of the primes, etc.
Depending on the sensitivity of your data, I would not settle for SSL, but would go with StrongSWAN or OpenVPN for more security. If handled properly, these will be a lot less vulnerable to a MITM.
Reliance on whitelisting alone (even with SSL) I would consider "low grade", but may be sufficient for your needs. Just be keenly aware of the implications and do not fall into the trap of a "false sense of security".
If it's limited by IP address, then although they can spoof the IP address, they won't be able to get the reply. Of course, if it's exposed to the internet, it can still get hit by attacks other than against the app.
Just because all your internal IPs match a given regex, that doesn't mean that all IPs that match a given regex are internal. So, your regex is a point of possible security failure.
I don't know what technology you used to build your site, but if it's Windows/ASP.net, you can check the permissions of the requesting machine based on its Windows credentials when the request is made.
Like all security, it's useless on it's own. If you do have to put it on a public-facing webserver, use IP whitelisting, with basic username/password auth, with SSL, with a decent monitoring setup, with an up-to-date server application.
That said, what is the point in having the server be publicly accessible, then restrict it to only internal IP addresses? It seems like it's basically reinventing what NAT gives you for free, and with an internal-only server, plus you have to worry about web-server exploits and the likes.
You don't seem to gain anything by having it externally accessible, and there are many benefits to having having it be internal-only..
My first thought on the ressource issue would be to ask if it wouldn't be possible to work some magic with a virtual machine?
Other than that - if the IP addresses you check up against are either IPs you KNOW belongs to computers that are supposed to access the application or in the local IP range, then I cannot see how it could not be secure enough (I am actually using a similiar approach atm on a project, although it is not incredibly important that the site is kept "hidden").
A proper firewall can protect against IP spoofing, and it's not as easy as say spoofing your caller ID, so the argument /not/ to use IP filtering because of the spoofing danger is a bit antiquated. Security is best applied in layers, so you're not relying on only one mechanism. That's why we have WAF systems, username+password, layer 3 firewalls, layer 7 firewalls, encryption, MFA, SIEM and a host of other security measures, each which adds protection (with increasing cost).
If this is a web application you're talking about (which was not clear from your question), the solution is fairly simple without the cost of advanced security systems. Whether using IIS, Apache, etc. you have the ability to restrict connections to your app to a specific target URL as well as source IP address - no changes to your app necessary - on a per-application basis. Preventing IP-based web browsing of your app, coupled with IP source restrictions, should give you significant protection against casual browsing/attacks. If this is not a web app, you'll have to be more specific so people know whether OS-based security (as has been proposed by others) is your only option or not.
Your security is only as strong as your weakest link. In the grand scheme of things, spoofing an IP is child's play. Use SSL and require client certs.
It became useful first to distinguish among different kinds of IP vpn based on the administrative relationships, not the technology, interconnecting the nodes. Once the relationships were defined, different technologies could be used, depending on requirements such as security and quality of service.
Maybe this will help ? I've been looking for the same answer, and found this stackoverflow as well as this idea from Red Hat Linux Ent. I'll try it soon. I hope it helps.
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
Where 0/24 is the LAN range you want to protect. The idea is to block "internet" facing (Forward) devices from being able to spoof the local IP network.
Ref: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html