Posts Tagged #Security

Posted on by Arnon Erba in News

This morning, Apple released iOS 12.1.4, an incremental update that fixes several security issues including the Group FaceTime eavesdropping bug from last month. The Group FaceTime service has also been re-enabled for devices running iOS 12.1.4 or higher.

The eavesdropping bug, discovered accidentally in January by a 14-year-old from Arizona, caused certain Group FaceTime calls to automatically connect even if the recipient did not answer the call. This flaw allowed macOS or iOS users to be eavesdropped on by any malicious FaceTime user. The bug was disclosed privately to Apple by the teen and his mother at least a week before it went public, but it appears that Apple did not clearly or immediately respond to the bug reports they filed.

Shortly after the bug went viral on January 28th, Apple took the Group FaceTime service offline as a temporary fix before a patch could be released. On February 1st, with Group FaceTime still offline, Apple announced that the bug had been fixed server-side and that a client-side software update to fully resolve the issue would be available the week of February 4th.

Read More

Posted on by Arnon Erba in Server Logs Explained

In today’s world, the exhaustion of IPv4 addresses and the slow adoption of IPv6 means that publicly routable IPv4 addresses are in high demand. It also means that when you spin up a cloud-based virtual private server using a service like Digital Ocean, Linode, or Amazon Web Services (AWS), you’ll almost certainly get an IPv4 address that was previously in use by someone else. In the worst case, your new IP address might be on some blacklists, but the most likely situation is that you’ll get some extra “background noise” in your server logs.

The Logs - - [06/May/2018:03:10:08 +0000] "GET /0f0qa0a/captive_portal.html HTTP/1.1" 404 152 "-" "Go-http-client/1.1" - - [06/May/2018:03:10:41 +0000] "GET /0f0qa0a/captive_portal.html HTTP/1.1" 404 152 "-" "Go-http-client/1.1"

These Nginx logs were pulled from a fresh virtual private server that I created with a new-to-me IPv4 address. If you’re curious, my original Server Logs Explained post contains a breakdown of the log format I’m using, but I’ll cover what these log excerpts mean in this post as well.

Essentially, two completely different IP addresses performed an HTTP GET request for the same resource, /0f0qa0a/captive_portal.html. Unable to provide this mysterious file, my server responded with 404 Not Found. This pair of log entries became much more interesting when I noticed that my server kept getting the same two requests from the same two remote IP addresses every few seconds.

Some Detective Work

First of all, these log entries are completely harmless. Anyone can request any random page from a web server, and the server should return a 404 response if the page does not exist. At this point, curiosity is the only reason to continue exploring the source of the two requests.

A cursory WHOIS lookup on both IPs reveals that they are owned by OVH Hosting, a French company that provides cloud-based hosting services. It’s similar to the other cloud hosting companies I mentioned at the beginning of this post. It isn’t a big leap to assume that both IPs belong to virtual servers hosted by OVH, so with that assumption in mind, let’s move forward.

Next, a reverse DNS (rDNS) lookup on each IP address yields the following interesting results: maps to maps to

Right away, there’s “ovh” in the hostnames for the two servers, which seems to confirm that OVH Hosting was a good guess. There’s also something else interesting about these results: is a Canadian IP address, and it has “ca” in its hostname. On top of that, is a French IP address, and it has “eu” in its hostname. It’s beginning to look like these two servers are part of some company’s public-facing server infrastructure.

Let’s look at the far left section of the hostnames, prometheus-nodes. There’s no law that dictates how you should name your servers, but it is pretty common to give them logical names that correspond to the software that runs on them. With that in mind, what is “prometheus”?

Prometheus is a real piece of software. Its GitHub page describes it as “a systems and service monitoring system”, which would explain the persistent requests in my server logs. Monitoring solutions work by constantly checking a service, evaluating the responses they receive, and notifying administrators if something looks wrong. It seems reasonable to conclude that some important service was being hosted by the previous owner of my IP address, and someone forgot to reconfigure their monitoring solution after decommissioning the server.

There’s still more we can learn from the reverse hostnames. A simple Google search for one of the hostnames turns up this GitHub issue from February, where a bunch of information is listed that confirms that the server runs Prometheus. On top of that, the user who opened the issue claims to work for a company called “AnchorFree”.

AnchorFree — could that have anything to do with the portion of the hostnames? Even though there’s no public-facing website associated with that domain, Googling for “” turns up this user profile on Docker Hub. Guess what’s listed in the bio for that user? Anchorfree, Inc.

There’s something else, too. A WHOIS lookup on “” reveals that it is registered under the real name of one of the co-founders of AnchorFree. That was easy. Too bad GDPR is killing WHOIS at the end of this month. (Ed: This was accurate when this post was drafted in 2018.)

Now that we know that both servers are owned by AnchorFree, let’s figure out what AnchorFree actually is. Wikipedia and AnchorFree’s actual website both confirm something interesting — AnchorFree is the parent company behind Hotspot Shield, a fairly well-known “freemium” VPN app.

The Conclusion

Nothing in this post is particularly revealing, but it’s interesting to consider what happens when IP addresses owned by cloud service providers get reused. If you incorporate cloud service provider IP addresses into your server infrastructure, it’s important to remember that those addresses may be recycled for other customers in the future. If you set up important services or access control lists based on IP addresses you don’t own, it’s possible to introduce problems that won’t become apparent until later. In cases like this, it might be as simple as having your monitoring solution check the wrong IP address for a few days.

On the other hand, consider what might happen if you decommissioned a server but forgot to remove its forward DNS entry. If a malicious actor gained control of its old IP address, they could set up a phishing website that would appear to be hosted on your domain. Change control and detailed documentation are important when it comes to using public cloud services.

Posted on by Arnon Erba in News

(Editor’s note: This post has been updated since publication.)

As announced in February this year, Google Chrome’s design is being evolved to more clearly indicate to users that websites using plain HTTP are not loaded securely and that HTTPS connections should be expected instead. Today, Chrome is pushing a change that affects all HTTP sites worldwide: starting in version 68, Chrome will display a “Not Secure” warning in the address bar for all sites loaded over HTTP.

This isn’t the first change Chrome has made to clearly indicate that HTTP is not secure. Chrome has been marking HTTP traffic as “Not Secure” in Incognito mode as far back as version 62. The “Not Secure” warning has also been appearing for HTTP sites in Chrome’s normal mode when a page contains a password field or when the user interacts with any input field.

Although Chrome has taken the lead, Mozilla Firefox is also on board with the effort to visually flag HTTP pages as insecure. Firefox currently displays an address bar warning for HTTP sites that contain login forms and displays a visible warning message next to login forms that are served insecurely.

What’s Next

The future will bring more changes for the way Chrome visually handles HTTP and HTTPS connections. As I covered back in May, Chrome is scheduled to remove the “Secure” text from HTTPS connections in September with the release of Chrome 69. One month later, in October 2018, Chrome will color the HTTP “Not Secure” warning red when users enter data into insecure sites in Chrome 70. Ed: A previous version of this post inaccurately reflected the circumstances in which the “Not Secure” warning will be colored red in Chrome 70. The color will only change when users enter data on HTTP pages.

Posted on by Arnon Erba in Server Logs Explained

(Editor’s note: This post has been updated since publication.)

Some log entries are particularly bizarre, like the one we’ll be looking at today: - - [26/Jun/2016:00:35:26 -0700] "\xD5H\xC5p*\xB7:\x8F\x91\x8A\xE1\xAA\xE0p\xD9\xF2[;\xAE\xE7c\xF7\x9C\xAB~\x98\xCB\xAD\xCB\xBE\xCE\xED\xAF\xEC\x8B\x19\xC6\x08D\xEB\xA8\x91\x1De\x10\x18 u\x01zHj\x00\x8D|\x15\x8B;\x98\x08RaSH" 400 166 "-" "-"

My server responded with 400 Bad Request, but the most interesting part is the giant $request portion, which doesn’t include any of the normal components you would expect in an HTTP request:

\xD5H\xC5p*\xB7:\x8F\x91\x8A\xE1\xAA\xE0p\xD9\xF2[;\xAE\xE7c\xF7\x9C\xAB~\x98\xCB\xAD\xCB\xBE\xCE\xED\xAF\xEC\x8B\x19\xC6\x08D\xEB\xA8\x91\x1De\x10\x18 u\x01zHj\x00\x8D|\x15\x8B;\x98\x08RaSH

Note: See my first Server Logs Explained post for an example of how to interpret the entire log entry.

Wait, What?

If your first thought was that this looks like 64 bytes of garbage, then you’d be exactly right. As it turns out, I wasn’t the first person to see one of these bizarre log entries. According to this Information Security StackExchange question and answer, this server request is from an Internet-wide research scan led by the Electrical Engineering and Computer Sciences (EECS) department at the University of California at Berkeley.

A reverse DNS lookup of the IP address led to an illuminating hostname, researchscan1.EECS.Berkeley.EDU. It turns out there’s actually several machines related to the project:

  •, or researchscan0.EECS.Berkeley.EDU
  •, or researchscan1.EECS.Berkeley.EDU
  •, or researchscan2.EECS.Berkeley.EDU
  •, or researchscan3.EECS.Berkeley.EDU
  •, or researchscan4.EECS.Berkeley.EDU

If you access any of those IP addresses or hostnames in a web browser, you’ll see a brief description of the project. However, according to this answer on StackExchange, the text on those webpages has changed over time, so the most concise explanation comes in the form of a quote from the project leaders at Berkeley that’s reproduced in that answer:

We are performing a measurement study of a particular phenomenon on the Internet. To accurately asses the behavior we’re performing a daily scan of the IPv4 space by sending a single benign packet to every IP on port 80 consisting of 64 random bytes of data. […] No, we are not attempting to gain unauthorized access. […] It’s simply randomly generated data that conforms to a certain set of criteria.

I contacted the project team a few months ago as well, but have not heard anything back. Given that the StackExchange answer and my log entry both date back to 2016, it’s possible that the research project is already over and is now just Internet history. Either way, it’s interesting to finally know what it is.

Posted on by Arnon Erba in News

Today, the Google Chrome security team announced the next step in their plan for handling plain HTTP pages in Chrome. Over the past couple years, the Chrome team has been slowly increasing the negative visual feedback users get when they interact with unencrypted HTTP sites, and back in February 2018 the team announced a plan to eventually mark all plain HTTP pages as “Not secure” in the address bar. That visual change is still scheduled to take effect in July 2018, but the team has already announced another big change, this time to the way Chrome visually handles already-secure HTTPS sites.

A Little Less Carrot, and a Little More Stick

Starting in September 2018, Google Chrome will no longer display the word “Secure” in the address bar for sites that support HTTPS. The rationale behind this change is that users should only be warned when a site is not loaded securely. Otherwise, users have to look for the absence of a padlock or the “Secure” text, and an obvious warning about insecure content is generally more noticeable than the lack of a positive visual indicator. As shown in the screenshot below, the padlock icon will still stick around for awhile longer, although it will no longer be colored green.

Later, in October 2018, the forthcoming “Not secure” warning on HTTP pages will turn red when users try to enter data into any form loaded over HTTP. Currently, the “Not secure” warning is only shown on HTTP pages with password forms, and when shown it is colored grey to match the site’s URL.

Still a Controversial Change

Google’s significant push towards universal adoption of HTTPS has not been without controversy. It’s generally accepted (for fairly obvious reasons) that sites handling the submission of sensitive data — like passwords and credit card numbers — should use HTTPS, but advocates of universal HTTPS suggest that even the most insignificant sites can still benefit from encryption.

For one, some sites still only use HTTPS for their login pages and serve the rest of their content over HTTP, which can open users up to very real attacks like session hijacking. Also, since all HTTP traffic is sent over the Internet completely unencrypted, it can be modified in transit, censored, scraped for tracking purposes, or have advertisements injected into it. While rare, ad injection by ISPs is very real, and the fact remains that HTTP traffic can be snooped on by anyone from local Wi-Fi hijackers to national governments.

On the other hand, opponents of universal HTTPS raise several complaints. Some claim that HTTPS is simply not needed for sites that do not handle sensitive data and do not care what happens to their content in transit. Others suggest that deprecating HTTP will kill off old, unmaintained websites from the 90’s and early 2000’s that contain valuable information and will likely never be migrated to HTTPS.

Mainly, opponents claim that Google is exercising an unreasonable amount of monopolistic authority over the future of the Web. Google has already been using HTTPS as a positive ranking signal in its search results since 2014, and as a company it does have a significant amount of influence over the Web.

An Ideological Dispute

At some level, the pro-vs-anti-HTTPS debate boils down to an ideological dispute over who should control the future of the web. Proponents claim that universal HTTPS is genuinely in everyone’s best interest, while opponents rankle at the thought of the Web being influenced by Internet companies rather than being the free-to-enter, open-to-everyone system that they feel it began as. Realistically, Google isn’t the only major company backing universal HTTPS, and with the amount of support behind the movement it’s unlikely to show any signs of slowing down.

Posted on by Arnon Erba in News

Update 11/29/17: Apple has released an urgent security update patching this vulnerability. Please patch immediately through the App Store if you have a Mac with 10.13.1 High Sierra. See this Apple support article for more information about the patch.

A recently disclosed vulnerability, revealed a few hours ago on Twitter, allows anyone with unprivileged login access to gain root privileges on a Mac running MacOS 10.13 High Sierra. The bug does not appear to affect versions of MacOS released before High Sierra (e.g. 10.12 Sierra, 10.11 El Capitan, etc.).


Exploitation of the bug is dangerously simple. Normally, protected system settings in MacOS can only be “unlocked” by clicking on the padlock icon and entering an administrator password, as shown below:

However, if you enter “root” as the username and leave the password field blank, the current build of MacOS High Sierra will eventually unlock the System Preferences window after a few failed login attempts. In testing, it required two to three failed authentication attempts as root to trigger the bug.

Scarily enough, once the exploit has been performed, the root account can be used at the login screen as a normal MacOS account. Simply clicking “Other User” and entering “root” as the username with no password grants a full MacOS session with root privileges that is capable of modifying system settings, removing and installing software, and viewing all files with no restrictions. It also appears that the exploit can be used remotely if remote access is enabled, removing the need for an attacker to be physically present at the affected Mac.

Behind the Scenes

As mentioned on Twitter, it appears that the exploit enables the built-in root user account but does not set a password for it. This enables anyone on the system to use this newly activated account to gain root privileges.


Update (11/29/17)

Apple has released an urgent security update patching this vulnerability. Please patch immediately through the App Store if you have a Mac with 10.13.1 High Sierra. The patch will appear as “Security Update 2017-001”.

Original Response (11/28/17)

Until Apple releases a fix for the bug, the only current solution is to enable the root user yourself and set a password for it. This prevents exploitation of bug since the root user will not be re-enabled once it has already been set up.

To enable the root user and change the password, go to System Preferences > Users & Groups > Login Options and click “Join” next to “Network Account Server”. In the popup that opens, click “Open Directory Utility” and click “Edit” in the menu bar at the top. From the dropdown menu, select “Enable Root User” and then “Change Root Password”. Directory Utility can also be opened directly from Spotlight.

Important: Simply disabling the root user does not fix the bug, since it can be exploited again to re-enable the account with a blank password. Changing the root password is the only mitigation at this point. Ed: see above for the official patch.

Read More