The ELF format is pretty common across various unix versions, having superseded previous binary formats such as a.out and COFF. Pretty much, today, if you see a unix binary then it’s probably ELF format.
One of features of the ELF format is that the run time linker can be smart about how it resolves dependencies, and this smartness can be tuned. A typical tuning many people know is the LD_LIBRARY_PATH variable, which can be used to add new directories to be searched for the needed libraries.
One of the major threats that companies are concerned about is “insider threat”. According to some Data Breach Incident Response (DBIR) analyses, insider threat may be the 2nd or 3rd major reason for data loss. It’s interesting to note that the insider threat is way down in the actual number of incidents, but they count for a larger number of successful data loss incidents because the insider knows where the data is, may have legitimate access to the data, and may know the controls that need to be bypassed to exfiltrate it.
A typical cloud engagement has a dual responsibility model. There’s stuff that can be considered “below the line” and is the responsibility of the cloud service provider (CSP) and there’s stuff above the line, which is the responsibility of the customer.
Amazon have a good example for their IaaS:
Where the line lives will depend on the type of engagement; the higher up the abstraction tree (IaaS->PaaS->SaaS) the more the CSP has responsibility.
The Siphonaptera has various versions. The version I learned as a kid goes:
Big bugs have little bugs, Upon their backs to bite 'em, And little bugs have lesser bugs, and so, ad infinitum. We make use of this fact a lot in computer security; a breach of the OS can impact the security of the application.
We could even build a simple dependency list:
The security of the application depends on The security of the operating system depends on The security of the hypervisor depends on The security of the virtualisation environment depends on The security of the automation tool.
There is a temptation in computer security circles to aim for the perfect. After all, we know that if there is a hole then it will be found and will be exploited. So we tend to build (hopefully! ahem OpenSSL) secure products that will withstand attacks… and then fail at usability
Let’s take a brief travel through…
Unix naming services NIS In the long distant past (the 1980s), Sun Microsystems created a system called NIS (Network Information Services)1.
There’s an old comment; “A Lie Can Travel Halfway Around the World While the Truth Is Putting On Its Shoes”. This came from a pre-internet world. Today a lie can travel around the world in seconds.
Personal annecdote Last year I broke the MBR on every hard disk on my home server. I was panicing. I really didn’t want to rebuild and restore from backup, and then re-rip all my DVDs; such a time sink!
Sometimes we can learn a lot from nursery rhymes; I’ve previously shown how A Hole In My Bucket can teach us about understanding problems and how this can lead to security issues.
The Itsy Bitsy Spider can also teach us…
So what is the story of the spider?
Spider starts to do something productive Event happens that destroys the progress Spider starts over to do something productive But what we don’t see, here, is the spider learning from the event.
Recently we heard news that the police had requested Alexa recordings to assist with a murder enquiry. The victim had an Amazon Echo and the police feel there’s useful data to be obtained.
This leads to speculation about what sort of information is recorded by these devices, and how secure are they?
What type of devices are we talking about? There are a number of devices out there these days which you can talk to, to request things.
This blog post is of a more practical nature, and may be of use for people at home who ssh into servers and then come back later to find their session disconnected. It might also help some people in offices with nasty firewalls!
Basically the scenario goes something like:
ssh into a server lock your screen, go away for a few hours come back, unlock your screen ssh session has been disconnected So how does this happen, and what can we do to stop it?
Have you tested your backups recently? I’m sure you’ve heard that phrase before. And then thought “Hmm, yeah, I should do that”. If you remember, you’ll stick a tape in the drive and fire up your software, and restore a dozen files to a temporary location. Success! You’ve proven your backups can be recovered.
Or have you?
What would you do if your server was destroyed? Do you require specialist software to recover that backup?
