The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Monday, May 13, 2019

“If you strike me down, I shall become more powerful than you can possibly imagine”

Of all the lightsaber duels in the Star Wars movies, the one in “Star Wars: Episode IV—A New Hope is probably the most sedate. But that's okay, because in 1977 this is the first time we're seeing freaking lightsabers! So cool! And it blew my 8-year old mind at the time.

But this reimagining of that fight? (link via Kirk Israel)

[Do you know just how painful it is to fall into a lava pit?  Do you?]

Had I seen that as an 8-year old, my head would have exploded!


They aren't attacking, they're being attacked

So that list of IP addresses I listed yesterday … it turns out they weren't the attackers, but the victims! And I was unwittingly helping to facilitate a DDoS amplification attack.

Sigh.

When we left off yesterday, I had modified my QOTD server to log the IP address, port number, and the incoming UDP packet to help figure out what the heck was going on. So pretty much off the bat, I'm seeing this (which goes on for nearly 4,000 entries):

38.21.240.153:6951      "\001"
38.21.240.153:7333      "\001"
38.21.240.153:37152     "\001"
38.21.240.153:6951      "\001"
38.21.240.153:7333      "\001"
38.21.240.153:37152     "\001"
38.21.240.153:6951      "\001"
38.21.240.153:7333      "\001"
38.21.240.153:37152     "\001"

What had me puzzled are the ports—I wasn't familar with them. It may be that port 6951 deals with online transaction processing, port 7333 seems to have something to do with the Swiss Exchange, and nothing at all about port 37152. It's not exactly looking good, but the ports being attacked are rather all over the place (I'm only going to list two of the attacked IP addresses—there are more though):

Ports being attacked
host address port number requests
host address port number requests
38.21.240.153 10947 1508
38.21.240.153 11860 1425
38.21.240.153 14485 1420
38.21.240.153 65033 1418
38.21.240.153 4625 1409
38.21.240.153 4808 1401
38.21.240.153 37152 1400
38.21.240.153 65277 1394
38.21.240.153 27683 1389
38.21.240.153 17615 1389
38.21.240.153 48235 1388
38.21.240.153 27227 1386
38.21.240.153 14503 1386
38.21.240.153 43174 1385
38.21.240.153 43069 1377
38.21.240.153 47040 1372
38.21.240.153 6991 1370
38.21.240.153 18235 1369
38.21.240.153 57696 1360
38.21.240.153 7333 1233
38.21.240.153 6951 1204
38.21.240.153 36965 1171
38.21.240.153 16306 1139
47.99.152.166 47673 145
47.99.152.166 39606 144
47.96.172.52 48309 142
47.96.172.52 46769 142
47.107.64.105 59669 142
47.107.64.105 35763 142
47.107.64.105 22100 141
47.99.152.166 4302 140
47.107.64.105 53336 140
47.99.152.166 35758 138
47.96.172.52 44529 138
47.96.172.52 26878 138
47.107.64.105 52337 138

A lot of the ports are high values, which tend not to have defined services and are typically used for outbound requests to a service, like making a request to a QOTD service.

The data being sent is just a single byte, which is all that's really needed for the QOTD protocol to return a quote via UDP. So this looks like legitimate traffic, except for the volume.

But as I kept searching for “QOTD attacks” I kept coming across UDP amplification attacks (more of the same). It appears that the vast majority of traffic is forged (it's easy enough to forge UDP packets), and because QOTD sends more data than it receives, it's a rather cheap method to attack a target with a ton of traffic regardless of what the attacked machine is being used for (and my UDP based server probably isn't the only one unwittingly facilitating this attack).

A bit more research revealed a few servers that made a request (or a very small number of requests):

Requests to the UDP QOTD server
host address requests first request
host address requests first request
74.82.47.61 2 May 03
185.94.111.1 4 May 04
74.82.47.37 1 May 04
74.82.47.17 1 May 05
71.6.233.171 1 May 06
74.82.47.29 1 May 06
104.152.52.39 1 May 07
74.82.47.57 2 May 07
74.82.47.33 1 May 08
206.189.86.188 1 May 10
74.82.47.49 1 May 10

I'm guessing these machines made the query to see if my machine could be used for a UDP DDoS amplification attack, and would periodically check back to see if such attacks could continue from my server, which would explain the periodic nature of the deluge of traffic I saw (they weren't continuous but would happen in very random bursts). I also suspect there may be two different groups doing an attack, given the volume of traffic to certain targets.

It was also amusing to see 104.152.52.39 attempt to spam me with email, and attempt to log in via ssh on the 7TH as well.

I've since disabled the UDP protocol on my QOTD server. Sigh. This is why we can't have nice things on the Intarwebs.

Sunday, May 12, 2019

Experimental headers are no longer experimental

On the Lua Users email list the topic of custom email headers came up. Back in the early days, RFC-822 stated that:

Any field which is defined in a document published as a formal extension to this specification; none will have names beginning with the string "X-" …

RFC-822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

This also applies to headers starting with “x-” as Internet based text headers are case-insensitive.

Now given that RFC-822 has been obsoleted by RFC-2822 and RFC-5233 I thought I would check those out as well:

Fields may appear in messages that are otherwise unspecified in this document. They MUST conform to the syntax of an optional-field. This is a field name, made up of the printable US-ASCII characters except SP and colon, followed by a colon, followed by any text that conforms to the unstructured syntax.

The field names of any optional field MUST NOT be identical to any field name specified elsewhere in this document.

RFC-5322: Internet Message Format

Hmm … nothing about “X-”. I replied that starting a non-standard header with “X-” was still a safe way to go, only for Cunningham's Law to kick into effect:

From
Daurnimator <XXXXX­XXXXX­XXXXX­XXXXX>
To
Lua mailing list <lua-l@lists.lua.org>
Subject
Re: Adding another way to point to "levels" to debug.getinfo and friends
Date
Mon, 13 May 2019 11:55:07 +1000

On Mon, 13 May 2019 at 09:03, Sean Conner <sean@conman.org> wrote:

In other RFC documents (too many to mention) private or experimental fields are usually labeled with "X-" (or "x-") so your best bet is to create a header name starting with "X-" to be safe.

Please stop using the X- prefix! See RFC 6648:

This document generalizes from the experience of the email and SIP communities by doing the following:

1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].

Interesting. The “X-” standard for non-standard headers was to allow for experimentation without fear of conflicting with other headers, but the process of converting such headers to a standard header prove problematic. But RFC-6648 does cover the case when one doesn't want to standardize a header (or parameter):

… In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122].

RFC-6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

What a wild idea!


I wonder what they think they're attacking?

In addition to a self written gopher server I also have a QOTD server accepting requests via TCP and UDP. I never mentioned it as I just put it out there to really see what would happen. I will occasionally see a request go by, but over the past two weeks, some people have really been hitting it hard via UDP:

Requests to the UDP QOTD server (over 1000 requests)
host address requests
host address requests
38.21.240.153 252628
113.113.120.152 18547
148.70.95.145 11529
150.138.92.17 11400
149.248.50.17 9917
123.129.223.133 9373
222.186.49.221 8689
39.105.122.74 8261
182.150.0.73 8098
47.107.64.105 7575
101.132.44.244 5745
170.33.8.193 5566
140.249.60.227 5520
61.160.207.99 5278
47.244.154.2 5084
23.107.43.194 5067
47.101.222.141 5066
47.101.169.118 5024
47.101.68.112 4449
47.102.135.146 4325
47.75.116.41 4200
47.244.36.42 4137
104.25.221.35 3638
144.48.125.176 3440
219.234.29.229 3402
125.88.186.186 3219
47.99.152.166 3167
39.108.51.161 3166
47.101.51.117 3161
210.83.80.21 3154
47.100.96.218 3139
47.101.200.97 3137
120.79.0.221 3090
47.100.183.18 2971
39.96.31.5 2944
47.98.38.120 2758
101.132.182.251 2756
47.107.123.238 2492
139.99.16.112 2290
47.101.157.245 2258
106.14.158.7 2226
47.100.234.2 2183
47.100.201.32 2090
120.79.40.9 2047
47.100.125.115 2037
101.132.37.45 1997
120.78.5.80 1985
47.101.68.50 1950
47.96.172.52 1915
20.188.110.231 1781
106.14.137.34 1118
119.188.250.37 1095

There doesn't see to be much I can find about this, other than a potential link to XBox Live, but that doesn't seem right. It's hard to say. So to see what might be happening, I modified the QOTD program to record anything it receives via UDP. That way, I should be able to figure out if 38.21.240.153 is trying to attack something, or if it really just wants an up-to-date quotes file.

Wednesday, April 24, 2019

Just one of life's smaller mysteries

Some fellow cow-orkers and I were returning from lunch to work and as we rounded the corner to The Ft. Lauderdale Office of The Corporation, we found the entire front of the building swarming with fire and rescue vehicles. Thirteen in all.

There were no police, so it wasn't an office shooting (thankfully!). No crowd of people were huddled outside the building, so there didn't appear to be an evacuation. No smoke, so there apparently was no fire. But something happened that required thirteen responding units.

[You can easily make out four firetrucks, one of which was in the process of transforming to a giant robot.] [Another four, although one is hidden somewhat by the trees.  There are more, but you can't see the trucks for the trees.]

We were able to park and enter the building. From what little we heard, there was an “incident” on the 6th floor, but what it was, and how many were involved, was unknown.

Just one of life's smaller mysteries.

Tuesday, April 23, 2019

Dealing with phone numbers

Project: Wolowizard only supports NANP numbers, but since those numbers come via The Protocol Stack From Hell clearly marked as NANP, it's easy to determine there if a number is NANP or not. It's not quite as simple in “Project: Sippy-Cup” since SIP is … a bit loose with the data formatting.

There, the numbers are formatted as a tel: URI (or a sip: URI but the differences are minor). If the number is “global,” it's easy to determine a NANP number because it will be marked with a “+1” (“1” being the country code for North America). So, tel:+1-501-555-1212 is most definitely a NANP number, while tel:+501-555-1212 is not.

Things get a bit more muddy when we receive a so-called “local” number. RFC-3966 clearly states that a “local” tel: URI MUST (as defined in RFC-2119) contain a phone-context attribute—except when it doesn't (I swear—the RFC contradicts itself on that point; tel:8005551212 is valid, even though it's a “local” number and missing a phone-context attribute because it's a “national freephone number”). So tel:555-1212;phone-context=+1501 is NANP, while tel:555-1212;phone-context=+501 is not (look closely at the two—one has a country code of “1” while the other has a country code of “501”). It's worse though, because while tel:555-1212;phone-context=+1501 is NANP, you cannot use the phone-context attribute to reconstruct a global number (the RFC contains the following example: tel:863-1234;phone-context=+1-914-555—um … yeah).

To further complicate things, the phone-context attribute does not have to contain digits—it can be a domain name. So tel:555-1212;phone-context=example.com is a valid number. Is it NANP? International? Who knows?

So what does “Project: Sippy-Cup” do? If it receives a “local” number with a “+1” country code in the phone-context attribute, it's marked as NANP; any other country code is it marked as non-NANP. If the phone-context attribute contains a domain name, it is treated as a NANP number (based on what I saw in production). And if there's a missing phone-context attribute for a “local” number, “Project: Sippy-Cup” treats it as a NANP number if it has at least 10 digits.

Now, why do I care about this? Because we want to avoid doing an expensive database query for non-NANP and invalid NANP numbers, but “Project: Heimdall” wants all the numbers for tracking potentially fraudulent calls.


The feeling when your new task is already done

“The ‘Project: Heimdall’ team now want all the numbers,” said TS1, my fellow cow-orker.

“Really?” I asked. “They can finally deal with international phone numbers?”

“Apparently yes. So ‘Project: Sippy-Cup’ needs to open the flood gates and let all the numbers through. But make it configurable.”

“Okay.”

So I dive into the code for “Project: Sippy-Cup” and … what's this? The code is already in place. From last year. When it was clear that “Project: Heimdall” could not, in fact, handle all the numbers! I remember it was annoying having to send all NANP numbers (those that are 10 digits, like “501-555-1212”), even the malformed, invalid NANP numbers (like “501-511-1212”), while making sure I didn't pass along valid, international numbers that also happened to be 10 digits long (like “501-555-1212”). Now that the “Project: Heimdall” team has to deal with the crap we get … well … good luck. We're all counting on you.

Monday, April 22, 2019

“Can you tell me how to get? How to get to Westeros?”

I have a few friends that are into “The Game of Thrones” (and if not the TV series, then at least the book series). For them, I have two videos: the first is “Game of Chairs,” a Sesame Street parody of the TV show. The second video is … well … a meeting between Cersei and Tyrion that is interrupted by an unexpected guest. To say more would be to spoil it.

Thursday, April 18, 2019

“Help! I'm still trapped in a Chinese fortune cookie factory!”

Bunny and I are having dinner at a Chinese restaurant. The check is delivered and we crack open our fortune cookies. Mine is something generic, but Bunny's cookie says, as God is my witness:

[“Pick another fortune cookie?”  I guess that's a great way of increasing sales.]

Unfortunately, there was no other fortune cookie to pick from. Go figure.

Monday, April 15, 2019

I like the whole “computers-in-wood” asthetic

Love Hultèn (or Hultén—it's spelled both ways on that page) made a series of life sized computers based off the old Lego computer bricks (link via Jason Kottke) and I must admit, they are very cool!

But then I checked out Love's other projects and the The Golden Apple—wow! A Mac Mini housed in a custom walnet case based off the original Macintosh 128K case is just beautiful (although to be truthful, I could do without the gold keys on the keyboard but that's me). The Pet De Lux is no slouch either.

One of these days, I'll get a computer into a wood case. One of these days …

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: http://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

http://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2019 by Sean Conner. All Rights Reserved.