Ladies and gentlemen, it was a good day.
The phone rang at home.
After a recorded message that alleged that computer activity at my location (not specified, naturally) would somehow be critically noted by Apple (with which I do not have any subscription relationship), a list of phone system choices were enumerated. I chose the "staff operator" option, hoping for further indications that it was a phony pitch. As I suspected, a live Indian voice alleging computer problems at my location began some lame but vaguely threatening story, so I loudly and rudely interrupted with:
Me: "Are you reporting virus activity?! If so, give me a type or a sub-type!!"
India guy: "Um, no, your..."
Me: "Is this a NETWORK ISSUE, a MOBILE ISSUE or a DESKTOP ISSUE?!"
India guy (attempting a more aggressive stance): "Um, no, Sir, this regards your Apple ID - "
Me: "DO YOU HAVE A TRACKING NUMBER? DO YOU HAVE A DISCOVERY DATE? WHAT ABOUT ANY O.S. VERSIONS?"
India guy, louder: "Sir, your Apple - "
Me, very loudly: "I DON'T HAVE AN APPLE ID, YOU IDIOT!!! (bellowing now) HOW IS THE VIRUS CLASSIFIED?!!!"
He mysteriously hung up. Most fun I've had in years.
Any systems analyst, devops management bigwig or network security professional would have been able to give some specific observation if there was really a problem, and would have done so confidently. Funny how that didn't happen.
Nobody calling you cold has any idea what computer activity is happening at your location. These are at best telemarketers, and at worst, criminals. Have a little fun with them!
Saturday, April 21, 2018
Sunday, April 8, 2018
The Galesburg, Illinois Hack
The below link provides the first coverage I've seen of a break-in just uncovered that happened during the 2016 US elections regarding several Illinois towns not of large but of average size. Mostly involved is Galesburg, in far western Illinois about halfway between Chicago and Des Moines, Iowa. The county seat of Knox County, it has a population of about 32,000, making it not Wall Street or Sunset Boulevard but plain old ordinary whitebread middle America. Here's the story link:
Eric Shawn Story
The story indicates that Homeland Security found connections to voter registration computers in Galesburg through servers in the Netherlands operated by a Russian entity called the GRU. Notice that that isn't the FSB (the modern descendant of the famous KGB, which was the Soviet near-equivalent of the CIA). FSB is a civilian agency that would be the usual candidate for infiltration of foreign elections (see the Christopher Andrew books "The Sword And The Shield" and "The World Was Going Our Way" for data on that). But this time it's apparently Russian military intelligence, which is what (in Russian) GRU stands for. That would be a rough equivalent of our DIA, or Defense Intelligence Agency, probably adding the duties of our NRO (National Reconnaissance Office) which operates observation satellites and NGA (National Geospatial-Intelligence Agency), basically a huge combat cartography service.
There are two things to note here (beyond a timely reminder that as far as we know, no votes in any American election have been changed by any foreign state-sponsored operator). First, it's interesting that GRU is doing their own work as opposed to relying on another Russian agency for it. It could be that GRU doesn't trust FSB to give them accurate or complete material. So it's not just that there's a problem with Russia being interested in election activity in the US (along with many other allied and opposed countries, I'll guess). There could be a problem with multiple unrelated Russian entities that do their own intelligence gathering due to interagency competition like you see from time to time in the Pentagon. That could have many implications for catching these types in that one may see unrelated but current Russian signatures because one isn't looking at one Russian group but in fact at two or three separate ones.
Second, it's noted but not trumpeted in the story that what got broken into were computers holding voter registration records, not computer-based voting machine systems. There were earlier such stories; the Galesburg story is the latest. This indicates that the particular risk here was not about votes being changed, but about the risk of the list of registered voters being subject to deletion, addition or alteration as well as exfiltration. That last refers to downloading or copying the list for later action, which is apparently all that DHS thinks happened.
Regardless, the exposure is that local government systems are not the most closely guarded or up-to-date systems anybody has, and any interested party foreign or domestic has some chance to break in. If indeed no votes have been changed in any local, county, state or national election (as with courthouse fires in olden times), I must credit airgapping of networks and individual computers that are known risks, and can't be replaced or upgraded due to lack of funds. The plan might be "if they're protection risks just don't network them". That would be a good, cheap form of firewalling that would interest a manager with no budget. I mean, if these devices are still running 386 processors and Win2K, would you get on the internet with them?
Eric Shawn Story
The story indicates that Homeland Security found connections to voter registration computers in Galesburg through servers in the Netherlands operated by a Russian entity called the GRU. Notice that that isn't the FSB (the modern descendant of the famous KGB, which was the Soviet near-equivalent of the CIA). FSB is a civilian agency that would be the usual candidate for infiltration of foreign elections (see the Christopher Andrew books "The Sword And The Shield" and "The World Was Going Our Way" for data on that). But this time it's apparently Russian military intelligence, which is what (in Russian) GRU stands for. That would be a rough equivalent of our DIA, or Defense Intelligence Agency, probably adding the duties of our NRO (National Reconnaissance Office) which operates observation satellites and NGA (National Geospatial-Intelligence Agency), basically a huge combat cartography service.
There are two things to note here (beyond a timely reminder that as far as we know, no votes in any American election have been changed by any foreign state-sponsored operator). First, it's interesting that GRU is doing their own work as opposed to relying on another Russian agency for it. It could be that GRU doesn't trust FSB to give them accurate or complete material. So it's not just that there's a problem with Russia being interested in election activity in the US (along with many other allied and opposed countries, I'll guess). There could be a problem with multiple unrelated Russian entities that do their own intelligence gathering due to interagency competition like you see from time to time in the Pentagon. That could have many implications for catching these types in that one may see unrelated but current Russian signatures because one isn't looking at one Russian group but in fact at two or three separate ones.
Second, it's noted but not trumpeted in the story that what got broken into were computers holding voter registration records, not computer-based voting machine systems. There were earlier such stories; the Galesburg story is the latest. This indicates that the particular risk here was not about votes being changed, but about the risk of the list of registered voters being subject to deletion, addition or alteration as well as exfiltration. That last refers to downloading or copying the list for later action, which is apparently all that DHS thinks happened.
Regardless, the exposure is that local government systems are not the most closely guarded or up-to-date systems anybody has, and any interested party foreign or domestic has some chance to break in. If indeed no votes have been changed in any local, county, state or national election (as with courthouse fires in olden times), I must credit airgapping of networks and individual computers that are known risks, and can't be replaced or upgraded due to lack of funds. The plan might be "if they're protection risks just don't network them". That would be a good, cheap form of firewalling that would interest a manager with no budget. I mean, if these devices are still running 386 processors and Win2K, would you get on the internet with them?
Tuesday, January 16, 2018
Hypothesis
The "Meltdown" and "Spectre" vulnerabilities are currently making the news and fixes are being fielded as I type. There is an impression that these processor-centric problems are not fixable. Well, kinda. I'll (at the risk of looking uninformed if you compare my picture here to CERT or somebody) offer a grossly simplified explanation. Bottom line, though, is UPDATE EVERYTHING. It's a software issue, at least immediately.
The kernel of any operating system is the internal part of it (be it Windows, Linux, CP/M, whatever - everything has a kernel)... the "guts" part that handles matters more fundamental than human interaction. It has three jobs: file system management, memory management and CPU scheduling (the "job stack"). That second matter about managing memory is key for the current issues. A kernel knows details about how the physical processor (or cloud simulation thereof) arranges physical memory and the kernel itself is what decides what and how much memory goes to this process, that application or that other cron job when fired.
Suppose - just suppose - that the Bad Guy could stick a virus (surreptitious unauthorized kernel module in this case) into a kernel. That would in theory give the ability to this virus/worm/nasty to eavesdrop upon exactly what memory locations a particular interesting process was using, as well as the ability to look into those locations and see (before wipe) if any data is left there after the process happens. If the nasty finds data, it could then copy it and send it to the IP address of Nasty Person Central, at least if network-capable and if sensing any usable connection to the outside world. Which would be a good bet.
Processor redesign could make this crack harder but will take months or years to put into the plans of all the chip makers. Software changes are possible quickly though, and are being rolled out now and will continue to be developed for months. The action plan:
1. DO ALL BACKUPS IN CASE PATCHES BREAK SOMETHING.
2. RESEARCH AND FIND PATCHES FOR YOUR STUFF.
3. WARN DOWNSTREAM USERS OF MAINTENANCE TIME WINDOWS BEFORE THEY HAPPEN.
4. PATCH ALL OPERATING SYSTEMS AND APPLICATIONS THAT MAY BE AFFECTED BY MEMORY EXFILTRATION PROBLEMS.
5. Follow authorities like the common vulnerabilities page and NixCraft for the latest news and workarounds.
The kernel of any operating system is the internal part of it (be it Windows, Linux, CP/M, whatever - everything has a kernel)... the "guts" part that handles matters more fundamental than human interaction. It has three jobs: file system management, memory management and CPU scheduling (the "job stack"). That second matter about managing memory is key for the current issues. A kernel knows details about how the physical processor (or cloud simulation thereof) arranges physical memory and the kernel itself is what decides what and how much memory goes to this process, that application or that other cron job when fired.
Suppose - just suppose - that the Bad Guy could stick a virus (surreptitious unauthorized kernel module in this case) into a kernel. That would in theory give the ability to this virus/worm/nasty to eavesdrop upon exactly what memory locations a particular interesting process was using, as well as the ability to look into those locations and see (before wipe) if any data is left there after the process happens. If the nasty finds data, it could then copy it and send it to the IP address of Nasty Person Central, at least if network-capable and if sensing any usable connection to the outside world. Which would be a good bet.
Processor redesign could make this crack harder but will take months or years to put into the plans of all the chip makers. Software changes are possible quickly though, and are being rolled out now and will continue to be developed for months. The action plan:
1. DO ALL BACKUPS IN CASE PATCHES BREAK SOMETHING.
2. RESEARCH AND FIND PATCHES FOR YOUR STUFF.
3. WARN DOWNSTREAM USERS OF MAINTENANCE TIME WINDOWS BEFORE THEY HAPPEN.
4. PATCH ALL OPERATING SYSTEMS AND APPLICATIONS THAT MAY BE AFFECTED BY MEMORY EXFILTRATION PROBLEMS.
5. Follow authorities like the common vulnerabilities page and NixCraft for the latest news and workarounds.
Sunday, November 26, 2017
Always Nice To Remember...
When indulging in virtualization, recall that this practice (as opposed to using real computing with hardware) introduces at least three new categories of concern:
PROVIDER HYPERVISOR ISSUES
PROVIDER WEB INTERFACE ISSUES
PROVIDER PERSONNEL ISSUES
You will notice the repetition of the term "provider", since one definition of "cloud" is "renting someone else's box and network".
The first area is one I recall from a previous project in which we saw time delays in patching hypervisor vulnerabilities, which never happen except when they do. Hypervisors are the software programs that create and manage the virtual computing instances "living" on the real host. Ideally they prevent a user on one instance from getting into others, into the host, into the host's network, and so forth.
The second area I recall from the same project, which would not only bring up injection vulnerability but simple operations faults, like not providing a necessary choice menu or button, or having that control work improperly. There's also the issue of the interface's throughput capacity.
The third area notes that by using a provider for virtual needs (if that's what you're doing rather than running the host in your own co-lo arrangement), you go through a layer of employees and management you've never met and do not control.
.....
So yes. We sometimes don't recall these issues in the way they were first commonly discussed. And as we move forward, fewer will think of them and they'll become more important. Witness the youngsters we see referring to any device connection as "wifi", since soon they may not remember ethernet, being told of it only by somebody else who fixes something for them.
PROVIDER HYPERVISOR ISSUES
PROVIDER WEB INTERFACE ISSUES
PROVIDER PERSONNEL ISSUES
You will notice the repetition of the term "provider", since one definition of "cloud" is "renting someone else's box and network".
The first area is one I recall from a previous project in which we saw time delays in patching hypervisor vulnerabilities, which never happen except when they do. Hypervisors are the software programs that create and manage the virtual computing instances "living" on the real host. Ideally they prevent a user on one instance from getting into others, into the host, into the host's network, and so forth.
The second area I recall from the same project, which would not only bring up injection vulnerability but simple operations faults, like not providing a necessary choice menu or button, or having that control work improperly. There's also the issue of the interface's throughput capacity.
The third area notes that by using a provider for virtual needs (if that's what you're doing rather than running the host in your own co-lo arrangement), you go through a layer of employees and management you've never met and do not control.
.....
So yes. We sometimes don't recall these issues in the way they were first commonly discussed. And as we move forward, fewer will think of them and they'll become more important. Witness the youngsters we see referring to any device connection as "wifi", since soon they may not remember ethernet, being told of it only by somebody else who fixes something for them.
Sunday, October 22, 2017
Go To The PUB
Here's my latest mnemonic which will make me rich, or not.
"Go to the PUB."
Although this is supposed to be a Linux blog, I often dip into questions of general computer security. I've been annoyed over the state of such matters, since zero-day exploits seem to be discovered daily or hourly. Cloud hypervisor weakness, DNS fakery, programmers forgetting to tell fields not to take nasty input (or the dev project not giving them time for testing in order to find and eliminate those instances - not to mention documentation)... wait a minute. What if I concentrate on the positive? What can we do that'll work?
P - use complex passwords and change them often.
U - perform updates and patching on all systems and applications, testing update or patch on a nonproduction box where feasible.
B - do backups at least of critical systems, file systems, configurations and settings.
My very basic list does not take the place of all other kinds of due diligence and due task completion. If a user or employee leaves, disable that account right now. Don't use any default passwords or configs on anything. Don't put info useful to the bad guys on the company website and don't let employees put same on their LinkedIn or Facebook pages. And so on. But use my mnemonic to keep the three biggies (according to me) always in mind:
Passwords. Updates. Backups.
End of file.
Thursday, June 15, 2017
A way they can drain your bank account - and a way they CAN'T
I caught this article that was referred to readers by PenTesting Magazine and originally came from The Register in the UK:
After Years Of Warnings...
It's about the protocol flaw that allows crook #2 to insert into financial transaction flows the logon/password/whatever information stolen from crook #1, who got the info from laptops, phones or desktops harboring the malware 'bots in crook #1's net. However, it occurred to me that although some bank customers would be vulnerable to the arrangement, there may be others that would not be. So I dropped by a local bank.
I described the situation in as-non-technical-as-possible terms and asked the loan official if it was plausible for customer immunity to result from a particular circumstance. An SS7 protocol vulnerability plus knowledge of logon credentials for an online banking account gives two crooks the opportunity to craft communication that looks like a request from the real customer for money. All one needs is the credential (or credential group) and the protocol hack (which the involved standards committee may spend months closing). But what if the list that crook #2 bought from crook #1 does not contain the credentials of customer X? Then customer X is immune.
How would this happen? The "harvester" malware operated by crook #1 looks for whatever it can find. If a particular customer, say 88 years old who's never set up an online banking profile, does business with checks, debit cards, credit cards, cash, whatever old fashioned way... then that customer would never have set up credentials with which to log onto any https site from the bank.
The loan official agreed that the lack of that information in the account holder's profile would be a problem for crooks since you can't steal what isn't there. I told her that I was interested to hear that, since the case of a customer that had not established an online profile with a financial institution described me as well. I like many types of technology but not the particular one being discussed. That's just me.
We also determined that fraud control software could possibly save the day, at least in the US for now. German banks have been seeing some successful attacks of the above type for a few months, but if the attack comes here (the US) from there, FC software might be able to tell from IP addresses that the malevolent request IP's don't match IPs from which the customer typically communicates. If it's smart enough to do that, it may even protect from attacks through closer servers in country (as well as apply contextual comparisons like 'why would a blind person buy a motorcycle?') At that point the bad guys experience something like
--- Interfere with transaction / Put up error message PLEASE CONTACT YOUR INSTITUTION / Write log entry / Run tracking script / Email admin --- .
After Years Of Warnings...
It's about the protocol flaw that allows crook #2 to insert into financial transaction flows the logon/password/whatever information stolen from crook #1, who got the info from laptops, phones or desktops harboring the malware 'bots in crook #1's net. However, it occurred to me that although some bank customers would be vulnerable to the arrangement, there may be others that would not be. So I dropped by a local bank.
I described the situation in as-non-technical-as-possible terms and asked the loan official if it was plausible for customer immunity to result from a particular circumstance. An SS7 protocol vulnerability plus knowledge of logon credentials for an online banking account gives two crooks the opportunity to craft communication that looks like a request from the real customer for money. All one needs is the credential (or credential group) and the protocol hack (which the involved standards committee may spend months closing). But what if the list that crook #2 bought from crook #1 does not contain the credentials of customer X? Then customer X is immune.
How would this happen? The "harvester" malware operated by crook #1 looks for whatever it can find. If a particular customer, say 88 years old who's never set up an online banking profile, does business with checks, debit cards, credit cards, cash, whatever old fashioned way... then that customer would never have set up credentials with which to log onto any https site from the bank.
The loan official agreed that the lack of that information in the account holder's profile would be a problem for crooks since you can't steal what isn't there. I told her that I was interested to hear that, since the case of a customer that had not established an online profile with a financial institution described me as well. I like many types of technology but not the particular one being discussed. That's just me.
We also determined that fraud control software could possibly save the day, at least in the US for now. German banks have been seeing some successful attacks of the above type for a few months, but if the attack comes here (the US) from there, FC software might be able to tell from IP addresses that the malevolent request IP's don't match IPs from which the customer typically communicates. If it's smart enough to do that, it may even protect from attacks through closer servers in country (as well as apply contextual comparisons like 'why would a blind person buy a motorcycle?') At that point the bad guys experience something like
--- Interfere with transaction / Put up error message PLEASE CONTACT YOUR INSTITUTION / Write log entry / Run tracking script / Email admin --- .
Friday, April 7, 2017
DRaaS
Software as a service, Platform as a service, Infrastructure as a service… might as well list Accounting as a service, HR as a service, Security as a service, Programming & Development as a service, Service as a service (actually that last isn’t a joke, as Customer Support has been offshored for many organizations now)… can every business process be outsourced or commoditized? I don’t know but I know that I haven’t seen much new – or old – in the service economy that compelled me to conclude that the benefits outweighed the hazards of paying outside sources for everything. But there may be a category now that makes more sense than many: Disaster Recovery as a Service.
Cloud providers can give you a rented virtual (and often the additional choice of rented physical) infrastructure. You can rent online storage for backups. You can dispense with information technology staffing by hiring server admin companies on an as-needed basis (I don’t recommend that but it’s a widespread practice). You can hire security experts as needed, hopefully before they’re needed. But what if there was a way to combine solutions for many of these needs into one strategy? As I understand it, Disaster Recovery as a Service uses a massive backup as a fix for not just hardware failure or power loss, but for many things this side of ddos mitigation (or other problems outside your network). One particular company with a booth I saw at a recent security conference appeared to work like Carbonite backup, except for your whole network inventory. All nodes (desktops, laptops, workstations, servers) plus all network devices like routers and switches are “cloned” at the provider’s data center. This idea stores not just data backups but whole operating system builds, with users, desktop environments, configurations, applications and stray documents. And in the network devices, all the addresses, routings, rules, configs and system versions are included. These are (in this particular company’s instance) not just snapshots restricted to one point in time, but constantly updated “clones” of All The Things.
A “Carbonite for your whole shop” approach would, as described here, seem to rely on lots of bandwidth to do all the constant updating (plus think cost for that in addition to network capability matters). Also, the securing of the connection to the provider location or cloud introduces an issue. The defense stance of the provider data center itself would constitute another. After all, grabbing backups has already proven profitable to criminals worldwide, who didn’t have to frontally attack a victim’s main arrangements. But there’s also promise in the approach. When your hardware and connectivity become ready after an event, you could come back from fire, flood, tornado, hurricane, earthquake, physical strikes like an eighteen-wheeler smashing through your office wall, node breakages induced by Windows Update, System Update or the like, worm damage, maliciously encrypted data blackmail and most problems related to geographical location (sinkholes?).
I can see potential challenges here with cost, security and network capacity. But if these can be handled then DRaaS is a new approach that could overtake legacy methods of the old offsite backup, reliable as it is. I’ll be watching the market for this product class with great interest.
Cloud providers can give you a rented virtual (and often the additional choice of rented physical) infrastructure. You can rent online storage for backups. You can dispense with information technology staffing by hiring server admin companies on an as-needed basis (I don’t recommend that but it’s a widespread practice). You can hire security experts as needed, hopefully before they’re needed. But what if there was a way to combine solutions for many of these needs into one strategy? As I understand it, Disaster Recovery as a Service uses a massive backup as a fix for not just hardware failure or power loss, but for many things this side of ddos mitigation (or other problems outside your network). One particular company with a booth I saw at a recent security conference appeared to work like Carbonite backup, except for your whole network inventory. All nodes (desktops, laptops, workstations, servers) plus all network devices like routers and switches are “cloned” at the provider’s data center. This idea stores not just data backups but whole operating system builds, with users, desktop environments, configurations, applications and stray documents. And in the network devices, all the addresses, routings, rules, configs and system versions are included. These are (in this particular company’s instance) not just snapshots restricted to one point in time, but constantly updated “clones” of All The Things.
A “Carbonite for your whole shop” approach would, as described here, seem to rely on lots of bandwidth to do all the constant updating (plus think cost for that in addition to network capability matters). Also, the securing of the connection to the provider location or cloud introduces an issue. The defense stance of the provider data center itself would constitute another. After all, grabbing backups has already proven profitable to criminals worldwide, who didn’t have to frontally attack a victim’s main arrangements. But there’s also promise in the approach. When your hardware and connectivity become ready after an event, you could come back from fire, flood, tornado, hurricane, earthquake, physical strikes like an eighteen-wheeler smashing through your office wall, node breakages induced by Windows Update, System Update or the like, worm damage, maliciously encrypted data blackmail and most problems related to geographical location (sinkholes?).
I can see potential challenges here with cost, security and network capacity. But if these can be handled then DRaaS is a new approach that could overtake legacy methods of the old offsite backup, reliable as it is. I’ll be watching the market for this product class with great interest.
Subscribe to:
Posts (Atom)