30

I was looking at the domain information of a website (poaulpos.net) on who.is that Chrome connects to whenever I visit a specific an old Tech Times article about Thunderstrike 2, a Mac firmware attack ("Thunderstrike 2 Is The Latest Nightmare Of Mac Owners"). I have Little Snitch, an application based firewall, so I blocked it the first time Chrome attempted to connect to it.

My question is very basic: clicking on the diagnostics tab of any who.is entry automatically runs a ping and a traceroute on the website. Is that more or less like visiting the website by typing the hostname into your browser and letting it load?

The website in question was only registered yesterday and contact information is Whoisguard protected. I'm pretty paranoid. I'm suspicious of the website and am worried if somehow, I could've just allowed something malicious onto my laptop by attempting to reach the website via the who.is diagnostics tab.

  • 61
    If you could get infected by just checking a website through who.is, society would be in great trouble. – MadWard Jul 7 '16 at 12:20
  • 5
    As a bonus, pinging a website won't even get logged anywhere. Many server farms have a firewall block on ICMP ports – usr-local-ΕΨΗΕΛΩΝ Jul 7 '16 at 15:10
  • 6
    @usr-local-ΕΨΗΕΛΩΝ but... ICMP doesn't have the concept of ports. – Dmiters Jul 7 '16 at 16:41
  • 25
    and there's no such thing as "pinging a website" – Lightness Races in Orbit Jul 7 '16 at 16:42
  • 5
    It would be clearer to add the context to the question title, like asking "Does pinging a website carry any of the security risk of visiting a website in the browser?" There are many ways to interpret the title (like availaiblity checking, firewall penetration, etc.). – Cody P Jul 8 '16 at 18:23
100

They are not the same at all.

A ping request is an ICMP packet which just by default sends null data to check if the host is up (You can change around the parameters being sent (read more here).)

When you visit a website in the browser you are using the HTTP protocol which requests data and so you have a CLIENT/SERVER setup here (data is served to the client from server upon a request that is sent in the HTTP protocol).

Either way, if you are not the one sending the request but rather the service (poaulpos.net) you are using sends it, there is no traceback to you and therefore no security risk for you.

  • 6
    ...to check if host is up... But it doesn't tell you if host is down. – user2338816 Jul 8 '16 at 6:20
  • 3
    @user2338816 Actually it does, by context. When you want to check if the server is down you're probably looking forward to use some service that will do more than just receive a null request and return an empty response. When you ping a server that can't even do that, the server is certainly not reachable for anything. – ViniciusPires Jul 8 '16 at 14:58
  • 18
    @ViniciusPires Not true. It's perfectly possible - and indeed relatively common - to have hosts set up to respond to some services, but not ICMP. – reirab Jul 8 '16 at 15:09
  • 4
    @reirab And that's why ping is not the ONLY tool used to see if a server is down :) – ViniciusPires Jul 8 '16 at 16:07
  • 2
    @ViniciusPires Agreed. I was just disagreeing with your assertion that a server is certainly not reachable for anything if it doesn't respond to ICMP echo requests. That's probably true if you set the server up yourself and you know it's set up to respond to ICMP echo requests, but not for the case of pinging someone else's webserver, as in this question. – reirab Jul 8 '16 at 16:10
26

Is that more or less like visiting the website by typing the hostname into your browser and letting it load?

Short answer, no ... it's not even close.

When you run whois you are doing a lookup of an IP or Domain's publicly registered information. In many cases the whois request will not even communicate with the target server. Rather whois databases are mainly run by registrars and registries. ICANN’s IANA department runs the central registry for all kinds of Internet resources, pointing to the whois server of the responsible (sub)-registry as well as the contact details of this registry.

The program you are running is also running a ping against the server. In most cases the standard ping command makes use of ICMP or The Internet Control Message Protocol. This however is not always the case for programs that are checking the status of a server. The tool you are using might instead be doing a port scan to check the availability of ports 80 and 443. NMAP is an example of another tool that has this functionality.

Now, to the heart of your question ... how are all of the things listed above different from visiting the website itself? The answer is that all of the tools above are pretty simplistic, they send a message and get a message but do very little processing. They are all more or less dumb challenge/response type systems in comparison to opening up a TLS socket for communication via HTTPS.

When you open your browser and navigate to https://google.com, the following things happen:

  • Your browser does a DNS lookup of google.com in an attempt to get an IP address to which it should connect.
  • Once an IP address has been obtained, a TLS socket will be negotiated: TLS Negotiation
  • After a secure socket connection has been established, the browser makes a HTTP:GET request for google.com's / (usually a file called index.html but can also be index.php, index.asp, etc depending on the server).
  • Once the HTML content of / is received by the browser, it attempts to load its content for you to see ... however while the HTML can have images (base64 uri encoded) and scripts in its content ... it usually contains references to other files that need to be downloaded as well. In many cases loading a page can result in a great number of secondary requests ... for example loading google.com caused 12 different HTTP requests.
  • Once the page is loaded, any JavaScript is then interpreted and client side code is executed within your browser ... this JavaScript code or flash / java-applet code is usually the root cause of the malicious activities you are afraid of.

It is possible to load a page without JavaScript by using something like NoScript however, this could also prevent the web page from functioning ... for example you wouldn't be able to log into stackexchange without letting some of the JavaScript content be executed.

So to answer the heart of your question, no ... it is very unlikely if not totally impossible to infect your computer by running a whois or ping against evil-website-of-doom.com ... however, if you ping it ... they will get your IP address which may or may not be an issue ... but that is a different question completely.

  • Well, you can read Stack Exchange happily enough without allowing JavaScript. But unfortunately, it does refuse to let you log in without JS and/or cookies (I forget which I had to allow...) – Toby Speight Jul 7 '16 at 14:52
  • 1
    @TobySpeight JS or Cookie, but you need JS to authenticate and get the cookie. Six in one Half a Dozen in the other – CaffeineAddiction Jul 7 '16 at 14:58
  • 1
    You forgot index.aspx, index.cgi, index.htm, default.htm, default.html, etc etc :D – Lightness Races in Orbit Jul 7 '16 at 16:41
  • 1
    @LightnessRacesinOrbit Added etc – CaffeineAddiction Jul 7 '16 at 16:44
12

Pinging a website and viewing it in a browser are two absolutely different processes which involve different protocols altogether. Ping sends an ICMP request (response won't be malicious) while viewing a webpage sends a request to get the index page (possibly malicious) of the website.

In your case, you have nothing to worry about. Firstly, it was a request to the machine that hosts the website and not the website itself. Secondly, the connection was made by who.is to the website and not from your laptop to the website. The website had no way of knowing your IP address.

  • 4
    "response won't be malicious" any chance there's a web server that responds to pings with port scans instead of the protocol-defined ping response? – John Dvorak Jul 8 '16 at 3:49
  • 2
    @JanDvorak I could be wrong, but I think ping is operating way below the application layer; the web server (software) won't respond maliciously. Pinging does give away to the target that you exist, though, yes. The ping response itself shouldn't be able to be malicious, but whoever/whatever saw the ping could begin to do something afterward. – Dave Cousineau Jul 9 '16 at 0:10
11

You can't ping a web site. You can ping a network interface; this sends ICMP ECHO request packets to that interface (and summarizes the replies received).

A web site (in this context) is a server answering HTTP and/or HTTPS requests on one or more TCP ports on the interface (normally port 80 for HTTP and port 443 for HTTPS).

A given interface may or may not reply to ICMP ECHO packets (but it ought to). The same interface may or may not have one or more web sites bound to its TCP ports. But the two are totally independent of each other.

To answer the security question: ping cannot carry a malicious payload; the server is required to return exactly the payload you send, but even if it doesn't, you never interpret it in any way. Your ping program may check that the received data match what was sent, but must not do anything else with the content (and in most cases, you'll be sending an empty payload anyway).

You are giving away a small amount of information (the fact that one interface is interested in the reachability/status of another) but very little beyond that.

  • 3
    I feel "ought to" should be "ought not, in most situations". Ping is useful for troubleshooting a connection to a service. If an interface is not providing any externally accessible services, there's no reason to have ping. Even if there is a service, permitting ping increases your attack profile: see security.stackexchange.com/questions/4440/security-risk-of-ping – Dewi Morgan Jul 7 '16 at 19:07
  • 2
    @Dew - opinions differ, as evident in the question you linked. I don't quite agree with you (ping can be useful against interfaces that are only ever initiators), but in the end, it's a judgement to make based on information - and the more the better, so thanks! – Toby Speight Jul 8 '16 at 8:13
  • "ping cannot carry a malicious payload" - but: Ping of Death. (Though I guess there is no such thing as a ping-reply of death ...9 – Hagen von Eitzen Jul 9 '16 at 16:12
  • @Hagen - good point, but ping-of-death normally means malformed packets - not, strictly speaking, the payload. If you have a system vulnerable to such attacks, you really don't want to put it on the public Internet... – Toby Speight Jul 11 '16 at 10:21
  • If we're going to nitpick about website vs interface terminology... :-) "You can ping a network interface" An ICMP packet does not address an interface, it addresses an IP address. I don't know which specific interface I reach when I ping 8.8.8.8 because of the anycast routing. Where you end up depends on routing decisions, not which interface you specified, because you can't specify an interface (at most, you can specify an outgoing interface with IPv6's ::1%lo notation). – Luc Aug 13 at 10:01
4

No. I would say running ping or traceroute on a domain is not a security risk. Furthermore, the ping is done by who.is and not by your computer.

-2

Ping is nothing like loading the website, as has been said its a completley separate protocol, that might even be blocked. I'd use something that does a dummy HTTP request or the good old Telnet:80

these will give you more information about the web server than a ping.

  • this doesn't really answer the question – schroeder Jul 11 '16 at 15:59

protected by Community Aug 13 at 11:28

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.