Computing desk
< July 11	<< Jun \| July \| Aug >>	July 13 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

July 12

hacking the web

Hi, I've heard that it's easy enough to set up a realistic looking, but fake website, eg. for phishing scams (like www.accounts.bank as a fake version of www.bank.accounts). But if everyone else had the correct web address already, could the scam work then? That is, if everyone already knew it had to be the second version, www.bank.accounts, could you still trick people? What would it take to accomplish some such feat? It would seem to involve getting into the web server, or someone's computer, and directly posting your fake information there.

My interest is in whether someone could fake a university degree register, such as http://webapps2.murdoch.edu.au/gradregister/, eg. to pretend you had a PhD in molecular biology, even when the correct address was known by the receiver. I'm curious because I often need to verify my academic degree, eg. for work in China, and I'm wondering if this is technically a secure option (although not legit for China at the moment). IBE (talk) 21:50, 12 July 2017 (UTC)[reply]

The problem is that the person who creates the fake web site also provides it's address in an email, etc., and people find it easier to just click on the link than to go look up the address on their own. I imagine some app could run in the background to detect when fake web sites are given, and warn the recipient. Something like: "Warning: This web site is NOT associated with the official Murdoch.edu website, and this may well be a phishing scam.". StuRat (talk) 22:02, 12 July 2017 (UTC)[reply]

Yes, but what if that could be avoided? I mean, suppose simply for the sake of argument they did not click on an incorrect address (eg. they have bookmarked the correct address). Can the correct address still be hacked? IBE (talk) 00:59, 13 July 2017 (UTC)[reply]

Yes, but that's no longer phishing. There's a table that maps URLs to actual I/P addresses, and that table could be hacked to redirect everyone to a fake site. See Domain Name System. StuRat (talk) 04:35, 13 July 2017 (UTC)[reply]

Further, those requests go through the local internet connection. That can alter the name resolution. For example, if you are your local coffee shop, using their free internet access, you are at their mercy when you type "somewebsite.com". They could easily direct you to a fake server. It isn't just them either. Because the network is open to all local users, I could monitor network traffic, see the requests going out, and push my own responses back on the network. If my computer is fast enough, you will get the IP address I want you to have instead of the one you expect. Yes, the proper response will show up right after my response, but computers are not programmed to wait to see if a second response shows up. So, it will be ignored and you won't get any warning of any kind. 209.149.113.5 (talk) 14:05, 13 July 2017 (UTC)[reply]

That is why you should use HTTPS for all critical web accesses. HTTPS will check the certificate of the site you connect to, and in particular check if the certificate has been issued for the address in question. Certificates are handed out by certification authorities who are (hopefully) reliable. --Stephan Schulz (talk) 14:22, 13 July 2017 (UTC)[reply]

Correct, but untrusted DNS is still a problem. Scenario: You go to https://mybank.com. I hijack your DNS and send you to my server. My server supplied you with a page that looks just like mybank.com, but it isn't. My server also sends you an SSL certificate. Your browser looks up the IP address of the authority for the certificate. Again, that points to my server. So, my server does the authority exchange and tells your browser that the certificate is valid, go ahead and sign in. There is a lot of ways that this whole process could fail, but it could also work. If I ran it at a hotel, I would have hundreds of potential people to trick into giving me their credentials. 209.149.113.5 (talk) 14:44, 13 July 2017 (UTC)[reply]

Untrusted DNS is a versatile attack surface, but certificates are not usually (or, IIRC, ever) verified online. Rather, they are signed by another CA and so on, up to a list of root CAs, and their public keys are embedded in the browser and/or the operating system. --Stephan Schulz (talk) 15:11, 13 July 2017 (UTC)[reply]

Correct, but there is a connection made to the authority to validate the certificate (at least the first time it is encountered). To really get into how untrusted DNS can be hell, you need to look at another practice: Fake certificate authorities. It is becoming increasingly common for organizations to run fake certificate authorities so they can perform deep packet inspection of SSL/TLS traffic. The web browser doesn't inherently trust the fake authority, so a warning is shown. The user accepts the authority and, then, the certificate authorized by the authority. The users are trained to ignore warnings that the CA is not accepted by the browser. Now, in a hotel on a business trip with their work computer, they go to their bank account, I slip them a fake certificate authorized by my fake CA and they get some sort of security warning that the CA is not automatically accepted by the browser. They click the exception or install or whatever the browser tells them to do and the fake certificate is now a trusted certificate. There are two roots to this problem. First, DNS cannot be trusted. Second, there should only be a handful of certificate authorities, preinstalled on all web browsers, and companies should have the option of creating fake ones so they can spy on their employees. But, that is just my IT security rant. If I was a business manager, I'd likely have a different point of view. 209.149.113.5 (talk) 15:22, 13 July 2017 (UTC)[reply]

It seems to me if an organisation is going to use use their own CA to issue certificates to enable packet inspection, then they should be installing the CA on the browsers of any computers they manage. Of course this doesn't help for BYOD, but still encouraging employees to ignore warnings even for organisation computers seems a dumb idea when there's a suitable solution. Public pinning can be a problem I guess, still for desktop browsers I'm fairly sure this can always be disabled in some fashion and it would be better to do so than to teach users to ignore security warnings. (Admittedly mobile devices are a little more complicated to manage, still I imagine an organisation buying hundreds can find something suitable although it may not help with apps.) Nil Einne (talk) 14:55, 14 July 2017 (UTC)[reply]

Long time later but I came across this whle looking for something else: Also having to click accept every time you visit a HTTPS site seems a awful annoyance and waste of time, especially with the growth in the number of HTTPS sites. I mean seriously, if the organisation has 100 or more employees who use the internet every so often, it seems to me someone could come up with an analysis showing that this is costing the business probably way more than to fix it, like as suggested by installing the CA on their devices. Actually if the organisation is large enough and uses the internet enough, I would be hardly surprised if they could hire someone full time for a full months with what they're spending on wasted employee time clicking accept. And it seems to me if management is remotely competent they'd do something about it then, even if they aren't willing to based on speculation about the risks of an employee accepting the wrong certificate. Also I forgot to mention, AFAIK if pinning is used, you generally have the same problems with an invalid certificate as you have with a valid one which is isn't the pinned one. Nil Einne (talk) 13:35, 5 January 2018 (UTC)[reply]

So if China controls their own web servers, and I am operating outside China, are they safe in that case? Or could I hack in and still rig the thing? IBE (talk) 14:53, 14 July 2017 (UTC)[reply]