Many website operators have wrestled with the decision to move all their web infrastructure to support HTTPS protocols. The upside is obvious: better protection and a more secure pathway between browser and server. However, it isn’t all that easy to make the switch. In this piece that I wrote for IBM’s Security Intelligence blog, I bring up the case study of The Guardian’s website and what they did to make the transition. It took them more than a year and a lot of careful planning before they could fully support HTTPS.
It used to be so simple to understand how a web browser and a web server communicated. The server held a bunch of pages of HTML and sent them to the browser when a user would type in a URL and navigate to that location. The HTML that was sent back to the browser was pretty much human-readable, which meant anyone with little programming knowledge and a basic knowledge of command syntax could figure out what is going on in the page.
I can say this because I remember learning HTML code in those early days in a few days’ time. While I am not a programmer, I have written code in the distant past.
Those days (both me doing any code or parsing web pages) are so over now. Today’s web servers do a lot more than just transmit a bunch of HTML. They consolidate a great deal of information from a variety of sources: banners from ad networks, images from image headers that are used in visitor analytics, tracking cookies for eCommerce sites (so they can figure out if you have been there before), content distribution network codes and many more situations.
Quite frankly, if you look at all the work that a modern web server has to do, it is a wonder that any web page ends up looking as good as it does. But this note isn’t just about carping on this complexity. Instead, it is because of this complexity that the bad guys have been exploiting it for their own evil ways for many years, using what are called script injection techniques.
Basically what is happening is because of poorly written code on third-party websites or because of clever hacking techniques, you can inject malware into a web page that can do just about anything, including gathering usernames and passwords without the browser’s knowledge.
One type of injection, SQL injection, is usually near the top of the list of most frequent attacks year after year. This is because it is easy to do, it is easy to find targets, and it gets big results fast. It is also easy to fix if you can convince your database and web developers to work together.
But there is another type of injection that is more insidious. Imagine what might happen if an ad network server would be compromised so that it could target a small collection of users and insert a keylogger to capture their IDs and passwords. This could easily become a major data breach.
A variety of security tools have been invented to try to stop these injections from happening, including secure browsers (such as Authentic8.com), using various sandboxing techniques (such as Checkpoint’s Sandblast), running automated code reviews (such as with runtime application self-protection techniques from Vasco and Veracode), or by installing a browser extension that can block specific page content. None of these is really satisfactory or a complete solution.
If you are concerned about these kinds of injections, you might want to experiment with a couple of browser extensions. These are not new. Many of these tools were created years ago to stop pop-up ads from appearing on your screen. They have gotten new attention recently because many ad networks want to get around the ad blockers (so they can continue to make money selling ads). But you can use these tools to augment your browser security too. If you are interested in trying one of them out, here is a good test of a variety of ad blocker performance done several years ago. There is another comparative review by LifeHacker which is also several years old that focuses on privacy features.
I was interested so I have been running two of these extensions lately: Privacy Badger (shown here) and Ghostery. I wanted to see what kind of information they pick up and exactly how many third-parties are part of my web transactions when I do my banking, buy stuff online, and connect to the various websites that I use to run my life. The number will surprise you. Some sites have dozens of third-party sites contributing to their pages.
Privacy Badger is from the Electronic Frontier Foundation, and is focused on the consumer who is concerned about his or her online privacy. When you call it up onscreen, it will show you a list of the third-party sites and has a simple three-position slider bar next to each one: you can block the originating domain entirely, just block its cookies, or allow it access. Ghostery works a bit differently, and ironically (or unfortunately) wants you to register before it provides more detailed information about third party sites. It provides a short description of the ad network or tracking site that it has discovered from reading the page you are currently browsing. The two tools cite different sites in their reports.
There are some small signs of hope on the horizon. An Israeli startup called Source Defense is in beta; they will secure your website from malicious third-party script injections such as keylogger insertions. I saw a short demo of it and it seems promising. Browsers are getting better, with more control over pop-ups and third-party cookies and blocking more obvious malware attacks. Although as browser security controls become more thorough, they also become more difficult to use. It is the nature of the Internet that security will always chase complexity.
reading my article on HPE’s latest website. You’ll learn something essential to maintaining your overall IT security posture. I provide an overall timeline of events since last fall, show how Mirai was first detected, and what things you should do to protect your enterprise infrastructure.You’ve probably seen your fill of Mirai-inspired headlines, but keep
His earliest memory of a security issue was with managing people: “I have found that no matter how comprehensive our policies may be, if you don’t have the right culture among your workforce they won’t matter. Education, understanding, and inclusion are the ways to build the right security environment.”
He is drawn to tools that provide useful analytics. “With TB of data available to your team, trying to find the needle in the haystack can be a challenge. Each tool has its place in your security architecture so picking one is difficult, but those which are capable of providing me good information for analysis are the ones I prefer. That said, knowing your use cases and setting up your tools is probably the biggest impact to any security organization.”
His best advice for dealing with insider threats is to first, start with the basics. “Many companies have not taken adequate measures to protect their information or environments. At the lowest level, access provisioning, data classification, and updated antivirus and firewalls are all mandatory but when new systems or services get introduced into your environment the effects are often not well known. Protect against the drift.”
He sees MDM as a careful balance between protecting the employee and preventing unauthorized access. “At the core of the issue, no one wants their data put at risk and most users and organizations are willing to conform to a good policy in order to protect themselves.”
As President Donald Trump arrives at the White House to start his term, he faces a very different collection of technology than when former President Barack Obama entered eight years ago. Back then, government PCs sported floppy drives and no president ever personally used Twitter or other form of social media. But the task of making the digital transition isn’t easy, and I describe some of the electronic methods that are being used to preserve the Obama legacy. You can read my post on IBM’s SecurityIntelligence.com blog here.
If you are looking to trace the origins of an insecure IoT, you might want to take a walk down memory lane back to October 1991. Back then HP developed the first network printer server called JetDirect. This took the form of an internal circuit card shown here that came in both Token Ring (remember those?) and Ethernet versions that fit inside the early monochrome laser printers. I believe those early printers cost around $2400, so there was some cost motivation to share them around the LAN. HP had been selling the first desktop laser printers for several years and this was the first time that any of them could be easily connected to a network. During the 1990s there were several versions of JetDirect cards created, including external print servers that could connect to any printer that had a parallel port. It wasn’t long before they were commonly used, not just for printing but numerous other hacking activities.
Why is this the origin story of the insecure IoT? Check out this post on SecurityFocus from May 2003. Way before ransomware was common, the post describes a major vulnerability in the JetDirect web-based admin utility. Some network admins knew when they first got these devices that they could be configured via two different protocols: web and telnet. The post shows that the telnet interface didn’t have any default password, and if you had to reset the device, you would return to this default setting. Thus began the insecure IoT. At the time, there was a lot of discussion about printer insecurity, not just about HP but any network-connected printer: check out this SANS white paper from 2003.
When we look at this material with a modern eye, some of the hacks mentioned here seem, well quaint. But some are significant, such as having a hacker hosting malicious webpages and scripts on your printer, as mentioned in this recent article here. One of the attractions for using network printers is that usually no one looks carefully at their operations, either through activity logs or intrusion systems. Another advantage is that they are always on and if they have issues get rebooted quickly so they can continue to serve print jobs.
Now we have millions of network-connected devices of all shapes and sizes, but still have sub-par programming where passwords, secure protocols and other practices are few and far between. Granted, laying all this at the feet of HP isn’t really fair: they didn’t anticipate how networks would be abused decades later. But it shows that hardware vendors often give security short shrift. Since those early days, HP hasn’t been just sitting around either: In 2015 they came out with ultra-secure printers that protect any BIOS tampering and have other controls such as built-in intrusion detection.
It is nice to see that the JetDirect product, which started the insecure IoT, brought about some solid innovation in the modern era with better printer security. It has come full circle, to be sure.
The number of innovative co-working spaces continues to rise around the world, and this doesn’t even include coffee shops, libraries and numerous other public places that offer free Wi-Fi. It’s important to consider the security implications of what these itinerant workers are doing. IT managers are challenged to keep their networks and data secure while encouraging remote workers to be productive, whether they’re dialing in from the local WeWork or reviewing emails at McDonald’s.
I have watched the series of reports about the Russians trying to influence our election last fall with a mixture of disbelief and interest. I wanted to put together links to some of the better reporting, and also call out some of the sub-standard reporting to steer clear from.
Let’s start with what we know and what has been released to the general public. The best quality of information came from this report from Crowdstrike back in June. They were called in by the DNC to try to get to the bottom of the attacks on their network. This post has many details that point out indicators that two separate Russian state intelligence agencies had penetrated their networks over a long period of time. They entered via phished emails and then proceed to infect various PCs with a boatload of malware, most of which was very clever at avoiding detection. When you look at the Crowdstrike report, you can see why this malware was so difficult to pin down: you needed the experience and context of other attacks by these Russian state actors to see the similar patterns of compromise.
I assume that our government has this experience, but getting them to tell civilians in an unclassified report is another matter entirely. Still such a report was done by the FBI and Homeland Security recently, and it can be found here. Sadly, this report comes up lacking in several areas: it doesn’t tie any specific Russian sources to these attacks, it doesn’t help network defenders to prepare their own networks for future similar attacks, and it contains mostly high-level platitudes and security chestnuts that aren’t very unique or actionable.
The feds didn’t do themselves any favors here. I agree with Bruce Schneier’s assessment: “If the government is going to take public action against a cyberattack, it needs to make its evidence public. It’s one thing for the government to know who attacked it. It’s quite another for it to convince the public who attacked it.” He links to previous attacks such as Sony, OPM, and Estonia that took some effort to figure out the originating offenders.
Also not helping matters was when the Washington Post ran a story about the Russians hacking into a Vermont electric utility. They later corrected the piece, leading with the statement they “incorrectly said that Russian hackers had penetrated the U.S. electric grid. Authorities say there is no indication of that so far.” Oops. The issue is that yes, one piece of malware, which can be purchased online from a variety of sources, was found on a laptop belonging to one employee of Burlington Electric. This laptop was a personal machine and not part of any operational function for the utility. The Intercept unpacks the Post story technically bit-by-bit so you can see the sloppy reporting and reactions forthwith.
Various security researchers have come out with similar negative reactions to the DHS/FBI report and the Post piece. Here are links to three of them:
So if you are a corporate IT manager, what needs to happen, going forward? First, you should re-read the Crowdstrike blog post from last June and make sure you – and your security staff — understand the various infection vectors used by the Russians. Next, you should take the time to ensure that your defenses actually will work against these vectors, and if not, what gear you need to put in place to make things more secure. Finally, you should not over-react to the general press stories about hacking attempts, without doing some careful investigation first. As a recent example, stories such as the US Customs computers going offline on Dec. 28th – which were originally attributed to a hacking attempt – turn out to be nothing more than a bad systems upgrade by their IT department.
Microsoft’s latest version of its anti-malware tool, Windows Defender, is a frustrating product to evaluate. Once you examine the product in more detail, you will see why we cannot recommend it for enterprise use. And that is the frustration of this product: Microsoft is trying to do the right thing and offers a tempting feast, but ultimately offers an incomplete meal that is tough to digest. It is hard to track, hard to configure, hard to remove and hard to manage in a typical enterprise environment.
It might be all the antivirus that a home user needs, but when it comes to the business world, you are better off with something else.
You can read the full review in Network World here.