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.

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.

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:

• http://www.robertmlee.org/critiques-of-the-dhsfbis-grizzly-steppe-report/
• http://jerrygamblin.com/2016/12/30/grizzly-steppe-ip-and-hash-analysis/
• https://www.wordfence.com/blog/2016/12/russia-malware-ip-hack/

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.

Since I began writing a series of newsletters for Inside Security in June, I have covered some of the most important data leaks or security threats each week. Here are my favorites:

Yahoo for the Big Kahuna award: Billions of emails served, thanks to Yahoo. The gift that keeps on giving, and also taking shareholder value too. My analysis and lots o’ links here.

In a class by itself is the Mirai botnet. Dyn’s analysis of the Krebs’ attack is here. Then more than 900,000 customers of German ISP Deutsche Telekom were knocked offline with new variant. It didn’t help matters that DT allowed the rest of the world to remotely manage these devices.

Schneider Electric gets the two times the charm award. Both Unity Pro and PanelShock utility software programs of theirs were compromised in a matter of days; both were attacks that could harm industrial control networks. This could be the return of Stuxnet. The published advisory is here.

The Australian Red Cross receives the bloodbath award. A million or so medical records of blood donors have, ahem, leaked. Gotta love those Aussies: “This is a seriously egregious cock-up,” said one researcher.

Three Mobile (UK) receives the can you hear me now award. Contact details of six million of its customers has been exposed, which are about two-thirds of their total. Hackers used an employee’s login credentials to gain entry.

The friends with benefits award goes to, naturally, the Friend Finder Network. They exposed more than 412 million accounts, including millions of supposedly deleted accounts, thanks to a local file inclusion flaw. Actually, this is their second such award: they were also breached in 2015.

DailyMotion and Weebly both share the password is ‘password’ award. DailyMotion had more than 80 million of their account IDs and passwords exposed. Only a fifth of these accounts had passwords and they were fortunately encrypted. The company admitted the breach in a blog post. Leaked Source obtained the data file. As for Weebly, they had more than 40 million accounts compromised earlier this year. Fortunately, their stolen passwords were stored using the strong hashing function BCrypt, making it difficult for hackers to initially obtain users’ actual passwords.

Payday awards. Criminals continue to figure out ways to make ATMs spit out their cash drawers. Two this year are notable: Alice (discovered recently by Trend Micro researchers) and Cobalt, where Group IB has named the organization behind the thefts. Both are very sophisticated attacks, and we should expect more in 2017.

The pixel perfect award goes to an attack called Steganos. Millions of people visiting mainstream websites over the past two months have been exposed to a novel form of malicious ads that embed attack code in individual pixels of the banners. This exploit has been around for several years. Its unusually stealthy operators scored a major coup by getting the ads displayed on a variety of unnamed reputable news sites, each with millions of daily visitors. It hides parts of its code in the parameters that control the pixel colors used to display banner ads.

Vera Bradley stores receive the attention shoppers award. They notified customers of a credit card exploit, which affects customers paying by credit cards in their stores from July and September of this year. Card numbers and names were captured by malware found running in their data center. The company has 150 stores selling fashion merchandise.

Oops mom, no firewall award goes to a Finnish facilities manager. Thanks to no firewall and a DDoS-based DNS attack.  At least two housing blocks in the city of Lappeenranta were affected and confirmed by the facilities management company. Hackers gained remote access to the HVAC systems. Luckily, outdoor temperatures weren’t critical.

The award for security starts in the home goes to so many companies it is hard to pick just one, but let’s give the honor to the Ameriprise employee who had a home-based network storage device with no password whatsoever. The drive was synchronized with one in his office, allowing anyone to view sensitive client data. Expect more of these sorts of attacks as the line between home and work continues to disappear.

And the most zero days reported in the past year: Adobe Flash, of course. No week would be complete without one!

What were your favorite breaches of the past year?