The Market Ticker
Commentary on The Capital Markets- Category [Technology]

Well now, it appears there is actually a story in here regarding malware tied to Russia:

BURLINGTON, Vt. –  Malware code linked to Russian hackers and found on a Vermont electric utility's computer is further evidence of "predatory" steps taken by that country against the U.S., a Vermont Democratic congressman said Saturday.

....

"This attack shows how rampant Russian hacking is. It's systemic, relentless, predatory," Rep. Peter Welch said in a statement. "They will hack everywhere, even Vermont, in pursuit of opportunities to disrupt our country."

Welch said the breach also underscores that sanctions President Barack Obama took against Russia this week were warranted. Russia, which has denied hacking U.S. systems, has been accused of interference in the U.S. presidential election by hacking American political sites and email accounts.

In other news the person who used that laptop was known to prefer pornographic video of sex with goats (sarc).

First off, said laptop was apparently owned by said utility but, the utility claims at least, it was not in any way connected to any part of their network, especially the parts that actually control its operations.  This leads one to wonder exactly what purpose said laptop had -- perhaps it was part of a meter-reading system in a company vehicle, for example.

"Vermonters and all Americans should be both alarmed and outraged that one of the world's leading thugs, (Russian President) Vladimir Putin, has been attempting to hack our electric grid, which we rely upon to support our quality-of-life, economy, health, and safety," the governor said in a statement.

Meh.  There's zero evidence to support that allegation.  First, we don't know how the malware got in there.  The most-common means by which it "gets in there" is the installation of a program that someone thought would do something else -- like, for example, play videos of people having sex with goats.

This is the dirty little secret when it comes to "rootkits" and other forms of persistent malware -- it has to get into the machine somehow, and the "somehow" on modern computers requires that you give it permission to install.

Installation on most modern machines is inherently an act that requires elevated privileges to some degree.  These privileges are (sadly) not usually very granular, so when you get the permission to do the installation if the installer has evil code in it that installer can put the evil code into the computer and protect it from being seen through normal means (and removed through normal means!)  This frequently includes corrupting one or more of the system's internal files so that absent a complete reload of the device in question it is virtually impossible to cleanly remove the evildoer's work.

Yes, there occasionally are vulnerabilities discovered that allow "unsanctioned" installations of this sort.  They're called "privilege escalation" attacks and the really ugly part of them is not only how many of them are discovered but that the places they're discovered are in pieces of code that execute with system privileges and thus can modify other, unrelated parts of the system and its software.  Most, but not all, of these pieces of software should not be written to require that sort of privilege but software vendors do it because they're lazy while government, commercial and individual users repeatedly give the vendors a pass instead of bending them over the table and destroying them.

Incidentally, this sort of malware is literally everywhere.  It's used by the people who "cryptolock" files and demand ransom, it is used by those who corrupt machines for the purpose of using them for "denial of service" attacks and as a means of relaying further data without being detected as the source and, sometimes, it is also used to directly target someone for data theft or corruption.

We don't know which was the case here, but it's a fairly good bet that this wasn't exactly a "targeted" attack as if it was it was rather poorly-executed.

Let me remind you that there certainly have been targeted and effective attacks in recent memory allegedly traced to actual state actors.  The OPM data heist is an example of a series of not only massive acts of stupidity inside our government it also illustrated active and intentional covering up of the breach once detected, including lying under oath -- which is a crime.  Yet the number of people prosecuted for said lying under oath and intentionally covering up said breach, which I remind you included fingerprints of millions of individuals along with detailed background check information related to virtually everyone who has held a security clearance in the last 20 years numbers zero.

There has also been no formal claim of "blame" laid on any foreign actor in this regard, although there certainly is more evidence pointing to who was responsible for that breach than either the DNC's hack or this laptop incident in Vermont.

This, I remind you, is despite the fact that China claims to have arrested people involved in same.

Yeah.

Folks, we have a major security problem throughout government and private-sector systems ranging down to the mundane such as your car, TV and cellphone.  We have agencies of our governmental units along with other critical private sector parties (like power companies) that intentionally and willfully ignore known protocols that are highly effective in preventing such attacks.  Among these acts of willful and intentional ignorance include using public email provider accounts or "private" (and poorly constructed) servers (a.k.a. Hillary), allowing corporate and government machines to have installed on them software that has not been vetted, allowing the attachment of external devices without authorization and vetting (e.g. USB drives, etc), continuing to allow the of software that has known security exploits in the field and more.  In the OPM case there were multiple critical breaches of security protocol any one of which would have likely been effective in preventing the attack from succeeding.  Taken together they would have almost-certainly not only prevented the attack but detected the attempts.

Folks, this stuff really isn't all that hard but it does mean that a certain amount of "convenience" has to be foregone.

That's the real problem, you see.  It's convenient to not lock your front door but if you do that the odds of a robber stealing your television go way up because now he can just walk in and take it!  Likewise, an email system that cannot have its storage accessed except via a VPN connection that requires a certificate to connect is extremely secure.  It now is not a matter of simply having someone's password now you have to steal a device and break into itand if you do your access is only good until the person realizes the device was stolen and the key is revoked.  If you configure a machine that is supposed to do a business or government-related thing (e.g. obtain usage data from electric meters and then transfer that to a central site for billing) so that no other connections than the authorized ones work then it becomes very hard to get the malware on the computer in the first place that would then be used to circumvent those controls.  Of course if you do that then the meter reader can't access Amazon, some news site or blog, or the gay sex with goats site using said business computer in the electric company vehicle.

Yeah.

In other words security when it comes to data access is a process, not a product.  You have a bunch of companies running around these days claiming to provide "security solutions" that are in fact nothing more than vendors of software that can easily be put together for free, who package it up and call it a "solution."  It is not.  These same firms then use break-ins as advertising; in other words they are very interested in seeing actual compromises happen because that "increases demand" for their products and services!

An example: Several years ago I raised hell about the so-called "advanced keyless entry" systems on automobiles, which by the way, are now the rule rather than the exception.  It was blatantly obvious to me with only a few minutes of thought that a pair of no-licence-required radios and a relatively small amount of effort (an effort I could trivially make myself) would allow a thief to repeat the signals from your key and car to each other over distances that would make theft trivial.  The key to making such thefts possible is the convenience factor of you not having to press a button on the keyfob -- that is, the car senses the key is near it and acts without a positive action being taken on your part. These systems normally only work within a couple of feet of one another and use a "rolling" code that leads people to "think" they're reasonably secure -- but if I can pick up the signal from one and repeat to the other end and do likewise for the response then I can pretend you are sitting in or standing next to the car when you're actually in the shopping mall!  It now becomes not only trivial to steal the car there is exactly no evidence of how I did it after the fact.

The stupidity of such a design is that if you have to push a button then it goes from trivial to very hard to exploit because now I have to capture you actually using the keyfob and then figure out the encryption so I can determine what the next code is because as a thief I cannot cause the fob to emit the next code by myself.  That's hard.  But if you don't have to push a button then I can simply ask the key for the next code and send it as if the key was sitting next to the car, and....... your nice new car is GONE!

In short we took what was a reasonably-secure system and made it insanely insecure just for the pleasure of your "convenience" in not having to push a button to unlock the damn door!  We took two-factor authentication to open the door (you must have the fob and you must perform the act of pushing the unlock button) and turned it into one-factor and then on top of that made the one factor something you both have and that can be queried without your direct knowledge.

I don't -- and won't -- own a vehicle equipped with such a "convenience" feature -- and that's why.  And what did we see this year? A demonstration.  Oops.

How many of the people reading this are stupid enough to have something like Alexa in their house?  Or a smart TV that responds to voice commands?

Oh, you say, it only records when you say "Heh Alexa" first?  How do you know that to be true, how do you know that the code in that device is secure and has neither a back door or a security problem that has allowed some malignant third party to turn the damn microphone on all the time?

You do know that the cops are testing the claim that Alexa (and Amazon) doesn't have that data, right?  Wanna bet on that?

What the hell is wrong with you?

The same thing that was and is wrong with the government, with the utility in Vermont and elsewhere -- you wish to have so much convenience that you simply don't give a good damn about the fact that you are leaving your front door unlocked and a big "steal my TV" sign in the window.

I've raised a ton of Hell about this over the years, going back to my days writing code for others as a wage slave.

It's a fight that's almost not worth writing about anymore -- except to post great big "Told You So" signs when your car is stolen or your fingerprints (which you can't change like a password, incidentally) are ripped off from the government.

And with that I leave this for the utility in Vermont:

smiley

View this entry with comments (registration required to post)
 

Folks, let's make this easy.

Everyone wants to talk about how Podesta's email was penetrated, or the rest of the DNC, or that the RNC, allegedly, was not.

All the screamers are (still) out about  "Russia" and similar.

Let me restate -- while Podesta's email was apparently broken into via a "spearfishing" email (one with a reset password link embedded in it that didn't go to the real site, but rather to the person who was trying to steal) and which he was dumb enough to click and then provide his current password the real issue here isn't about this sort of attack at all.

The real issue is about the idiocy of such "email" systems or the use of any other sort of cloud provider for anything secure in the first place.

Let me explain.

I run my own email here.  It would be trivial for me to lock it down so that even if you stole my password it would be worthless.

How?

Simple, really.  You see on the same network I have a VPN gateway that does not accept passwords at all.  It only accepts a certificate.  Such a SSL certificate is (nominally) intended to sign and encrypt private emails, and can also be used as a secure identifier for a VPN.  It is, effectively, the same thing a server uses to secure web communications but with a different set of "intended use" flags set (client authentication and digital signature rather than SSL server authentication.)

All I'd have to do is change the configuration on the email system slightly so that only accesses that came from connected VPN clients could connect at all.

Now you'd have to steal a device and if you did, it would only work until I knew it was stolen (and revoked the key.)  No other means of getting in would work even with the password.

It is literally a 15 second configuration change on my Dovecot and Exchange servers to do this, and it would not impact my ability to exchange email with others one bit.

Modern smartphones (including Android, IOS and BlackBerry 10 handsets) can all use these certificates for an IPSEC/IKEv2 connection.  Such a connection can be "nailed" open as well, active even on cellular, or activated "on demand" by the user.  Modern commercial and freely available operating systems (Windows 7/8/10, MacOS, Linux and FreeBSD) can also use same.  Doing so positively encrypts all traffic coming into or leaving said device.

Such a system is extremely secure because only authorized devices, secured with a cryptographic key loaded on them, can see the service in question.  An unknown key is refused by the VPN gateway as is one that has been revoked. Only trusted certificates (which are loaded on the host in a certificate store) can connect.  I use this facility with other services here at Ticker Central so I can have my laptop with me and use it "as if I was at home" even from half the world away on an insecure, or even known to be monitored data link.

The only way to get packets onto the "private" network from the outside and thus be able to "see" the email store is to connect to the VPN and establish a tunnel and the only way to do that is to have a trusted certificate on the device in question.  No certificate, no connection, no access, password or no password -- period.

This sort of facility is essential if you intend to allow remote access to services that are themselves of questionable security (or worse) such as, for example, Windows file shares.

So why didn't the DNC do this?

Because it takes more than 30 seconds of thought to do it and in addition it means not using email providers like Google -- you have to do it yourself, in-house, or all these security steps are worthless since your certificates and such have to be where someone else, who is unvetted, can get at them.

In other words they were stupid, and so have been the others.  They chose the equivalent of an unlocked front door for their house, and then are surprised when someone walks in and takes all the beer out of the fridge.

Oh, and all the guns and money in the house too, along with the nice widescreen TV!

Just remember folks that these are the very same people who claim to be smart enough to run the country.

PS: All the cloud providers are unlocked houses.  Always. They have to be in order for a cloud service to work; it's not a choice, it's an inherent part of any public "cloud" architecture. Claims otherwise are like putting a 25 cent TSA lock on your suitcase and calling it "secure."  The reason you have not and will not see this discussed in the media, especially the "business media", is that the minute this fact reaches the level of general knowledge all of said "cloud providers" have their stock prices collapse.

View this entry with comments (registration required to post)
 

2016-10-31 06:00 by Karl Denninger
in Technology , 291 references
 

Give me a break.

A task force of more than 30 major technology and communication companies said they have made progress but have not found a solution to eliminate "robocalls" or automated, prerecorded phone calls, but a top U.S. regulator urged faster action.

Throw some people in prison and you'll get their attention.  Yes, right here in the US, and yes, I'm talking about carrier executives.  Why?  We'll get to that:

Wheeler wrote major companies in July urging them to take new action to block robocalls, saying it was the top source of consumer complaints at the FCC. Scam artists often times based abroad try to appear to call from a bank or a government phone to trick consumers into disclosing confidential financial or account information.

How do they "appear" to call from a bank or government phone when they're not in the United States?

Ah, now see, there's the fraud and the US carriers are complicit in it.

Along with a call setup request (from one carrier to another) comes some information, which includes the "originating" number.  The carriers do exactly nothing to validate that for other than 800 (free to calling party) numbers.

But they could very trivially prevent, for example, foreign calls from appearing with US numbers.

How?  Refuse to route a call that comes from the UK unless the "originating" number is in the correct format including the country code prefixfor example.

That would stop instantly any of these calls that are originating outside of the United States.

As for those within the United States the FCC has jurisdiction, and can require that one of two things be the case:

1. The "originating" number be the actual originating number.  This will be the appropriate setting for all individual lines; simply do not allow an overridden number from a consumer account -- period.

2. For those that are overridden require, under penalty of law, that the party overriding accept both civil and criminal legal responsibility for the authenticity of their override under existing criminal fraud statutes.

There are very good reasons to allow such an override on outbound calls.  For example, at MCSNet we had outbound trunks that were all "rolled up" into high-capacity circuits (at the time DS1s); each of those trunks had a "real" phone number, but it was unpublished.  We then had DID mapping for certain people who needed "private lines" and in addition we had our "main" number (312) - 803-MCS1 that would ring into the PBX on the next available trunk in the group.  If you dialed out from our PBX those trunks (set up for bidirectional signalling) were configured to show 312-803-MCS1 as the "originating" number even though technically it was not.  That's fine, because we owned the originating number, it was "real", and it really was our number.

It would not be difficult at all to require that all such entities that purchase service from a telco provider in the United States and wish to provide "originating number" overrides do so under a contractual requirement, carrying criminal criminal penalties for lying, that any such number they put through be truthful and belong to the actual originating party of the call.

If you were to do this and at the same time hold carriers criminally responsible for accepting "foreign" calls that have originating numbers that violate the country code format of the originating nation, a software check they could easily implement, this problem would disappear instantly.

Of course there are "telco providers" (such as the SIP folks) that would scream about such a requirement -- but let's face reality here.  Enabling fraud as a business model makes you an accessory before the fact and recognizing that along with appropriate criminal sanction would go a long way to draining this swamp -- quickly and permanently.

Instead we "accept" a bunch of handwaving nonsense that comes from the FCC and various telcos.

View this entry with comments (registration required to post)
 

Main Navigation
MUST-READ Selection:
2016: What Was And a Preview of 2017

Full-Text Search & Archives
Archive Access

Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.

NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.

The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.