Mitigating man in the middle attack over public wifi - Pinapple

What are some steps to take when developing a web app or even mobile app that requires connection to the internet.  If somebody is on public wifi, the pineapple seems to make easy pray of unsuspecting users.

Any suggestions to help users log in and know they are not being watched like this?
LVL 56
Scott Fell, EE MVEDeveloper & EE ModeratorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Anyone doing sensitive transactions over a public wifi is a fool no matter what they think is protecting them.  For every security measure there is a hacker counter-measure.  people get their identity stolen and lose their money because the are ignorant of the risk; too stupid to care about risk; or both.

As for the actual question:
Any suggestions to help users log in and know they are not being watched like this?

Antone suggesting they have such an answer is delusional.  You can mitigate, but you cannot prevent.
You can only use the organ betwee your ears to do what is sensible and keep sensitive transaction to secure locations,; not the coffee shop or library.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
I understand the organ between the brains but sometimes even carful people can be fooled.  And there are also times when even though a user knows the dangers, will use public wifi.

If I have a private log in site and can't control if a user is in the office, at home, the coffee shop airport or using cell service, is there a way to alert the user that there is a possible mitm attack?

What do you think of detecting the certificate info via curl as example and matching that to a table in the database or text file?  I control the server so I would know what the certificate info should be.  If the requested info does not match, then throw a warning and perhaps log them out? It sounds too simple.  

I know some banks are using the security image, but that is just for show and from what i read is not actually affective.
Ultimately, public wifi doesn't introduce any NEW vulnerabilities, it only makes the existing ones more likely. Public/private key (PKI) was designed particularly for this purpose - to exchange data securely over insecure connections.

If you use an HTTPS connection to a web site, then the data is encrypted with a public key before it ever leaves the computer. So if someone is sniffing the connection with promiscuous WiFi, then it's useless data to them unless they have the private key.

The client certificate is definitely a step up in security, because the private key is going to always reside on the end user's computer and the contents will never be (or SHOULD never be) transmitted. So the private key should be able to create a digital signature that cannot be reproduced by a MITM. There IS a catch, though:

If the destination server isn't using SSL to encrypt the initial connection, then the authentication digital signature from the private key will be visible to MITM, so they could essentially copy and re-send the same data to the server (replay attack).

To limit replay attacks, you usually want a system that will generate a single, random token on the server side and give that to the end user along with the contents of the login page. The end user can then respond with authentication plus that token. The server authenticates the user and invalidates the token. So if a replay attack is attempted (someone blindly sends what they THINK was an authentication set of data packets), they would be sending over a token that is already used up.

The same principle applies with connections AFTER you're logged in. Once you're logged in, usually you stay logged in via a session cookie. If that session cookie ID never changes, then a successful replay attack (even a blind one) could allow the MITM to instantly be logged in. So it's a good idea to rotate session cookie IDs as well.

Any way you go, HTTPS on the server is the first critical component.

However, you can have MITM attacks where the malicious user acts as the gateway/proxy. This ranges from the easy-to-do attack (e.g. offering a "free" WiFi connection at an airport, where the victim connects because they're just happy to have found a free Internet connection, and all of their data is streamed through the attacker's gateway), to a more complex attack (e.g. ARP attacks to make the victim's computer change its gateway). Either way, the malicious user gets all data to come through his/her gateway. That gateway can then intercept the packets and pretend to be the destination server. On firewalls, this is called Stateful Packet Inspection (SPI) and is a legitimate feature, but the same concept can be used for malicious purposes.

In order for a malicious SPI attack to work, the gateway has to pretend to be the destination server. If the destination server is secured by HTTPS, then the gateway will generate a new certificate on the fly so it can respond to the victim's computer and say, "Yes, I'm" or whatever. The caveat is that the gateway is not going to have the ability to generate a TRUSTED certificate by default, because the victim's computer doesn't have the malicious server's root CA installed (unless they do it via social engineering somehow - e.g. get someone to download and run an .exe file to "gain access" to the WiFi).

So if the victim doesn't have that root CA, then they are not going to recognize the malicious party's "" SSL certificate as valid, and the browser is going to complain and warn them that it doesn't trust the certificate. So part of ensuring that YOUR setup is configured properly is to ensure that you are using a valid certificate from a trusted CA like Verisign or Thawte or whatever, so that people will be able to tell if something is wrong when they get a browser certificate warning from a MITM attack.

This is pretty much all you can do, though. At some point, a user's stupidity is going to overturn anything you do. If a user is dumb enough to connect to a strange, free WiFi connection, then download and run an .EXE file, then they are going to be hosed. Or if they choose to ignore a browser warning (sadly, more people do this than not), then they run those same risks.

Also, in regards to the security image, it is not just for show. If a malicious user is pretending to be your bank and offering a login page, then they are not going to know what your security image is. So if you go to this login page and you see a different image, then it may just be a malicious user showing a random image and hoping you don't pay attention to the fact that it's different from your own before you type in your credentials.
Choose an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
What do you think of yubikey?  or is it best to let our own server generate the passcode?
Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
THANK YOU for all of this!
I use Yubikey for work every day. It's a really nice little thing, but it's a client-side authentication mechanism. That means every user needs their own little Yubikey device, which can be relatively expensive. You have to get a Yubikey device for each user, then get it TO them (so bear in mind logistics/shipping to remote users), and then set up each user on the server side so the Yubikey tokens can be authenticated properly. Then there's ongoing support on top of that (handling login problems, lost keys, etc). It's the same story with any hardware-based token. So while it's a nice little setup, you should keep that in consideration.

Ultimately, you can still achieve a similar result with just the software-based token exchange.
Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
What type of software system would be equivalent.   This is for a web app that will be used by about 10 users for now and perhaps as many as 20.
madunix (Fadi SODAH)Chief Information Security Officer Commented:
Better to use SSL/TLSconnection
Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
Yes, 100% ssl and enforced via code
madunix (Fadi SODAH)Chief Information Security Officer Commented:
End to End channel encryption .. encoded mode per OWASP secure SDLC model
I was not talking about a specific software system - just the general principle. It is fairly simple to create the random token system. You simply need a piece of code that creates the token (which can really be anything unique - com_create_guid(), or maybe a microtime(true) with some random characters), a database to store the token in, and a line of code in the login system that can check for the token in the database and delete it once it's used.

I'll be honest - it's definitely a good thing to be paranoid about security, but if you're concerned about going all-out on security, it prompts another question - is this web app dealing with data that should be PCI compliant, or compliant with any government-level policies (FIPS, etc)? If so, then you should just make sure that you're not attempting to substitute PCI compliance processes with stronger web app security.
Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
Another part of this accepts payments and I have a pci scan implemented.  It was pci that was my final straw to never host email again.  Now I make everybody use google apps for work or whatever 3rd party email system they want.  I was tired of paying high prices to upgrade only for pci and to never be ahead of the spam game.    

It is an ERP that runs the majority of the business functions.  My main worry is somebody working off site on wifi.
I thought you were talking about a much larger user base.  If it is only 10-20 users and you have a measure of control, then the yubikey would do the job nicely and the logistics should not be much of a problem.

Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
Another step to this later on will be a customer log in portal that will be for thousands of users for things like making payments, viewing account etc.  Now the public area is a simple payment page.   The main site users are from within the company and that is the 10 to 20.
Any site doing financial transactions over the internet is always at risk, mobile just adds additional risk. Many of my legacy clients are financial institutions.  When I started out with them we were doing networks on secure lease-lines.  Whe we had to open up and add ATMs, the risk increased, but we were still on a closed secure network.

Then the internet forced a further broadening and the risk went up substantially, because we now had to go through routing facilities that we did not control.  The risk has increased every year as the criminals find new vectors to attack. The counter to the hacking has also increased every year along with the associated cost. Mobile and wifi just add additional layers to the problem.  

There is no fool proof solution. In the last 20 years every major bank, insurance company, stock exchange and government agency in the world has been hacked; sometime with financial loss and sometimes not.  So they pay to be as safe as possible and treat the losses as a cost of doing business.  Part of the cost is custom security.  Anything off the shelf just puts the user in a herd to be targeted.  I one member of the herd gets hacked because of a new exploit, the rest of the herd will be looking at similar attacks within hours; sometimes even before the original victim is even aware that they were hacked.

Only a small fraction of hacks resulting financial loss are publicly reported, because it is bad for business if the public thinks you are vulnerable; so most institutions  eat the lose and compensate their customers for any lose without any public reporting.

I mostly agree with that ^^. However, I'd say that off the shelf doesn't always result in vulnerability. I'd say that the vast majority of successful intrusions are results of poor security maintenance. Companies don't understand the benefit of paying for regular security audits and paying the salary of people who maintain and patch the infrastructure.

So as vulnerabilities and exploits are discovered in software and publically documented as a CVE, a business might just go on using unpatched software, and it's simply a matter of time before some script kiddie comes along and hits the server with the right tool and discovers a way in. Or a business might hire a cheaper developer that doesn't have expertise in secure programming and he/she builds something custom that is easily exploited.

That said, it can be good to be part of a big herd of people and organizations using certain software. Large usage typically motivates the software owners to release patches and security updates faster. OpenSSL is a good example - it has a huge community that led to a quick discovery and patching of Heartbleed.

So, to me, I like using off-the-shelf when its appropriate. I think it lends itself to more hardened security, as long as you have someone who is paying attention to CVEs and is proactively maintaining the company's security and enforcing defense in depth principles.
>>>Companies don't understand the benefit of paying for regular security audits and paying the salary of people who maintain and patch the infrastructure.

Some don't. Most large organizations have very much changed their approach to security ever the last decade. I used to get all kinds of pushback on the pricing of hardening and doing multi-layered partitioning, but to day I can quote outrageous prices and they don't bat an eye because they understand the cost of a security failure.

I understand what Gonzo is saying and quick patching is a benefit, but getting the barn door fixed after the horses have run off, is not always the best.  The preferred solution is a security admin who knows what they are doing and does not compromise security even if it pisses off the CEO.  For security you want Robocop, not Barney Fife.  Almost every breach is through a hole that the security admin should have found before the hacker; and the best defense is continuous testing if your own site security.

Agree with that. IT security personnel are a must, and they need to be okay with being at constant war with the rest of the company. Everyone else wants to get to the end as quickly as possible, which usually means that the security personnel need to be fighting the flow and constantly evaluating.

Anyway, I think that's pretty much the gist of it. I'm moving onto another question. :)
The way I have always evaluated a security admin is that if at least one manager a month does not threaten to have them fired; then they are no doing the job.  To do the job right you have to refuse to compromise; and that is the only best defense against any security threat.

In the context of this question the real answer is that you have to consideryourself in a bunker in the middle of a war zone and the only way to survive is to be surrounded by mean people with big guns guarding the doors.  You still might take some hits but the big mean people will absorb most of it and you will survive.

Scott Fell, EE MVEDeveloper & EE ModeratorAuthor Commented:
Thank you.  There is a lot of good information here.  My main concern was somebody trying to capture data on something like the pineapple.  What I am taking away is as long as it is https, the data they would capture is garbage unless they had the private key.
Basically, yes. Once someone figures out how to quickly reverse the RSA algorithm (the trapdoor math that allows for PKI), then we're all in deep trouble. :)
>>>then we're all in deep trouble

There are modern day Turings working on it in darknet chat rooms and forums.  It is probably just a matter of time.  Any reversible encryption can eventually be rendered worthless.  However there are also groups working on a replacement when needed.  We just have to hope there is a viable replacement before the darknet barbarians find an attack formula.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Wireless Networking

From novice to tech pro — start learning today.