Filtering all posts in Security

15 December 2017

In which Lukas Reschke explains step-by-step how he got remote code to execute in Atom via Cross-Site Scripting (the specific vulnerability he found was patched in v1.21.1).

Atom happens to be the single most popular Electron project on GitHub. I suspect that, were a study to be done, an large number of Electron apps would be found to be vulnerable to XSS attacks in some shape or form. What makes this angle of attack particularly bad for Electron apps is that injected JavaScript, just like the JavaScript the app’s developer wrote, has full access to the NodeJS core. Lukas demonstrated this by launching the Calculator app via a child process; its not hard to think up something far more destructive (or discreet) to run once you have this much access though:

One easy way to [execute malicious JavaScript code], in this case, is by accessing the window.top object and use the NodeJS require function to access the child_process module. The following JavaScript call would open the Mac OS X calculator:

window.top.require('child_process').execFile('/Applications/Calculator.app/Contents/MacOS/Calculator',function(){});
14 December 2017

A paper by Lance Spitzner from back in 2003 in which he explains honeytokens, their huge power to simplicity ratio, and provides some good examples.

My highlights

The term honeytoken was first coined by Augusto Paes de Barros in 2003 on the honeypots mailing list.

[…]

A honeytoken can be a credit card number, Excel spreadsheet, PowerPoint presentation, a database entry, or even a bogus login. Honeytokens come in many shapes or sizes, however they all share the same concept: a digital or information system resource whose value lies in the unauthorized use of that resource. Just as a honeypot computer has no authorized value, no honeytoken has any authorized use.

[…]

For example, the credit card number 4356974837584710 could be embedded into database, file server, or some other type of repository. The number is unique enough that there will be minimal, if any, false positives. An IDS signature, such as Snort, could be used to detect when that honeytoken is accessed. Such a simple signature could look as follows.

alert ip any any -> any any (msg:"Honeytoken Access - Potential Unauthorized Activity";   content:"4356974837584710";)  

This concept can easily be extended beyond databases. File, web, or email servers can all have honeytokens embedded into them. Anything that has data can easily have additional bogus data added, bogus data that becomes our honeytoken.

12 December 2017

Canarytokens is a very cool looking tool built by Thinkist that allows you to easily — and freely — generate and monitor honeytokens.

These tripwires can be set off in a number of ways of your choosing, from a simple GET request all the way to triggering when a specific query is run on your MySQL database. SELECT * FROM user_passwords for example.

A number of helper tools are provided for use with Canarytokens, all of which are described in the linked blog post. The two that seem most interesting to me are the aforementioned MySQL trigger and the FileWatcher trigger which notifies you when a specific file is read.

Canarytokens is open source and self-hosting is made easy thanks to an official Docker image.

18 November 2017

Snyk has been around for a while but this fantastic new addition to GitHub brings dependency vulnerability monitoring to the masses.

Vulnerabilities that have CVE IDs (publicly disclosed vulnerabilities from the National Vulnerability Database) will be included in security alerts. However, not all vulnerabilities have CVE IDs—even many publicly disclosed vulnerabilities don’t have them. We’ll continue to get better at identifying vulnerabilities as our security data grows.

They “only” support JavaScript and Ruby at the moment — in addition to those two, Snyk also supports Java, Scala, Python, Go and Gradle — but Python support is said to be coming in 2018 and I’m sure they won’t stop there.

13 November 2017

In a blog post about new user protection features coming to Chrome in future versions, Ryan Schoen mentions this update scheduled for Chrome 65 which should prevent the target='_blank' vulnerability known as “tabnabbing”:

When the user interacts with content, things can also go wrong. One example that causes user frustration is when clicking a link opens the desired destination in a new tab, while the main window navigates to a different, unwanted page. Starting in Chrome 65 we’ll also detect this behavior, trigger an infobar, and prevent the main tab from being redirected. This allows the user to continue directly to their intended destination, while also preserving the context of the page they came from.

If you’re unfamiliar with tabnabbing, a non-malicious demo along with recommendations on how to prevent the attack can be found here; here’s a nice concise write up about the attack too.

25 August 2017

U2F devices have been on my radar for a while; I’ve yet to take the time to investigate them properly though. This collection of to-the-point overviews of the most popular devices provides a nice jumping-in point.

7 July 2017

Andy Greenberg has written an excellent piece for Wired which looks at Russia’s quickly-becoming-annual proof of concept cyberattacks on the Ukrainian power grid:

Noting the precise time and the date, almost exactly a year since the December 2015 grid attack, Yasinsky felt sure that this was no normal blackout.

[…]

Yasinsky knows by now that even as he’s analyzing last year’s power grid attack, the seeds are already being sown for 2017’s December surprises.

Failing to plan is planning to fail. They planned:

Once the circuit breakers were open and the power for tens of thousands of Ukrainians had gone dead, the hackers launched another phase of the attack. They’d overwritten the firmware of the substations’ serial-to-­ethernet converters—tiny boxes in the stations’ server closets that translated internet protocols to communicate with older equipment. By rewriting the obscure code of those chunks of hardware—a trick that likely took weeks to devise—the hackers had permanently bricked the devices, shutting out the legitimate operators from further digital control of the breakers.

Concepts are proven for a reason. I suppose only time will tell if the reason this time ’round is to deter other nations or to engage them:

A grid attack on American utilities would almost certainly result in immediate, serious retaliation by the US. Some cybersecurity analysts argue that Russia’s goal is simply to hem in America’s own cyberwar strategy: By turning the lights out in Kiev—and by showing that it’s capable of penetrating the American grid—Moscow sends a message warning the US not to try a Stuxnet-style attack on Russia or its allies, like Syrian dictator Bashar al-Assad. In that view, it’s all a game of deterrence.

[…]

But for those who have been paying attention to Sandworm for almost three years, raising an alarm about the potential for an attack on the US grid is no longer crying wolf.

2 April 2017
1 December 2016

Now serving over HTTPS and HTTP2

Every so often I check to see if GitHub have added a way to serve websites hosted on GitHub Pages with a custom domain over HTTPS rather than HTTP. Whilst clicking around to that end last night, I found that the answer is still no. I did stumble upon a service called Netlify however.

As this site uses Jekyll plugins I can’t push directly to my username.github.io repo, it needs to be built first. To avoid having to do that manually, I setup a whole song and dance on Wercker that turned out to be more hassle than it was worth.

Netlify is, in short, a one-stop-shop for static sites. The features that attracted me to it were the Git integration—all I need to do is push a post to the repo and it’ll handle the rest (including building the site despite it using plugins, taking Wercker out of the mix), the free SSL certificates via Let’s Encrypt and the HTTP2 support. A global CDN, and fast DNS aren’t features to shake a stick at either, but GitHub pages has those covered too.

The setup was quick and easy: I pointed Netlify at the site’s repo, it detected that the generation engine was Jekyll, automatically setup a box, built it and served a preview. From there, I just removed the two A records that pointed at GitHub and added one that points to Netlify, added my custom domain in the admin and waited for the lot to propagate. Once it had, SSL was a click away and only one more click was needed to force TLS connections.

If your site’s repo is public on GitHub then Netlify gives you all this functionality on the house. From the few hours I’ve spent with it, I’d highly recommend it as an alternative to GitHub Pages.

28 June 2015

Tidying up access

Following a temporary files-are-missing-and-I-didn’t-delete-them scare, I changed my Dropbox password. Whilst I was in my security settings, I checked the list of applications that currently had access to my Dropbox—something I can’t ever remember reviewing despite having had an account for many years.

18 apps had access, 12 of which had full access.

Whilst fortunately there weren’t any in there that I didn’t trust, there were plenty I didn’t need anymore and proceeded to revoke their access.

As I was scrolling down to the linked apps list, I was alarmed at the length of the linked devices list. 29 devices were linked to my Dropbox.

When you do a clean install on your Mac, iPhone, et cetera and Dropbox is re-installed and re-linked, it counts it as a new device. Once I figured that out and scanned the “most recent activity” column I was less concerned but again—I revoked access to everything that wasn’t needed leaving just 3.

Now that my mind was thinking about “What other services do I use that apps get linked to?” I went to check my Twitter account. Unlike my Dropbox, I have reviewed the list of apps that are linked to my Twitter account a few times in the past but not having used it in close to a year, I wondered what was in there that didn’t need to be. 23 apps that I no longer use had access. They too were revoked.

I consider myself to be pretty careful with which apps I give access to what so was surprised by how many had added up over time. Whilst I trusted (to a point) everything that did have access, 20-odd apps leaves a heck of a big margin for error.

If you haven’t done so in a while, I’d recommend checking your Dropbox, Twitter, et cetera, accounts for anything that has access that you no longer use.

From a user’s perspective, it’d be nice to receive and email from time-to-time from these companies recommending that the list be reviewed.

Dropbox’s account security settings.

Twitter’s connected services preferences.

You can keep up to date with new posts by subscribing to the RSS Feed or by following me on Micro.blog.