Sex, Secret or God... Passwords

In the 1990's it was common to have to tell folks not to use "popular" password, like "sex", or "god", believe it or not even "password" and "secret".  Since then times have moved on, folks have become very adept at using other characters in their passwords...

Unfortunately, this is (very seriously) what one of our IT bods here has just found on a machine:

Props to the user for mixing in some numbers, a word and a symbol, however... We can all see the flaw in their storing the password.

(Thanks to our IT Manager for letting me use his picture - it is a lovely left hand, I wonder if he does hand modelling?)

C++14 std::memset Not Working?

When I say not working, I do not mean the function does not work, of course it works.  What I mean is that left to it's on devices the GCC compiler can actually chose to not perform a memset in certain circumstances, you can read more detail about this in the official bug list.

So, what's going on?  Well, I have a piece of code which uses a common buffer, each function locks a mutex (std::lock_guard), fills out the buffer and then transmits over USB to target devices, crucially I then want to clear the common buffer.

The purpose of this architecture is to keep sensitive information being transmitted through the buffer present for as little time as possible (i.e. the time between filling out and transmit, ~35ms) rather than filling out, transmitting and leaving the data in the buffer; as the time between calls may be anything up to 5 seconds, plenty of time for someone to halt the program and inspect memory dispositions.

In pseudo code therefore our sequence looks something like this:

COMMON BUFFER [256]
CLEAR BUFFER

USB CALL:
    FILL  BUFFER
    USB TRANSMIT
    std::memset(BUFFER, 0, 256);

In debug this worked no problems, all my soak testing worked, I was quite happy.

Until one switches to release, whereupon the GCC compiler can opt to optimise away calls which it defines as not having any noticeable effect.

In the case of the memset call here, to the compiler, locally sees nothing inspect the BUFFER variable after the memset is performed, it therefore decides nothing is bothered the buffer is cleared or not.

Of course we know the next call to any call, or the same call, will rely on the BUFFER being empty when it enters.

There are therefore two problems, if one had this code:

USB CALL:
    std::memset(BUFFER, 0, 250);
    FILL  BUFFER
    USB TRANSMIT
    std::memset(BUFFER, 0, 256);

You would of course pass all your tests, even in release, the buffer would work as expected, you could even assume no data is being left in RAM between transmit calls; you'd be dead wrong, but you can assume anything you like really.  No, what's happening here of course is that the lead-in memset is clearing the buffer before use, but the sensitive data is left in the buffer between calls as the latter memset is still being optimised away.

The code remains vulnerable to introspective intrusion attempts.

The real solution?  Well, I've gone with:

USB CALL:
    std::memset(BUFFER, 0, 250);
    FILL  BUFFER
    USB TRANSMIT
    std::memset(BUFFER, 0, 256);
    auto l_temp(buffer[0]);
    buffer[0] = buffer[1]
    buffer[0] = l_temp;

Whatever you do to solve this, don't spend a whole day as I just have.

In conclusion, of course the call works, it's the compiler which is optimising the call away.

Administrator : Blocking Spammers & Hackers (Basics)

To see whom has been trying to connect to your Debian (or Ubuntu) server, use:

cat /var/log/auth.log | grep "Failed"

This will list out the failed attempts, then add the successful with:

cat /var/log/auth.log | grep "session opened" | grep "LOGIN"

You can note the IP addresses for the unwanted attempts and block them with iptables, like this:

sudo iptables -I INPUT -s AAA.BBB.CCC.DDD -p tcp --dport ZZZ -j REJECT

Where the IP to block is "AAA.BBB.CCC.DDD" and the port is "ZZZ" as a number, so to block 192.168.0.1 on port 7000 you would do:

sudo iptables -I INPUT -s 192.168.0.1 -p tcp --dport 7000 -j REJECT

Instead of REJECT you can use DROP, and in place of tcp you can use udp and icmp protocols.

To block a whole subnet range I just do this:

sudo iptables -A INPUT -s AAA.BBB.CCC.000/AAA.BBB.CCC.255 -p tcp --dport ZZZ -j DROP

This makes all addresses in the range not respond, the range could have been 192.168.0.0/192.168.0.255, or you could block higher up the range like this 192.168.0.0/192.160.255.255, the first address range blocks just the last section subnet mask, the second blocks the last two sections of the subnet mask!

You can view the iptables in use with:

sudo iptables -L

Why Does This Exist?

Its not often I have to actually turn a server towards the outside world, my personal servers usually sit on my LAN and never route to the internet, like-wise the items I provision in the office are for internal use...

Yesterday however, I had the pleasure of being told to make a service available to the outside world...

No big deal, it's Apache2 on a Ubuntu host, set up done... And I only opened port 80 then left it... All was fine...

It has run for six hours... six... On a brand new acquired IP address, no-one but the recipient at the far end knows about the server being there, it has no DNS entry, it has no other services, just port 80 and ssh open...

Yes, I have had hacker, poking, security breach attempts from China, Vietnam, the British Virgin Islands, Canada, the Netherlands and Russia...

The mind boggles at quite how much hacking and infiltration is going on out there...

I've been checking the mainly ssh breach attempts with the command:

cat /var/log/auth.log | grep "Failed"

I run this to a file and then have a python script to log the IP addresses into a table for me, and I can then just block them individually or as a subnet range, though iptables.

I also check for successful logins just in case with:

cat /var/log/auth.log | grep "session opened" | grep "LOGIN"

I wonder however whether a python script to manage all this for me might be in order... Hmmm, project time!