Holy Hash!

#security on software development security and web security, security best practices and discussions, break-ins and countermeasures. Everything you ever wanted to know about software security but were afraid to ask, for fear of not understanding the answer!

Over-engineering

Causes for security problems are legion. One of the high pertinence problems in software development is called “over-engineering” – creation of over-complicated design or over-complicated code not justified by the complexity of the task at hand.

Often it comes as a result of the designer’s desire to show off, to demonstrate the knowledge of all possible methods, patterns and tricks. Most of the time it impresses only people who are not deeply involved with the subject. Usually it annoys people that know software design and the subject matter. Slightly more often than always it results in overly complicated code full of security holes.

XKCD on over-engineering

Of course, over-engineering is nothing new and even in the old times this was a popular thing. The problem is, where the old mechanical contraptions were ridiculous and did not really quite work in the real life, the contemporary computer software, although built in about the same way, manages somehow to struggle through its tasks. The electronics and software design industry are the most impacted by this illness that became an epidemic. Interestingly, this is one aspect where open source software is no different from commercial software – the open source designers also try to impress their peers with design and code. That is how things are.

The over-engineering in software is not just big, it is omnipresent and omnipotent. The over-engineering disease has captured the software industry even more completely than the advertising – the broadcasting. The results are predictably sad and can be seen with an untrained eye. Morbidly obese code is generated by morbidly obese development tools leading to a simply astonishing myriad of bugs in software that fails to perform its most apparent task and written with so much effort that writing the original in assembler would have been faster.

The implications are, of course, clear: the complexity is bad for security and the bugs are bad for security. Mind you, the two interplay in ways that exacerbate the problem. To top it off, the software becomes unmaintainable in a number of ways, including the total impossibility of predicting the impact of even small changes to the overall system.

The correctness of the software implementation is hard to judge on non-trivial amounts of code. Software is one of the most complicated things ever invented by mankind. So when the software gets more complex, we lose oversight and understanding of its inner working. On large systems, it is nowadays usual for no one to have a complete overview of how the system works. Over-engineered software has much more functionality than required, complicating the analysis and increasing the attack space. It tends to have functions that allow complex manipulation of parameters and tons of side effects. Compare making a reaping hook and a combine-harvester from the point of view of not harming any gophers.

Bugs proliferate in over-engineered software both for the reason of complexity and sheer size of the code, which go hand in hand. We know by now that there are more bugs in higher complexity software. There is direct correlation between the size of the code, complexity of the code, and the amount of bugs potentially present there. Some of those bugs are going to be relevant for security. The bad news is that quite often what cannot be achieved by an attacker through using a single bug, can be achieved through using a combination of bugs. A bug in one place could bring a system to an inconsistent state that could allow an attack somewhere else. And the more complicated the software becomes, the more “interesting” combinations of bugs there are. Especially when the software is over-engineered it allows for a much wider range of functionality to be accessed through security bugs.

As for the maintainability, an over-engineered system becomes harder and harder to maintain because it is not a straightforward implementation of a single concept. Anyone trying to update such software would have a hard time understanding the design and all implications of the necessary changes. I came across a serious problem once, where a developer had to inherit a class (in Java) to add additional security checks into one of the methods. By doing so, he actually ruined the complete access control system. That was unintended, of course, but the system was so complicated it was not apparent until it turned out in penetration testing that one could now send any administrative command to the server without authenticating and the server would happily comply. When the problem was discovered, it became apparent in hindsight, of course. However, the system is so complex, that it requires non-trivial amounts of effort to analyze impacts of changes. Any small change can easily turn into a disaster again.

The complex, non-maintainable code riddled with bugs becomes a security nightmare. The analysis of over-engineered software is not only expensive, it becomes sometimes simply impossible. Who would want to spend the next hundred years to analyze and fix a piece of software? But that is what I had to estimate for some of the systems that I came across. For such a system, there is no cure.

So, the next time you develop a system, follow the good old KISS principle: Keep It Simple, Stupid. If it worked for Kelly Johnson, it will work for you, too. When you maintain the code and make changes, try to bring the code size down and reduce functionality. Code size and complexity are directly correlated, so decreasing the KLOC count is a good indicator.

Software Security vs. Food Safety

My friend works in a large restaurant chain in St-Petersburg. She is pretty high up in the command after all these years. We talk about all sorts of things when we meet up and once she told me about how they have to deal with safety and quality inspections and how bothersome and expensive they are. So I teased her: why don’t they just pay off the officials to get a certificate instead of going through all the trouble? And she answered seriously that that was only good for a fly-by-night business that does not care about clients or reputation.

Food Poisoning
Food-poisoning a customer would have severe consequences. Their chain has been around for more than ten years, she said, and they do not want to risk any accidents to destroy their reputation and client base. In the long run, she said, they are better off establishing the right procedures and enduring the audits that will help them to protect the health and safety of their clients. And she named three kinds of losses that they are working hard to prevent: direct losses from accidents, loss of customers as the result of a scare and a long-term loss of customer base as the result of reputation and trust decay.

I think there is something we could learn. The software industry has become completely careless in the recent years and the protection of the customer is something so far down the to-do list you can’t even see it. Judging by the customer care, most businesses in the software industry are fly-by-night. And if they are not, what makes them behave like if they are? Is there some misunderstanding in the industry that the security problems do not cause costs, perhaps? Evidently, the companies in the software industry do not care about moral values but let us see how the same three kinds of losses apply. Maybe I can convince you to rethink the importance of customer care for the industry?

Sony PlayStation Network had an annual revenue of $500 million in 2011, with about 30% margin, giving them a healthy $150 million in profit a year. That year, their network was broken into and hackers stole thousands of personal records, including credit card numbers. In the two weeks of the accident Sony has lost about $20 million, or 13% of their profit. When the damage compensations of $171 million kicked in, the total shot to about $191 million, making Sony PlayStation Network lose over $40 million that year. Some analysts say that the long-term damages to the company could run as high as $20 billion. How would you like to work for 40 years just to repay a single security accident? And Sony is a large company, they could take the hit. A smaller company might have keeled over.

security-2014-01-31-01

And these kinds of things can come completely unexpected from all sorts of security accidents. Thanks to the governments’ pressure we hear about companies suffering financial disadvantage from incidents that used to be ignored. The US Department of Health & Human Services has fined Massachusets Eye & Ear $1.5 million for the loss of a single laptop that contained unencrypted information. “Oops” indeed. The same year UK Information Commissioner’s Office fined Welcome Financial Services Ltd. &150,000 for the loss of two backup tapes. Things are heating up.

Now, the Sony PlayStation Network breach did not only cost Sony money. The company Brand Index, specializing on measuring the company image in the game circles, determined that that year Sony PlayStation image became negative for the first time in the company’s history. The gamers actively disliked the Sony brand after the accident. That was enough to relegate Sony from the position of a leader in the gaming industry to “just a member of the pack”.

More interesting tendencies could be seen in the retail industry. TJX, the company operating several large retail chains, suffered a breach back in 2005, when hackers got away with 45 million credit card records. At that time, the analysts were predicting large losses of sales that never materialized. TJX paid $10 million in settlements of charges and promotion and the sales did not dip.

Fast forward to December 2013, now Target suffers a security breach where 70 million customer records and 40 million credit card numbers are stolen. Target did not appear to be too worried and engaged in the familiar promotion and discount offering tactics. And then the inconceivable happened. The customers actually paid attention and walked away. The total holiday spending dropped by 9.4%, sales were down 1.5% despite 10% discounts and free credit monitoring offerings from the company. As the result, the company’s stock dropped 1.8%. In the scale of Target, we are talking about billions upon billions of dollars.

security-2014-01-31-02

So, what happened? In 2005, the industry worried but customers did not react. In 2013, the industry habitually did not worry, but customers took notice. Things are changing, even in the market and industry where software security was never of any interest to either shops or customers. People are starting to pay attention.

Now, if we talk about customer trust and industry image, the food industry serves as a pretty good role model. They have a lot of experience stretching back hundreds of years, they must have figured out a few useful things we could think of applying to our software industry. Take the dioxin scare of 2011. The tracing abilities of the food industry allowed them to find easily how the industrial oil got into animal feed and traced it to particular farms. Right away, the chickens and pigs were mercilessly culled at those farms. That’s what we call an accident response all right. In the aftermath, the food industry installed a regulation to require physical separation of industrial and food oil production and created a requirement for the labs to publish Dioxins findings in food samples immediately.

The food industry has learned that they will not be perceived well if they kill their customers. They are making an effort to establish long-term trust. That’s why they have good traceability, they are merciless in their accident response and they quickly establish new rules that help to improve customer confidence. Take the story of the horse meat fraud in 2013, where horse meat was sold as beef across Europe. That was not dangerous for health, that was a fraud to sell cheaper meat instead of more expensive. The food industry traced it all back to origin and found out that the liability for this kind of fraud was insufficient. That even after paying the fines the companies that engaged in this fraud were making a handsome profit. But customer confidence suffered immensely. And the industry took a swift action, the proposal to increase the penalties and take tougher measures was already accepted by the European Parliament on the 14th of January.

What can we learn from the food industry? They have great traceability of products, detection of all sorts of misbehavior and dangerous agents, requirements to publish data. The penalties are kept higher than potential gain and the response is swift and merciless: either recall or destruction of contaminated goods. All of this taken together helps the industry to keep their customers’ trust.

Try to imagine that HTC was required to recall and destroy all those millions of mobile phones that were found to have multiple security vulnerabilities in 2012. Well, HTC did not waltz away easily as happened in so many cases before. They had to patch up those millions of mobile phones, pass an independent security audit every two years, and, perhaps most telling, they are obliged to tell truth and nothing but the truth when it comes to security.

And this kind of thing will happen more and more often. The customers and governments take interest in security, they notice when something goes wrong and we have a big problem on our hands now, each company individually and the industry as a whole. We will get more fines, more orders to fix things, more new rules imposed and so on. And you know what? It will all go fast, because we always claim that software is fast, it is fast to produce software, make new technology, the innovation pace and all that. People and organizations are used to thinking about he software industry as being fast. So we will not get much advanced notice. We will just get hit with requirements to fix things and fix them immediately. I think it would do us good to actually take some initiative and start changing things ourselves at the pace that is comfortable to ourselves.

Or do we want to sit around and wait the crisis to break out?

Fraud Botnet Controls Sales Terminals

Ah, the humanity. ArsTechnica reports that researchers came across a proper botnet that controls 31 Point Of Sales (POS) servers with an unknown number of actual sales terminals connected to them. The botnet is operational, i.e., it is running and collecting the credit card data. The data is transmitted during idle times in an encrypted form to the command center. The software running the botnet is apparently available for sale worldwide in the black market. There is another report by Arbor Netowrks that follows the widespread attack campaign mostly in Asia. So much for credit card security…

Planning a redesign and a move…

Web DesignerI have a confession to make. I am planning to redesign the website. I am toying with several ideas on what things should look like. I plan to provide more information for non-specialists and even non-developers of software. You probably would agree that the website is rather intimidating to the uninitiated at the moment. I want it to be a little friendlier, so perhaps a division into chapters or separate catalogues of posts would be right. I am going to try out a few things and keep whatever works.

Anyway, that is all a little way off, likely at the beginning of the next year. In order to do the redesign though, I will have to move out of wordpress.com. The platform is wonderful, easy to use and worry free. The only problem is, you cannot really customize it all you want. For that, one needs own hosting.

So, the first step is likely to happen some time in January. I will move holyhash.com to own hosting. I will keep all of you who subscribed to updates posted (and thank you for subscribing, I really appreciate your interest). I will announce the move and I will let you all know when it is done. The website name will remain but the internals will be slightly different. Stay tuned.

Camera and microphone attack on smartphones

Tactile-password-288x192The researches at the University of Cambridge have published a paper titled “PIN Skimmer: Inferring PINs Through The Camera and Microphone” describing a new approach to recovering PIN codes entered on a mobile on-screen keyboard. We had seen applications use the accelerometer and gyroscope before to infer the buttons pressed. This time, they use the camera to figure out where the fingers are touching after the microphone has signalled the start of a PIN entry. The success rate varies between 30% and 60% depending on configuration and number of samples. And that is a lot.

This attack falls into the category of side-channel attacks and it is rather hard to prevent. The paper explains in detail how the attack works and gives recommendations for mitigation to the developers. The paper also refers to several other works that use side-channel attacks using smartphone. For mobile application developers, it would be a wise idea to read through this and referenced publications to find out what the state of the art now is.

Can I interest you in more security, sir?

nsa-eagle-200x197The last week’s meeting of the IETF discussed security of the Internet and the recent revelations that the NSA turned the Internet into a giant surveillance machine. While the sentiment was clear that the Internet should not allow itself to such abuse, there is little evidence that anything at all could be done about it.

The problem is not that it is technically impossible to introduce more encryption and build better protocols. The problem is that it is not in the current interest of the companies to do so. The Internet was conceived for use in academia, so it was not a commercial thing from the start. The principles on which it is built are idealistic. But it is commercial from the hardware to the applications, through and through now. And it is not in any company’s commercial interest to introduce better security. It is quite the opposite, in fact: most companies are interested in less security even if they claim otherwise.

Me and you, as people, as independent human beings, can introduce better security because it is in our interest. I would not rely on companies to do so.

Guard your secrets

I meant to write about the subject of spying and corporate information security for a while now but got around to it only now. The article Confessions of a Corporate Spy has provided an excellent background for the discussion and is absolutely worth a read.

Twenty years ago the corporate spying was already abound and me, as a fresh employee, was excited to find out that we are actually being spied upon. We had to keep quiet about our work when we went out for drinks or lunches. Once a Good Samaritan lady reported overhearing our colleagues talk about their work in a restaurant near the company. This lead to disciplinary measures and the whole company new what happened. And we all new it was wrong to discuss things outside.

4.1.1Fast forward twenty years. The company managers discuss the upcoming mergers and acquisitions in a social network account of a third-party company. Details of products, designs, problems, customers are exchanged freely at lunch tables and in trains. How often do you see privacy screens on laptops of people doing their work in trains and at the airports?

People became careless. It’s like if in the drive to deliver more and faster we completely forgot that the competition does not really have to do a lot to catch up with us if they have all the information available to them. We forgot that despite the information flowing in heaps over the Internet we still have to protect it in all the mundane places. Web security, application security, network security do not matter anything if all the same information is available to anyone who can listen carefully and record.

Security is said to be about finding the weakest link and mending it. Nowadays, the physical security of information is rising in the ranks and will become the weakest link. Sometimes it already is. Especially when a specialist in competitive intelligence comes around. With the business intelligence market estimated at $80 billion, do you think we should be sloppy?

Making sure your people know that it is a really bad idea to talk business outside a business setting, to talk confidential information to strangers, to work on company numbers where the screen can be seen and so on is not that hard. Companies 20 years ago did it. We can do it now. Let’s do it.

Google bots subversion

There is a lot of truth in saying that every tool can be used by good and by evil. There is no point in blocking the tools themselves as the attacker will turn to new tools and subvert the very familiar tools in unexpected ways. Now Google crawler bots were turned into such a weapon to execute SQL injection attacks against websites chosen by attackers.

it_photo_76483_200x133The discussion of whether Google should or should not do anything about that is interesting but we are not going to talk about that. Instead, think that this is a prime case of a familiar tool that comes back to your website regularly subverted into doing something evil. You did not expect that to happen and you cannot just block the Google from your website. This is a perfect example of a security attack where your application security is the only way to stop the attacker.

The application must be written in such a way that it does not matter whether it is protected by a firewall – you will not always be able to block the attacks with the firewall. The application must also be written so that it withstands an unanticipated attack, something that you were not able to predict in advance would happen. The application must be prepared to ward off things that are not there yet at the time of writing. Secure design and coding cannot be replaced with firewalls and add-on filtering.

Only such securely designed and implemented applications withstand unexpected attacks.

Dump anti-virus and move to secure-by-design?

I stumbled across an article this morning that analyses the threat to the mobile devices from malware and comes to the conclusion that it is not likely a good idea to  have an anti-virus on your mobile.

mobiliesecurity01The premises are that only a very few of the mobile devices are currently infected, so the conclusion is that the infection is unlikely, plus that anti-virus software is terribly ineffective at catching the malware. The author concludes that the industry is best off to dump anti-virus on mobile and move to secure-by-design hardware and software.

I wholeheartedly agree that moving to secure-by-design devices would be excellent. I personally prefer an old trustworthy Nokia rather than any new fashionable smart phones for making calls and reading RSS. On the other hand, there is a couple of problems with the analysis and the proposition itself.

First, the apparent absence of the malware infection on the phones says nothing about either the actual infection or the possibility of infection. The mobile malware may get better tomorrow and the levels will jump overnight. Or perhaps we do not analyse it properly. The likelihood of infection is not a function of the current rate of infection.

Moreover, asking the mobile industry to make secure devices is vain. This is the same as asking the software industry to make secure software. They are just not going to. Security costs money, security is a cost for the manufacturer and they will reduce it through the floor if they can.

Secure-by-design is only going to happen when the costs of security breaches stop being externalities for the producer. As long as customers bear the costs, security remains the problem of the customer.

Security Assurance vs. Quality Assurance

7033818-3d-abbild-monster-mit-investigate-linseIt is often debated how Quality assurance relates to Security assurance. I have a slightly unconventional view of the relation between the two.

You see, when we talk about the security assurance in software, I view the whole process in my head end to end. And the process runs roughly like this:

  • The designer has an idea in his head
  • The software design is a translation of that into a document
  • Development translates the design into the code
  • The code is delivered
  • Software is installed, configured and run

Security, in my view, is the process of making sure that whatever the designer was thinking about in his head ends up actually running at the customer site. The software must run exactly the way the designer imagined, that is the task.

Now, the software has to run correctly both under the normal circumstances and under really weird conditions, i.e. under attack. So the Quality Assurance takes the part of verifying that it runs correctly under normal circumstances while Security Assurance takes care of the whole picture.

Thus Quality Assurance becomes an integral part of Security Assurance.

Post Navigation

Follow

Get every new post delivered to your Inbox.

Join 99 other followers

%d bloggers like this: