31

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.

Bubble Hacker
  • 3,615
  • 1
  • 11
  • 20
oats58459
  • 531
  • 1
  • 4
  • 5
  • 61
    If you could get infected by just checking a website through who.is, society would be in great trouble. – MadWard Jul 07 '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 07 '16 at 15:10
  • 6
    @usr-local-ΕΨΗΕΛΩΝ but... ICMP doesn't have the concept of ports. – Dmiters Jul 07 '16 at 16:41
  • 25
    and there's no such thing as "pinging a website" – Lightness Races in Orbit Jul 07 '16 at 16:42
  • 3
    @MadWard, remember TXT record XSS? – colonelsanders Jul 07 '16 at 18:11
  • Yes, @DmitryNarkevich you are correct. I said that statement because I had in mind a couple of sentences. One is a firewall's "block ICMP port" and the other is "port 9". I don't remember where that port 9 comes from atm – usr-local-ΕΨΗΕΛΩΝ Jul 08 '16 at 09:39
  • Oh, and the firewall I mentioned above, yeah, was a really cheap firewall.... – usr-local-ΕΨΗΕΛΩΝ Jul 08 '16 at 09:49
  • 2
    But ... you *didn't* ping the server: you asked who.is to ping the server on your behalf. – TRiG Jul 08 '16 at 10:29
  • 2
    Note that *telnetting* to port 80 of a web server is much more similar to viewing it through a browser, since that is just the kind of connection your browser makes. Of course a simple telnet session does not involve rendering or processing of anything like a browser would do, even if you issue several HTTP `GET` requests. – Todd Wilcox Jul 08 '16 at 13:53
  • 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 08 '16 at 18:23
  • One thing that I'd like to add to these (very good) comments: I once worked with someone who that that pinging a web server meant that it was up and operational; it doesn't. Simply because a device responds to a ping **doesn't mean** that it's operational, or serving whatever it's meant to serve. – Tom Raymond Jul 08 '16 at 14:33
  • FYI: Visiting a website uses IPv4/6 (Layer 3) -> TCP (Layer 4) -> HTTP(S) (Layer 7), and IPv4/6 -> UDP (Layer 4) -> DNS (Layer 7). Pinging a website uses ICMP (Layer 3) only. The attack vectors available are larger visiting a website than pinging a server. Fundamentally a ping/traceroute and a website visit in your browser are different all the way down to Layer 3 of the OSI Model. – zamnuts Jul 11 '16 at 00:42
  • It is not security related question ... – boleslaw.smialy Jul 11 '16 at 09:55

6 Answers6

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.

Bubble Hacker
  • 3,615
  • 1
  • 11
  • 20
  • "…no security risk for you unless the service is horribly implemented and the website tailored to its holes." – Bergi Jul 08 '16 at 02:43
  • 6
    `...to check if host is up...` But it **doesn't** tell you if host is down. – user2338816 Jul 08 '16 at 06: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 08 '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 08 '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 08 '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 08 '16 at 16:10
  • @reirab Sorry, I didn't understand your argument at first, you're right. Reading it again, I misused the term "certainly", I meant "probably". My bad. – ViniciusPires Jul 08 '16 at 16:17
  • A server interface might both be up and respond to pings, yet a ping might not get a response. The ping might never reach the server because any intermediate networking device can block ICMP. It's just that only receiving a response tells something about the status of the interface while not receiving a response can have a number of possible interpretations. It just gets tricky without good networking background. I'd only suggest an answer edit to expand the "no response" interpretation. – user2338816 Jul 09 '16 at 00:58
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.

Community
  • 1
CaffeineAddiction
  • 7,517
  • 2
  • 20
  • 40
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.

Limit
  • 3,191
  • 1
  • 16
  • 35
  • 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 08 '16 at 03: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 09 '16 at 00: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.

Toby Speight
  • 1,214
  • 9
  • 17
  • 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 http://security.stackexchange.com/questions/4440/security-risk-of-ping – Dewi Morgan Jul 07 '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 08 '16 at 08: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 09 '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 '19 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.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
-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.

EnviableOne
  • 157
  • 8