Category Archives: Uncategorized

Sorry for the Insecure Passwords…. NOT….

Oh brother, here we go again…

Creator of NIST Password Rules Apologizes

There is a common thread, ALWAYS, when discussing passwords, particularly length, complexity, value.

There are a couple of reasons this is generally all bunk and the author of NIST Special Publication 800-63. Appendix A, does not have that much to apologize for.

First, some truth.

The information about passwords in the NIST publication was already dated when it was published in 2003. The author, Bill Burr, does have to apologize for that.

But not much else.

Secondly, some fact.

The people, almost *always* complaining about password rules and looking for any excuse not to follow them are usually people who don’t understand the science and math surrounding them. While people can recognize obvious bad passwords, good ones are actually much harder to spot, because good passwords have one thing in common, they are complex combinatorically.

Bet you never heard that word before… more on Combinatorics later…

Next, an unfortunate but all too natural phenomena of iteration, evolution and progress.

Lastly, before the boring stuff, there is no such thing as a secure anything. Security is a state, which changes from time period to time period and evaluated based on prevailing threats with some measure of risk assessment for both the known… and unknown threats.

So, by definition, there are no permanently secure passwords (or permanently secure anything).

Given enough time, tools, power, situation, opportunity (and opportunity cost), vulnerabilities, a little luck and desire, everything is crackable.

With that in mind, any advice on secure passwords WILL only be valid for a certain period of time.

So there is absolutely no excuse in not following that advice, it doesn’t really matter how you feel about it or how lazy your fingers are, with the knowledge that it is going to change at some later date.

This phenomena is generally a result of changes in technology and more importantly changes in the prevailing tactics used to get around it.

For example, in the 1970’s when everyone is using birthdates as passwords, once attackers know this is common, they proceed trying passwords with birthdates. Next, people start using the recommendations in the NIST 800-63 publication (which is 1980’s circa advice, despite it being published in 2003). So the attackers now know the majority of sites use these recommendations… and adjust their method of attack to include the NIST 800-63 recommendations.

This is natural, there is nothing you can do about it.

This is iteration. Next, evolution…

Cracking passwords takes time, the harder a password is to crack, the more time it takes. Of course, if it takes 100,000 years to crack a given password… that is a good password, why? Because you are likely to be dead for 99,900 years by the time it gets cracked and your bank account is long gone.

However, computer power increases periodically, thus, the time to crack a passwords shrinks. In addition, sometimes weaknesses are found in password encryption algorithms and that further shortens the time to crack them. This is evolution, these things can’t be stopped.

Ok, so let’s bring this all home.

At the heart of this discussion for passwords is Combinatorics. In math, combinatorics is the science of “Countable Discreet Structures”. Put in English… the study of counting sets of thing used in combination (i.e. If I have 3 objects, an apple, an orange and a banana, how many ways can I order them as a list of three items [Apple,Orange,Banana], [Orange,Apple,Banana], [Orange,Banana,Apple]… etc.

As the set of things grows and the number of items in the list also grows, this increases entropy (in English, the number of combinations).

Thus, low entropy sets are easy to crack, high entropy sets (or longer lists with more things I can use in each place in the set), gets progressively harder to crack. At some point, it gets so hard, the set of objects and length of the list becomes at first, exponentially large and if I keep going increasing either or both, geometrically hard. Randomness adds to entropy, but reality is, passwords are not truly random (even when using online password managers that supposedly generate random passwords). Computers don’t have a “random” anything, scientifically speaking, computers are only “pseudo random”. Plainly, randomness in computers starts from a set of initial conditions and iterates through an algorithm which creates a progressive random sequence of numbers. Thus, if you know the initial conditions and the algorithm, you can calculate the sequence of numbers, despite the sequence being random.

This is the goal for picking relatively secure (although realistically, temporally secure passwords), pick exponentially or geometrically hard to crack passwords; passwords with high entropy.

So here is the kicker, this still isn’t good enough… why… search space. If my set of objects is known (which it is, keys available to me on a keyboard) this is part of the space of objects an attacker can search through, then the only mystery is the length of my string of characters in the password. To make matters worse, if an attacker knows the limits of what I can use for a password, for example, some websites only allow for letters and numbers, it tells the attacker how s/he can further narrow the possibilities of what my passwords could be. Knowing corporate policy on passwords is also useful and clearly, if nearly everyone is following the recommendations of NIST 800-63, the attacker has even more advantage.

So even geometrically complex passwords can have weaknesses based on policy, prevailing trends, technically imposed limitations and available pools of characters.

So this is why you hear people say “passwords are useless and irrelevant”. Of course, this is all hogwash. They are not useless, they are only useless if you set them once and never change them, once they become an immobile target, time is on the attackers side for all the outlined reasons, changes in computer power, some predictability in the search space and the fact that the password isn’t really random. Cries that passwords are dead, “long live passwords”, are merely the cries of lazy ignorant people with no insight into what makes for a good password, it is literally like someone shouting “fire” in a crowded theater… it’s irresponsible.

So the best strategy is…

  1. Understand passwords requirements (or authentication methods in general) are going to change over time.
  2. Follow the prevailing advice on authentication methods… and maybe add some personal flair so your methods aren’t exactly the same as everyone else’s.
  3. Pick passwords that have some amount of complexity (i.e. higher entropy).
  4. Follow this simple rule, using longer passwords means you can change your passwords less often, shorter passwords means you will have to change much more frequently. But as a rule, you must change them at some point, hopefully on a regular basis.
  5. Where you can, use 2-factor or multi-factor options.

What really seals the deal on decent passwords is 2-factor authentication (aka 2FA). You should still periodically change your passwords even with 2 factor, but with it, you have significant leeway on how often and when. If anything, 2FA should appeal to the laziest people.

Of course, this is a complex topic, authentication in general that is. There are many other discussions and arguments that can be made here surrounding it. Suffice it to say, this information above is not wrong, although it may be open to interpretation. That being said, it’s still, presently, sound advice.

Alternatives to FTP (or How I Stopped Worrying and Loved The SSH)

Forgive the Dr. Strangelove reference, but sometimes life around here is just as bizarre as the world of that movie.

With the final closing of the second of the 4 fatal protocols, namely FTP (and formerly Telnet, can you guess the 3rd & 4th?) Here is a quick meditation on how FTP is just no longer required and there is an AWESOME alternative… if you are just willing to open your mind a bit.

Since SSH provides three major features, encrypted communications, encrypted sign-in and built-in second factor authentication, what is there NOT to love about SSH?

The direct replacement for FTP via SSH is of course, SFTP. Certainly you can use SCP to, but for the moment, lets stick with SFTP as we are really talking about replacing FTP here. Also, this discussion focuses on Unix/Linux and even MacOS X. Windows on the other hand, is a separate story.

Your first response might be, “but allowing SFTP gives people implicit access to the SHELL”. I am sorry to tell you this… but horse-dinky. At least, horse-dinky for OpenSSH 4.9 and up (7.2 is the current stable release). Other SSHD server’s your mileage may vary.

A side note, as some will note, years ago, I said of OpenSSH, “…I wouldn’t give it to my worst enemy… well… maybe my worst enemy, but no one else.” Back in the day, OpenSSH was a total wreck, but after some soul searching… and the fact that the majority of the flaws came from one programmer and OpenSSH itself went full hog into auditing this guy’s code… it’s been pretty stable since.

Having said that, don’t download, compile and install SSHD on your own. Get it from a Package Manager or at least use one supported by whoever your vendor is. Why? Well, given OpenSSH’s track record and continued footprint around the world, it will always be under attack and you want to be sure your updates to it are automated and not have to think about it.

For SSHD implementations that do not have the correct feature set, there is “scponly”, https://github.com/scponly/scponly/wiki. But I wouldn’t recommend it if you can avoid it.

Ok, the meat… SSHD has two wonderful features that many people are not aware of.

  1. A flag called “ForceCommand”
  2. Pattern Matching and Conditional Processing in sshd_config

With these two features, you can limit users or groups to SFTP only and deny them access to the shell. A pro tip though, I would still also set the user’s account to “noshell” or “/bin/false” just for safe measure (see “man chsh” on your computer of choice for that). If you have other protocols enabled like… gack… telnet, rlogin, rsh or any other one that requires a user account but no shell access, then do this anyway. (btw, Friends don’t let friends deploy telnet, rlogin or rsh and if you do use them… shame on you…)

The totally cool part is, not only can you limit an individual user or group, the matching and conditional processing in sshd_config allows you to limit where they come from, what commands they use, Change their root and set a whole lot of SSH settings just for them.

Ok, here are a few examples… Let’s limit the user “bob” to SFTP only, in /etc/ssh/sshd_config (or wherever your SSHD config is located), I would append the following..

Match User bob
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

In this example, conditional processing will match Bob’s username and execute the commands under the match statement. In this case, we Chroot to Bob’s “%h” (aka Home directory), so he can only save to his home folder. We also here, limit him to SFTP and we limit his ability to use SSH to forward himself around to other places or create tunnels. Literally, we tell SSHD, SFTP to this folder ONLY.

Let’s say Prof. Rob has students that need to submit homework assignments. Yes, Prof. Rob could use one account, a service account, for this… while this is very much like anonymous FTP, it is highly not recommended. Instead, we create a user for each student, student1 through student230 (it’s a big class). We create a group, “PHY222” and add all the users to this group.

Then we create a folder in Prof. Rob’s home (or anywhere else to be honest), called, “Phy222Homework”. Chown it to “chown rob:PHY222 Phy222Homework”, then Chmod it to “chmod u=rwx,g=rws,o-rwx Phy222Homework”. Finally, create folders under “Phy222Homework” named after the users.

Again, add to the bottom of /etc/ssh/sshd_config…

Match Group PHY222
ChrootDirectory /home/rob/Phy222Homework/%u
ForceCommand internal-sftp
AllowTcpForwarding no

Effectively, each user can place files only in his/her sub folder in Prof. Rob’s Phy222Homework folder and has no shell access.

You can do this as outlined, for letting people place webpages in folders under a webserver, skies the limit here.

Now…, do you want to turn it up to “11”.

SSH has built-in two factor authentication… sort of… but still, awesome despite it being “sort of”. SSHD allows the use of self-generated keys. Basically, you (or the admin for your server) generates a key and then places a checksum of the key in file named “authorized_keys” in the “.ssh” folder in your home directory. You can also place the key there so that you can use it to access other systems, but that is a post for another time. The key, can either have a password… or not.

As matter of policy, your keys should have passwords, I can’t stress that enough. I won’t even address having keys with no password here.

The beauty of a key with a password is this, when you type in the password to authenticate, it unlocks the key. The key, then becomes your password effectively. So when you log into an SSH server, the password used to unlock the key never travels across the network. This… is… huge… because there is now, no password moving across the network that can be captured and the key itself is never revealed because anything encrypted with it, is decrypted at the other end using the hash in the “authorized_keys” file or via a negotiated key using the hash as a key.

Which, I should mention, never never never ever, exchange a key or key-hash with a user via email or any other insecure method that could be intercepted. If you do, consider the key worthless. I would recommend that keys are either distributed over authenticated and encrypted channels or in person via a portable media (like a flash drive).

You can generate OpenSSH keys on a Unix/Linux/MacOS X systems with ssh-keygen (see the man pages) and on Windows PC’s using PuTTY’s puttygen.

The key thing to remember with “puttygen” is that it saves the hash (and key) in a PuTTY format. You must use the export menu option to export it to an OpenSSH recognized format. The hash, can be lifted from the main window. The output window visible when you generate a key contains the hash in a format that you can place directly into an “authorized_keys” file.

Always use SSH-2 or newer, prefer RSA over DSA when selecting a key and lastly, pick a decent key size. These days, 2048 for key size should be considered a minimum, however, 4069 or 8192 are better. The number, in case you were wondering, is a power of 2 (or a multiple of 512 or 1024, i.e. 1024 & 2048 divides evenly by both 512 or 1024; and represents the number of bits in the key.

You might think the larger the bit size, the slower your connection, this is not true. This is because, the key is only used to encrypt a session key and is used infrequently during the course of the connection, the session key itself is used for the majority of the connection. While the key size may effect the time for build up and teardown of the session, you probably won’t even notice that. So 8192, or 16K keys… not a problem. Larger key size will give your key more life as advances in computing power are prone to reduce the life span of encryption techniques. So don’t be chintzy with the key size.

Not Original, But, Still Kind of Cool…

To make a long story short, I ended up at one point, buying two little 3x3x3 LED cubes from Radio Shack. They were about $20 a piece. Ultimately, the point was to mount them on my Udoo Quads (http://www.udoo.org) and control them through the Serial comms port using a Python script. While I had some trouble porting over the code from the Arduino it was meant to run on, once I figured out what I was missing it was a snap.

I even asked Dave to look at it, he couldn’t figure it out either, the answer came to me in a flash of insight. The cube is a Charlieplex system, and I was confused about the order in which the pins controlling the LEDs were being set high and low. To both of us at the time, it made sense, setting them high, turns the LED’s on, setting the pins low would turn them off.

Turns out it was the opposite. What we both missed was that, when the pins are low, they are grounded. Thus, if you are putting in 5v at each end, you get nothing, ground the cathode end and the power flows…. and we both  missed that part, that the cathode was set high to “shut off” the LED’s.

Anyhow, I kept one of the cubes for other purposes. I wanted a cube in a different color so I sourced almost all the parts from eBay and assembled one from scratch in Blue 3mm LEDs with an Arduino prototyping shield. See the video below for the Cubes in action.

Aside from having a cool little 3x3x3 LED cube, I had a purpose for controlling them with the Udoo’s. At the moment, I use the Udoo’s mostly for experiments, while they are not doing anything in particular, they are running Litecoin crypto coin mining software. They really aren’t powerful enough to make any Litecoin worth having, BUT, when the mining software submits a hash, it takes the cube out of demo mode (cycling through all the patterns it has except for one special one) and then display’s the special one. Basically when a hash is submitted, the cube pulses itself.

The two Udoo’s the cubes are on, will never find a block or get much in the way of work hashes, but it is a neat conversation piece.

Holiday Cheer

I worked on this project last year. Electronics by me, wreath’s by my wife. We made two of them. We also make a pretty good team. Most of the parts by Adafruit… ahaha…

eWreath

eWreath with the LED’s off

Of course, it looks better with the lights on…

eWreath with the lights on

eWreath with the lights on

Basically, its a typical wire wreath (from Joann’s) with some extra wide gift ribbon hot-glued and wired up to the wreath wire. Inside is a strip of Adafruit Neopixels also wired up to the frame.

The Neopixels are driven by an Adafruit Trinket mounted in a project case. The colors can be programmed in code and they cycle. I was heading towards a more ambitious configuration where I’d use something that had WiFi or Bluetooth, so I could control it from a cell phone or tablet. I am saving that for Version 2. I’d upload a video, but the best one I have is larger then the max limit for uploading videos here. 🙁

The colors can be changed to suit the holiday since the Neopixel strip is RGB and you can program most colors. Next year we might put it out during Halloween with a nice Orange glow.

And that is one of the more interesting things. The Neopixels are quite bright. Seen the picture above, the brightness and color was turned down a bit because in full red it washed out the picture. I was hoping the ribbon would diffuse the LED’s… and it did somewhat, but the Neopixels are REALLY bright.

 

 

Forgive the rapid fire posts…

I took my independent blog offline… more or less, actually, GoDaddy took it offline… I had… technically… made the mistake of selecting a Windows environment for my hosted content. GoDaddy eventually turned over the Windows based hosting to Plesk. But even so, that was only for a year at the current rate I pay. After that, who knows.

So I set the Plesk stuff up… I wasn’t happy with it… I let the blog and site lapse as they turned it off. I saved the content, hoping to deploy it someplace else… I will eventually do that… but I kind of got distracted with other projects.

Of course, I skulk around the Element14.com community looking for pointers, tips and occasionally… parts for my electronics hobby.

Periodically they have these things called “Test Drives”. Basically you submit an application about what you plan on doing with the thing/stuff they are test driving and if you are chosen, then you get one of the things/stuff’s to test drive and do a write up. I was fortunate to have been selected for a Raspberry Pi 2 test drive; which was quite awesome. I wasn’t completely happy with the test drive though because I ran into some minor problems along the way with software, BUT, thankfully I learned a thing or two in the process. For example, I wanted to run performance tests on it. While I did that, I ran into a dead end at the Linpack series.

However, this lead me to another test suite, that I use regularly now for testing these little small board computers.

Today, I discovered they have another road test. This time with what looks like an introductory course in Microcontrollers and C. Of course, one of the things you have to do in the application is list some of your projects… with my personal blog offline… that kind of messes me up a bit with links to project content… so I am posting them here in rapid fire progression so I have a place to link to them for the application.

While I think I am probably a good candidate for the “microcontroller” part of the course material, the “C” part, not so much. While I certainly could use a refresher, my experience with… a number of more recent languages (C#, Java, JavaScript), which are descended from C/C++… and the fact I already know C and C++, kind of makes that part mostly just review material for me.

Although, I believe C with Microcontrollers, is not exactly like C as an application language… there might be some surprises there for me. At one point I tried using some “C” trickery on an Arduino and… well… it didn’t go so well… for some reason Arduino’s aren’t so good at handling dynamic array’s using “calloc” or the more C++ like “new” statement.

Anyhow, should be interesting if my application is accepted. Otherwise, back to the O’Reilly books for me.

Amazon Dash Button Hack

Well, I saw this some time ago and I just couldn’t resist it.

When I first saw the Amazon Dash buttons, I thought… wow… how useless… a single purpose WiFi enabled IoT device whose only reason for it existence is to help you spend money on Amazon. Even worse, the buttons are technically tied to certain product lines. (ie. The bounty button is for bounty only products… BTW, I am NOT pushing any particular product here). However, I’d prefer… myself, the buttons were more generic and you could set the button up to order anything from Amazon Fresh or Amazon Groceries… there loss in my opinion. For example, there is no button, currently, for anything I like to drink… although the Mac and Cheese button is sorely tempting me… had the buttons been more generic, I’d simply set one up to order a case of Lori’s Lemon iced Tea from Honest Tea and cheerfully chug it while programming. But … no…

Amazon Dash Button

Amazon Dash Button

Ok, after I got over the laughter it induced when first seeing the buttons, I realized… actually its a bit intriguing none the less… I was completely curious about how it worked, particularly for $5.00. Adafruit.com curated some tear downs of the button hardware and rehashed some already existing blog posts about repurposing the buttons.

Here is the teardown and the rehash of Ted Benson’s Dash Button Baby Monitor hack.
Anyhow, there are two ways to repurpose the $5.00 button.

  1. Reprogram the hardware (definitely not easy)
  2. Cheat, and do not complete the button’s initial setup and monitor your network for ARP broadcasts (the easier way).

As a security guy by trade, I *really* don’t like the second option. It is an example of why IoT is so dangerous. However, for yucks (and time constraints), I went for the second option. The funny part is, while Ted Benson is in the process of teaching you how to hack the button, he is also showing you how to hack… the hack… the observant techie will see this.

So first… the victim…

Amazon Dash Hack Victim

Amazon Dash Hack Victim

I would never be caught dead ordering a case of water from anyone personally unless it was for some kind of emergency, so I figured buying the SmartWater dash button would help me resist the urge of wanting to use the Dash button for Amazon’s intended purpose. (And yes, I have one for ordering pet food and have considered one or two others; ie. the Mac & Cheese one).

So, as per Ted Benson’s instructions, I proceeded to go to the Amazon Shopping App on my Android Tablet and configure the button for use on my WiFi network. The last step in the configuration is to select the item from the buttons “product” line you wish it to purchase when you press the button. At this point, I just closed the app.

Next, a little Python magic on a Raspberry Pi like computer (actually its called a Wandboard Quad, and I use it for development work) and using the Scapy library. All the code examples and details are in the Ted Benson blog post and I won’t rehash them here. However there are a few gotchas in the post…

  1. The demo python code is missing “#!/usr/local/bin/python” on both examples, so either you add it or execute the scripts like this, “python dash-listen.py”.
  2. You must install Scapy… and… everything it relies on. The simplest way to do this is, is on any Linux distro with a decent package manager (apt, yum, etc….) simply, for example on Debian derived Linux distros, “apt-get -y install scapy” will do the trick. This will bring down scapy and all its dependencies. If you install Scapy any other way… don’t ask me for help, your are on your own.

Anyhow, following Ted’s instructions, I obtained the button’s MAC address. Then I altered the python script to suck up the MAC address from a config file (which will be capable of holding an arbitrary number of such addresses for the future) so they can be recognized; ie the file contains the button type, MAC Address and script to be executed when pushed. As mentioned, I already have one button deployed Amazon’s way to keep my cats neck deep in tasty cat food (see picture below of the little beasties) and to keep my lazy lower posterior from having to leave the house to get it). However, it also stands to reason I can also see this ARP’ed MAC address for this button and launch a script if need be, like emailing both my wife and myself to be on the look out for the impending delivery and adding a calendar entry on Gmail for the probable delivery date.

Deez Cats

These little eating machines right here

Now, I have all the workings I need to get the button to do something… first lets demonstrate that it works…

As you can see from the video, once the button is pressed, its ARP broadcast can be detected with a great deal of ease. Interestingly enough, you may have noticed the video is much longer then it needs to be. In this particular test the button failed to do something. Usually, the button flashes the white LED, then flashes red (ostensibly to indicate it failed to order anything). For some reason this time it did not do that. Not sure why, I suppose if a case of SmartWater shows up, then I’ll know. 🙂 You may have also noticed that I did not display the complete MAC Address of the button… read on to discover why….

I have not yet figured out what I will use the button for, although I have some ideas, clearly though, I have to use it for something that is not critical or terribly bothersome should, uh, ahem… something goes wrong… read on for details. This was more of a “I wonder if I can do this” kind of thing. Actually, I think reprogramming the button would be better. Primarily because, technically, this button can still work as Amazon intends it too. I just have to select something for it to order. Also, I have not yet figured out how to reset the button to work in some other WiFi network. It seems once its configured, then its locked into your WiFi network. Bummer…

…And, for the security minded, you may have noticed… or thought… well… if you can use Scapy to see the ARP broadcast… then can’t you just make Scapy forge an ARP packet with the same MAC Address???? Why yes… you certainly can! This would essentially simulate a button pushing.

I can just picture a scene straight out of the Simpsons, with Nelson Muntz mercilessly running a Scapy script while shouting, “stop pushing yourself, stop pushing yourself”. (for the Simpsons deprived…).

So… for example, say I rigged this thing up through IFTTT (If This Then That, ifttt.com) to control my household Wemo switch which drives a living room lamp. Then some idiot can simply instruct the python code to turn the lamp on and off all day long just for giggles by repeatedly issuing forged ARP broadcasts. This is why I did not display the last 3 octets of the MAC address… I’d just be giving you the keys to the python script by showing you that.

Bonus points for anyone who can tell me why showing the 1st 3 octets wasn’t so smart either!!!

If you reprogram the button instead of using this ARP method, which it is a rather brain-dead hack, you can add some security to, perhaps, for example, actually have the Dash button reach out to IFTTT itself over HTTPS instead of using a go-between python script. But reprogramming the button requires much more sophistication in dealing with electronics and a boat load of TIME which I do not currently have.

Anyhow, something to consider.

Any suggestions for what to use the button for?

I suspect my next attempt at this, will literally be to build a similar device using an ESP8266 Wifi module ($2.50) running NodeMCU and an ATMEL AT-Tiny 85 microcontroller ($0.95) with a quartet of cheap push buttons and a 3.3v coin cell. Altogether, the cost should be on par with the Dash button, but the ESP8266 and AT-Tiny85 are *much* easier to program. Which opens the possibility of greater security features and significantly better configuration (ie. use in multiple WiFi networks) and possible greater non-security features too. It will just simply be, much more flexible.

CSI: Cyber

Matt reviewed CSI: Cyber some weeks ago… today I was channel surfing and came across this weeks episode…
I decided to watch it, just for kicks.

Hmmm… they found a suspect at the IP Address of “957.x.y.z”… in of all things from the header of a commercial email… which… no email these days includes the originating IP addresses anymore… nor is any digit of an IP address larger then 255….Um…

So, I won’t be watching this again.

But, I will say this… if non-IT security people watch it and start becoming more aware (or scared) of cyber-security issues… I don’t think I can complain about that…

Hmm… ok then…

If anyone is reading my blog and recalls, I once opined on the state of semi-conductor technology, most notably how physicists and engineers extended the life of silicon transistors instead of having to resort to much more expensive gallium arsenide. I also mentioned that its likely that the performance envelope of silicon has probably been reached unless someone comes up with a good idea like the last “doping” process.

Well, Stanford beat everyone to the punch with a way to make gallium arsenide cheaper.

According to Aneesh Nainani at Stanford, the average gallium arsenide 8in disc, cost about $5000 while the average silicon 8in disc costs about $5, you can see the problem reaching an on par economy of scale using gallium.

However, Stanford found a solution that will dramatically reduce the cost… see here… for details.

Worlds most useless Hack

Really… really…. I’m just speechless… I have to give the 16 year who did this, mad props for the technical skill… but why?

Next try should be a virtual retro gaming console, now that would be a awesome hack.

Why such Insecurity….

Oh boy.. tough question… the answer unfortunately is a bit complex and often a tad offensive to some…. and I can’t address all the problems in a blog post, but here goes on an attempt to outline some of the fundamental issues…

There are many aspects to what makes things insecure, but as in all sciences, understanding the fundamental forces both simplifies the explanation and allows any understanding to have more forceful and wider reaching effect when searching for solutions.

As in most things, the answer typically often is, the problems you see are merely symptoms and the greater problem is the system or model is broken. Therefore, working to fix the symptoms, never really solves the problem. With that in mind, here goes… I will list them first and explain then second.

  1. Paradigm Shifts
  2. Education
  3. Domain and Range
  4. Codebase
  5. Cohorts
  6. Deadlines
  7. Gaming
  8. Bias

Paradigm Shifts

Computer systems and IT itself from the early days, circa 60s to about the 80’s, is considerably different then how things are done today. For starters, networking computers together in a generic fashion and across wide geographical areas.

Earlier IT was mostly serial communications within an organization and over private closed circuit phone lines. In particular, an early problem in computers was that one crashing program could utterly disable a computer or significantly destabilize it… this problem has since mostly been fixed, but this plays a key but subtle role in modern security issues I will explain that next.

Education

Until recently, education in security was, and still remains, often an after-thought. Additionally, the subtle issue is that, many of the people educated in the time period before the internet have had ZERO education in security and any knowledge was gained on the job through experience (thusly, no formalized or rigorous study with well organized material and accepted principals).

As an example to illustrate the point. When I was a Computer Science student, I was educated about a problem in programming called Bounds Checking. For the non-programmers, you don’t need to know what that is, but, my education of this concept amounted to this, “Check you bounds or your program may crash or become unstable”…. that’s it…

The problem is that this issue in programming is primarily responsible for the most common security flaw, the Buffer Overflow.

Domain and Range

More or less a mathematical concept, its important to understand that all things math, physics, chemistry, engineering and computer science are bound to it and it is very poorly understood by people in IT. I can go into the technical details, but I’d rather not. It is sufficient to say that these concepts are used to map an object’s transition from one state (or set of states) to another state (or other set of states). For example, we know, the sun rises in the east, it reaches its height at noon and then sets at the end of the day in the west. If at noon, the sun started moving back into the east… something is seriously wrong. So the Sun’s states are understood and anything else would be a problem. Surprisingly, programmers, both self-taught and formally educated, don’t often account for state changes which are abnormal or unexpected. (Obviously, self-taught programmers are more guilty of this then the formally educated kind)

Failure to handle unexpected states is exactly what security exploits target.

Bounds checking, as mentioned above, is one form of paying attention to Domain and Range because it forces the programmer to understand what is… and what is not, an acceptable state.

Codebase

All software contains flaws. This is a direct result of incomplete attention to Domain and Range of the component pieces of a program. Some bugs will never be found or used maliciously, others will.

That being said, software in use for many years will contain flaws and continue to do so for many more years. So, software written in the time period where security education was nearly non-existent or a product of programmers not formally trained, is still in circulation. Any software based on that software, will suffer from any flaws as well.

Codebase, refers to that software that is ages old or used by many other pieces of software.

The codebase is large, some of it quite old, much of it heavily relied upon.

Cohorts

Connecting back to education, those educated in the early days are still in the workforce and will remain so for at least another 10 to 15 years. The cohort getting ready to replace them when they leave the workforce are only slightly, and iteratively, more knowledgeable. The cohort after them, is likely in a better situation, security wise, as having entered the educational system as security has become a front and center issue.

Deadlines

Unrealistic deadlines forces IT people to not fully understand a project and its technology, or rushing to complete a project by knowingly taking ill-advised short-cuts (with the likely intent of going back and fixing it later… which often never happens due to other time short deadlines). Deadlines are often formed by corporate goals. It is the lack of consideration of anything but corporate goals which tends to cause deadlines or maintenance life-cycles to also fail in the long term.

Gaming

Security is a paradigm with an unattractive feature of having a short time period between changes. This is because security is always being gamed. To illustrate…

A thief walks into a house by an open door. The owner then closes the door. The next thief merely opens the door. Now the owner locks the door. The next thief enters an open window. The owner then closes and locks all the windows. The next thief smashes a window and enters anyway. The owner then puts bars on the window, the next thief picks the door locks. Finally, the owner then puts in an electronic security system to end the problem once and for all.

What does the next thief do… easy, he waits for the owner to come home, points a gun at him and enters the house at gun point.

The point here is, for every action the owner can take, the thief can find acceptable alternative options to meet his or her goals. This is called gaming the system.

It is also an example of paradigm shifting. Every time the owner changes his defensive tactics, the attacker changes their offensive tactics.

If you change a tactics without understanding the problem first and entertaining what possible new weakness any plan may introduce, you have a seriously flawed plan; one that can likely be gamed.

Bias

IT is often filled with acrimonious debate over which thing is inherently better… if someone fails to recognize that, they are mentally labeled a moron and grouped with similar morons. The morons create cliques or camps and they will rarely acknowledge when differing opinion is correct or holds any validity; as if doing so is personally costly or a betrayal of dearly held beliefs. Actually.. its quite like religion.

This effectively stifles any truly open and intellectually rigorous debates centered on trying to understand things instead of merely advancing ones own agenda for the sake of advancing one’s agenda. Solving problems becomes an act of trying to fit ones cherished technology choices into any problem, even if there are better solutions.

This incredibly hampers sound architectural engineering.

Couple these issues and a few others together and you have a system that is fundamentally incapable of addressing the underlying problems and only just “patches” as it moves along from problem to problem.

Of course, offering up some of the problems and no solutions is just as bad… so here is what needs to happen in order to fix the problems.

First, accept that as time goes on, doing what you did in the past will not be sufficient for the future. Accept that things will change, be flexible about it.

Secondly, education. Those entering the educational system have to be exposed to formal and rigorous material. Those out of the educational system have to have periodic professional development to stay current. That being said, those who do not have, or did not have, a specific focus on security in their education or professional development MUST defer (if not ordered to defer) to those who have. Please don’t take this as a sit-down and shut-up philosophy, what it means is, defer to the expert in the subject matter; professional interaction between experts in different disciplines with deference to one another is the ultimate goal here.

Next, domain and range along with codebase and cohorts present a problematic challenge. Codebases have to be reviewed or tested against current understandings of security issues and continued professional development. Moving from one technology to another to run away from a problem (or problems), only presents you with different problems; choices should be carefully considered (if not scientifically) and with due caution (and without bias).

Deadlines have to be more realistic. Project participants have to be given ample time to understand their projects unique issues and their most viable solutions. Pushing a project for high-visibility it a short-sighted and deadly game. Along with deadlines, organizations also have to be willing to allocate minimum resources. I have seen to many IT teams that are both understaffed and under funded, this is about as good a mix as an understaffed and under funded hospital… the outcomes will be random and quite poor.

Lastly, gaming and bias. This is the crux of the problem. It requires us to think ahead or even predict future behavior. This is incredibly difficult. But, surprisingly… easy to combat without having to predict anything. Bias, prevents us from recognizing flaws and possible solutions. It also hampers professional relationships by intellectually separating groups within an organization into US and THEM groups who overtly and covertly sabotage each other. Attackers WILL target such divides and biases. It is a fundamental problem between groups who lack coherency versus individual actors who have no such requirement, or naturally form groups that bind together solely by some coherency. For example, consider a bank with a dysfunctional corporate culture that allows political self-interest regarding career advancement to dominate business decisions versus some group of Russian 20-something’s who want to get rich. The 20-somethings can exploit the bank’s dysfunction because it really isn’t minding the store so to speak and the attackers are much more focused on meeting their collective goal. (This has actually happened BTW).

Combatting gaming is straight-forward. Just be organized, understand what is valuable to you… what is valuable to the attacker and architect systems that address this and are on a sound technical footing and you review periodically to be sure it meets current needs. Also, consider things that would make misuse hard to achieve. Learn… more about your surroundings and the capabilities of the technologies in it.

There is a concept in biology, called the Selfish-Herd principal. Basically, it states, if you and I are out on in the wild and we stumble upon a predator, like a lion, in order for me to survive, I don’t have to outrun the lion… I only have to outrun you.

The concept of making misuse hard… lends itself to this principal. Attackers are predators. They will always tend to go for the easy catch. Even moderate security implementations can cause many predators to hunt elsewhere.

It’s really just that simple.

As for biases, if I had an answer for that I could likely help the world achieve lasting peace.

All I can say regarding it is this, first, keep as open a mind as possible, listen, even if you disagree and consider what you hear. Try not to be intransigent.

Intel trains its employees to, “Argue as if you were right, listen as if you were wrong”. I find that imminently practical and wise. In the end, no one is saying you must agree… the wisdom here is that you should, at least, listen as if there is possibility that something of value could be said.

Lastly, if that doesn’t convince you to stay open to possibility, I remind you of something Benjamin Franklin said to the other revolutionaries that founded the United States, “Gentleman, if we don’t all hang together, we shall surely all hang separately.”