Insecure Storage Of Liquid Confections

Recently it was disclosed that a giant, well-known, multinational confection supplier was hacked. Their proprietary recipes were altered—for reasons unknown—by malicious actors.

Seasoned security professionals can only shake their heads and sigh. To them the security flaws of this company are legendary, although in the past the company has managed to escape publicity and accountability for their haphazard security practices.

The most notorious incident happened over fifty years ago to a Mr. Y. Y. Mann (not his real name). In those days it was common practice in the industry to store liquid confectionery ingredients in large, unguarded, 30 foot deep vats in publicly accessible areas, protected only by a cheap metal railing.

Mr. Mann—who was walking down the street minding his own business—happened upon one of these vats in his neighborhood. A skilled and talented acrobat, he balanced himself on the railing as he had done many times before.

Little did he know that someone had greased the railing earlier that day. Due to a documented history of filial rivalry, police immediately suspected a conspiracy between his brother and his mother, but nothing was ever proven beyond a shadow of a doubt and to this day the miscreant has yet to be identified.

Inevitably, Mr. Mann slipped and fell into the vat, but his quick thinking enabled him to summon help and he was extricated from his predicament.

However, the incident left him horribly scarred for life (WARNING: graphic image). The company attempted to settle out of court but Mann, shaken by the incident, refused. Thereafter the company staged an effective public relations campaign to keep the story out of the public eye.

Angered by this, Mann became a tireless protester during the tumultuous 1960s, fighting for new public safety laws to prevent this kind of atrocity from ever happening again and documenting his ordeal in popular folk music of the day.

His struggle ended with the passage of the Secure Confectionery Storage Act of 1967, which effectively outlawed the practice of storing dangerous ingredients in public areas. Despite these reforms accidents of this nature continue to this day, although less frequently.

Amazon EC2 Proxies

Back on Proxy Obsession, before I was so ignominiously bounced from GoDaddy, I mentioned an Irish proxy that was stable and fast. The IP belonged to Amazon Advanced Web Services, having a hostname ending in amazonaws.com.

I didn't think much about it at the time, other than to mention it, but it appears there are lots of folks putting up "private"—or so they believe—proxies on Amazon's "Elastic Compute Cloud" (a.k.a "EC2") service.

Well, surprise, they're not private and the proxy listers have been hunting and posting them for a long time, if my database is any indication.

I have them going back to 2008, when the list started, but there's been a lot of growth in this segment since 2010.

They're all either in Dublin or Seattle (with one outlier in Singapore), so that in itself is a dead giveaway. But GeoIP can't locate them all, so you really have to go by a reverse DNS lookup to tell for sure.

Here's a small sample of the DNS names I have collected...

Now, I have no idea whether these folks are violating Amazon's Terms of Service by doing this, and I really don't care whether they are or not, but there is all kinds of "HOWTO" information published on the Web on setting up a free EC2 proxy. Try this search, for example.

In fact the only reason I mention it now is Amazon's role in the recent SONY attack. Take for instance this Bloomberg report...

For three pennies an hour, hackers can rent Amazon.com Inc’s servers to wage cyber attacks such as the one that crippled Sony Corp’s PlayStation Network and led to the second-largest online data breach in U.S. history.  A hacker used Amazon’s Elastic Computer Cloud, or EC2, service to attack Sony’s online entertainment systems last month, a person with knowledge of the matter said May 13. The intruder, who used a bogus name to set up an account that’s now disabled, didn’t hack into Amazon’s servers...

So... there you have it.

With that in mind, I am now marking the IP address of EC2 proxies with a cross (†) on the proxy list. There aren't a lot of them, but they're in there.

Don't use them if you don't want to attract attention to yourself.

End of the SOCKS Bubble?

Let me say right up front that I haven't run the numbers in depth yet, but it looks like the SOCKS boom is BUSTED in proxyland.

At this point in time, glancing over The List you'll see a few on the traditional SOCKS port (1080) and those mysterious port 27977 proxies. Just last month there were pages and pages and pages of port-hopping SOCKS4 proxies.

Where are they now? Did someone take down a botnet?

I haven't heard anything on that particular front since Microsoft & Rustock back in March, but SONY, RSA, PBS, et. al. have been hogging all the security news with their issues with LulzSec. You'd think after all that crap anyone who downed a botnet would be beating their drum pretty loud by now.

The daily numbers are pretty much the same. Every day I get 2500-5000 new proxies scraping the usual suspects. As usual, over half of them are Chinese, on port 9415.

I'm not all that sorry to see them go. Despite their usefulness for non-Web traffic, I have always preferred the plain old http (CERN) proxies, although lately I've been using a Glype proxy here and there (with NoScprit & Ad Block to kill the ads they try to shove down your throat) just because they're easy to use and generally dependable.

Maybe they'll return, but I have a feeling they're gone for now.

SoftLayer == Niche Player

Anyone who's ever followed Gartner's Magic Quadrants knows the lower left corner is usually the Loser's Quadrant.  If you can't make it to at least the "Challengers" quad (losers with attitude), there's not much your marketing department can do to help you spin the news.

Whenever an MQ is unleashed unto the world, the press releases start to flow from the Gartner-proclaimed  Challengers, Visionaries, and Leaders.

Not so much from the Niche Players.

So it's somewhat surpising to see SoftLayer strutting their stuff over their Niche Player status in the latest Gartner MQ for "Cloud Infrastructure as a Service and Web Hosting" (Price US$1,995).

Well, good for them.  They've had a checkered past.  Nice to see they're finally cleaning up their act.

Life During Cyber Wartime

Heard of a Prius that's loaded with iPhones
Packed up and ready to go
Heard of a Web site, up on GoDaddy
A place where nobody goes
The sound of noobies, off in the distance
I'm getting used to it now
Squatted in a mantion, squatted in a rental
I squat all over this dump

This ain't no Facebook, this ain't no Twitter
This ain't no surfing around
No time for blogging, or online dating
I ain't got time for that now

Upload the log files, to the sysadmin
Hope for a backlink some day
I got three avatars, a couple OpenIDs
You don't even know my reddit name
Back there at 4chan, hackers uploading
Everyone's ready to troll
I schlep in the daytime, I hack in the nightime
I might not ever get laid

This ain't no Facebook, this ain't no Twitter
This ain't no surfing around
This ain't no MySpace, or fucking flashmob
I ain't got time for that now

Heard about Google? Heard about Yahoo?
Heard about eharmony dot com?
You oughta know not to surf using Windows
Somebody hack you out there
I got some thumb drives, some elite kid scripts
To hack a shitload of sites
But I ain't got no iPod
Ain't got no earbuds
Ain't got no iTunes to play

Trouble in transit, we got through Websense
We blended in with the noobz
We got some shell code, we're hacking telcos
I know that that ain't elite
We dress like hipsters, we dress like camwhores
or in stinky old shorce
I changed my goatee so many times now
I don't know what I look like!

You make me nauseous, I feel like puking
We make a decent Red Team
Don't get exhausted, I'll do some coding
You ought to get you a latte
Why stay in college? Why go to tech school?
Gonna get certified this time?
Can't write an email, can't send e-postcards
I can't do nothing at all
This ain't no Facebook, this ain't no Twitter
This ain't no surfing around
I'd like to hack you, I'd like to pwn you
I ain't got time for that now

Creepy Convergence

One early Sunday morning back in October, Gastonia (NC) police found a 2009 Hyundai Sante Fe parked in their own parking lot.  Inside were a pair of bodies, the victim and perp of a murder/suicide.

Tragic, but it happens every day.  On average, it happens about twice a day.  There is no avoiding it.  It happens.

This always triggers a number of events.  The police have to investigate.  The bodies have to be removed.  The crime scene has to be cleaned up.  Coroners are woken up.  Autopsies are performed.  And sooner or later the unfortunate actors of their own Final Tragedy are laid to rest.

The twist in the Gastonia murder/suicide was somewhere along the line a mortuary worker lifted a credit card from the victim.

Or, if you believe her creepy MySpace page, the mortuary manager.  (I don't expect this page to be up forever, so I have preserved it at right.  Click for a larger view.)

This particular mortuary advertises many of the services involved in the chain of events that happen after a murder/suicide, including body transport and autopsy, so it's not unusual the Gastonia police contracted with them for this incident.

Now, the mortuary has a public relations nightmare on their hands.

And they're looking for a new manager.

The cops, too, need to take a look at their chain of evidence policies and procedures.  And a second look at their dealings with this company in the past.

Then someone needs to take a long, hard look at ChelleMorticia.  With search warrants.  And maybe a cadaver dog or two.

This is not going to be the last we'll hear about her.

Disturbing Update

It seems our girl has taken her own life.

Still, this is not the end of this story.

0days & Anonymous Assclowns

Tomorrow, August 2nd, Microsoft is supposed to release a patch to address the (decade-old) "LNK" 0day vulnerability in all (supported) versions of Windows.

If you haven't heard about this yet, you've been living under a rock for the past month.

Or, like most people, you just don't give a shit about computer security (after all, you play UT99 and install untrusted DLLs almost every time you play, right?).

I consider this a severe threat. So much so that I have moved all my online activities (except UT) over to Linux, specifically my 64bit Mythbuntu system.

(And - incidentally - I have also been using Opera, which is much better on Linux than it is on Windows - why is that?)

If you're wondering why you haven't heard about this on Hinky Links, the fact is I'm pretty burnt out on security and I've been letting Hinky Links slide into the shitter.

On top of that, working at the Salt Mines has been an incredible disappointment. Rumor has it our "Security Officer" is about to get the axe, and he's been acting like it.

That would be Anonymous Assclown #1 and the less said about him the better.

Anonymous Assclown #2 recently dropped a few threatening comments here at Blogspot accusing me of being in cahoots with yet another Assclown. I have no clue what that is all about, but if he shows up again I'm going to have to shut off anonymous comments.

ASSCLOWN UPDATE

I didn't mention it earlier, but this is what Assclown #2 had to say...

If you fail to answer my question in a timely manner, I will assume that you are working directly with Kimmo [this guy - hinky]. As such, I will be forced to send tons of false abuse reports to your registrar and host, GoDaddy, which may result in you losing your domain and hosting privileges.

I'm not sure what this assclown's schtick is, but apparently this "Kimmo" dude has raised the ire of 4chan et. al. over the past few years.

Me, I never heard of him. But since I'm not interested in losing my GoDaddy accounts just yet (although I've been bitching about them for years now), I called Tech Support and let them know of this guy's threats. Their policy is to contact the client before taking any action on abuse complaints, so it shouldn't be a problem.

I deleted Assclown 2's original comments but if he shows up again I'll probably let them float for awhile, just for posterity's sake.

Changing The Default SSH Port Without "Really" Changing It

UT99 players can sit this one out.

For years, on security forums and mailing lists, if you ever dared to suggest changing SSH's default port (TCP 22) the "security by obscurity" crowd would come out of the woodwork and nail your ass to the Cross of Righteousness for having the unmitigated gall to even dare utter such heretical nonsense.

Unfortunately for these dogmatic True Believers, changing the ssh daemon's default listening port is such an incredibly effective method for avoiding ssh scans and brute force password attacks that it's starting to show up in HOWTO security articles as a method for hardening your system.

For example, see this article at Linux Magazine.

But the Port 22 Crowd will not leave well enough alone. Although they haven't abandoned the "security by obscurity" mantra completely, they're now using the following argument with increasing frequency:

NEVER CHANGE YOUR SSH PORT! If an exploit comes out that can crash SSH locally, a local unprivileged user on your system could crash SSH and start their own daemon on the SSH port > 1024 and capture your usernames and passwords. If you want SSH on a different port, do this with firewall rules.

Note that ALL CAPS is required when raising this alarm.

Also note that if you require users to connect with SSH in the first place, it's not going to do them a helluva lot of good to crash SSH. If you have users who actually sit down at the keyboard of the physical system, that's another problem entirely. Why bother with crashing SSH when they can slip a bootable CD into the tray and bounce the box?

And of course if you choose a port other than 22 but less than 1024 you can avoid this issue completely.

However, "changing the port with firewall rules" struck me as a novel idea (maybe I'm just stupid but it never occurred to me before) and set me to wondering how you would do such a thing, since I've always taken the easy way out by changing or adding ports in sshd_config.

So I sat down with iptables and experimented a bit. I came up with the following method. If everything you have is behind NAT, the problem can be reduced to simple port forwarding. If not, there are a few hoops you need to jump through. Be advised the iptables rules presented below assume you have a blank set of rules. Just copying and running them against an existing set of rules probably won't work.

First, set SSHD back to the default port 22. Next, figure out what port or ports you want to do SSH over. We're going to use 44, 88, and 8188 here.

Now we take care of the Hypothetical Evil Unprivileged User by not accepting anything over those ports in the first place. This is only meaningful for port 8188 (since 44 and 88 are privileged ports) but we'll do all three for the sake of completeness:

#~iptables -t filter -A INPUT -p tcp -m multiport --dports 44,88,8188 -j REJECT --reject-with tcp-reset

Then, pick a number between 1 and 4294967295. This will be the value of the iptables "mark" we use for ssh. I'll use 0x2200 (8704), just because it's ssh-ish, but any positive integer in that range will do. We're going to tell iptables to reject anything without this mark coming into port 22.

#~iptables -t filter -A INPUT -p tcp -m tcp --dport 22 -m connmark ! --mark 0x2200 -j REJECT --reject-with tcp-reset

I would prefer to DROP these packets rather than REJECT them, but more on that later.

Now we'll tell iptables what ports we will accept for ssh.

#~iptables -t filter -A FORWARD -p tcp -m multiport --dports 44,88,8188 -j ACCEPT

In the "mangle" table we slap our mark on these packets.

#~iptables -t mangle -A PREROUTING -p tcp -m multiport --dports 44,88,8188 -j CONNMARK --set-mark 0x2200

Finally, in the "nat" table we tell iptables to send the marked packets back to port 22.

#~iptables -t nat -A PREROUTING -p tcp -m multiport --dports 44,88,8188 -j REDIRECT --to-ports 22

The packets go back to the INPUT rule and, since they're marked correctly, are sent to the SSHD process listening on port 22.

We have done exactly what was recommended, i.e. we have indeed changed the default ssh port with firewall rules alone (and without NAT). And yet, ssh still listens on port 22!

I must admit this appeals to me on a number of levels, not the least of which is that it has all the hallmarks of a slick little hack. Secondly, it definitely takes a load off of the ssh daemon since it's listening on one port instead of three (in reality I have ssh listening on seven ports).

However, this is done at the expense of complexity, which has yet another group of Annoying True Believers who are fond of chanting "COMPLEXITY IS THE ENEMY OF SECURITY" at the slightest provocation. This is another religion I have never bought into (it may be the same group since increasing complexity generally tends to increase obscurity).

Well, fuck them, you can't please everyone.

Besides, I use the most bizarre, complex combination of port forwarding and routing you'd ever want to see. Most days I have a hard time understanding it myself. It keeps me sharp.

I am almost 100% certain this wouldn't please a "real" firewall administrator. They're mostly overpaid Certified Cisco Clowns anyway. It would never even occur to them to actually use iptables.

But what we have done in essence is put all our trust in iptables working "just right". And we're betting the next time there's an update to the netfilter core code (or the kernel) everything will still work.

I've been around iptables/netfilter far too long to ever bet on that. Sorry, fellas, "once bitten, twice shy" and all that.

Then there's the TCP reset thing. Can it be bypassed? Web filtering appliances that use span ports and two-way TCP resets work fine when everyone "plays by the rules of TCP/IP" (actual statement from Web filter appliance vendor Sophos), but the Bad Guys don't usually play by the rules.

The alternative, DROP-ing the packet, lets anyone scanning our system with tools like nmap know with absolute certainty that SSHD is listening on port 22 since it will show up as "filtered". This makes TCP resets the lesser of two evils, but it's still evil.

In the end analysis, isn't sending a reset from an "open" port just another instance of "security by obscurity"?

Not that I care, that was a purely rhetorical question.

And what about attacks against iptables connection marking (CONNMARK) itself? Do they even exist? Am I opening myself up to an unknown exploit vector? Do I have to take additional measures to avoid spoofing or brute forcing or some other method (fragmented/crafted packets, maybe) to get around my firewall rules?

Even though we followed this fellow's advice, there are too many open questions and it appears that just changing the port in sshd_config is still a simple and effective countermeasure. It's worked for me for over ten years. I have escaped all 0day SSHD vulnerabilities for over a decade and no one ever tries to brute force passwords on my box. It doesn't happen because port 22 isn't open.

Simple. Effective.

duh!

So I feel compelled to shout out my own advice:

ALWAYS CHANGE YOUR SSH PORT!!!

The Hinky Dink Top 10 Koobface Infested Shitholes Report

FOR IMMEDIATE RELEASE

The Hinky Dink Top 10 Koobface Infested Shitholes Report

Columbus, Ohio – March 22, 2010 – Mr. Hinky Dink, a Big Time Security Professional™ today released an analysis of the spread of the Koobface worm. Based on an exhaustive study of his database of over two and a half million open Web proxies collected over two years, Hinky's findings demonstrate where the most vulnerable social networking users can be found.

“With more losers piling into social networking sites this trend is very likely to continue,” said Hinky. “This study highlights the cities with the most gullible users on the Internet. This study will no doubt help cybercriminals, script kidz, and Cameroonian puppy scammers target their next online marketing campaigns.”

View the complete report here.

CSO PWN3D!!!!

Here's a little bedtime story about Life in Hinky Dink's Security World.

Back in the Old Days, when l33t H@X0Rs and scriptkidz wrote viruses just for lulz and masssive IT butthurt (as well as worldwide credz) and had no clue how to make The Big Bucks pimping juicy 0day hax for e-gold, anti-virus companies used to send out newsletters enumerating newly discovered lulzware.

Back then (c. 2001-2005), people used to like to make the Security Team look bad by being better informed about such matters. We had to stay one step ahead, ready with a risk assessment at the drop of a hat. It was simple. In those days, viruses and worms travelled from East to West. Some guy in Hong Kong would go to work at 8AM, open an email, get infected, and begin the process of spewing lulz all over the Intertubes. By the time 8AM rolled around to New York City, most of Europe and Asia would be already infected and the security mailing lists would be well ahead of the anti-virus vendors (it was a funny time - all the "security experts" on those lists got hit the hardest and were generally the most butthurt of them all).

Scanning the lists and sending out local alerts became part of my job. If something was serious enough an email would be blasted to the entire IT department. Since this tended to make otherwise only mildly neurotic server room Trevs completely shit their pance and go into Full Panic Mode, it was avoided as much as possible. It was more important to keep them calm and focused. Otherwise they'd get so scared they wouldn't come back from lunch. For days (I'm not kidding).

At the very least, I would email the security team just to keep them informed. The same went for security patches and the like. It was extrememly important to keep on top of things. It still is.

That was then, this is now. Anti-virus companies can't keep up with the malware anymore and they don't send out alerts (in fact, AV is hardly any defense anymore). The Security mailing lists are just short of useless. The oneupsmanship is gone, mostly because now it's all about patches and the server room Trevs hate patching. As far as they're concerned patches don't exist and they never heard anything about them.

And instead of three people in the Team, there are now nine security droids. Most of them are newbs, and will freely admit it. And with minor exceptions they appreciate the "heads up" email I - used to - send.

Everyone except His Nibbs, the Chief Security Officer.

To be fair, the CSO gets a lot of email and it causes him unbearable butthurt. It's so bad he's just now answering emails from last May (again, totally serious). In this respect he is an extremely poor communicator. I'm convinced he does this on purpose for "plausible deniability", but a large part of the problem is all his responses must be perfect in every detail, the right font, the right bullet, the right signature, pertinent hyperlinks, etc. so it takes him the better part of an hour to respond - masterfully - to a single e-mail.

It was no big surprise that the Directive came down to "Stop Discussing Things In Email". The Team didn't stop. We simply refrained from cc'ing him. This worked very well, the CSO was oblivious, and everyone was happy, until one day His Nibbs got a hard-on for a huge, steaming pile of Microsoft SHIT called SharePoint.

Then we got a new Directive, "Start Discussing Things In Sharepoint".

OK, fine. I moved my "alerts'n'stuff" to the SharePoint Discussion Board. Only there was one problem: when you discuss something it sends everyone in the Team an email notifying you of the new discussion. When someone joined into the discussion, everyone got another e-mail. Net effect: no change in the amount of e-mail you received.

Frankly, this is configurable. You don't have to do it and there are other ways (RSS) to get some kind of notification. So then Mr. CSO had a Bright Idea: we would vote on whether or not to turn off e-mail notifications. The "Or Not's" won.

Honestly, I think most of the Team voted it down because the CSO was such a whiner about e-mail. (Note to CSOs who may be reading this: Democracy does not work in your favor. Whether you like it or not - and most do - you are a Dictator. So start acting like one and stop being a Whiny Little Bitch.)

After that, Yet Another Directive came down from the CSO: "Only Discuss Things That I Want To Discuss On The Discussion Board".

That immediately put an end to all discussion, all email notifications, etc. The crickets moved in and the Discussion Board promptly died. Not only did he not want to discuss anything, but the things he wanted to discuss amounted to nothing but Boring Shit. Plus he used it as a venue for new Directives, which, in his perfect and sublime mind, require no discussion. Who would dare argue with the CSO? Problem solved.

Naturally, the Team went back to e-mailing each other without cc'ing the CSO. "Fuck that noise" was the general consensus.

Noticing the Discussion Board traffic dropped down to nothing, and thoroughly annoyed by the all chirping crickets, the CSO decreed SharePoint should be expanded to include Blogs.

Therefore, New Directive: "Discuss Things I Don't Want To Discuss In Your Blog" or, more aptly, "Put That Shit Somewhere I'll Never Have To See It".

OK. Fine.

I became a reluctant, but prolific, Corporate SharePoint Blogger, starting out with a series on Why You Shouldn't Blog At Work Or Anywhere Else (there are no guidelines, no policy, no list of "Do's and Dont's", nothing). I made certain all my blogs were simple Cut & Paste articles. No original content whatsoever, with proper attribution and a link to the original whenever possible. I don't "say" anything and I'm going to keep it that way until these bozos can tell me what kind of trouble I'm getting myself into.

So that goes on for a few days and one morning I get a call from the CSO. It seems the CFO got her panties all in a bunch about the Pentagon getting infected with a virus and he wanted to know what the Hell was going on.

"Oh," I said, nonchalantly, "DIDN'T YOU READ MY BLOG? I WROTE ABOUT THAT TWO DAYS AGO."

PWN3D!