Friday, 20 June 2014

CodeSpace and protecting your intellectual property

The recent attack on CodeSpaces as reported by Help Net Security http://www.net-security.org/secworld.php?id=17028 shows how cyber attacks can be damaging to an organisations intellectually property. The attack was about availability, the DDoS was designed to prevent access by the clients of CodeSpaces but evolved into the permanent deletion of artefacts. The Incident Response process of CodeSpaces and its Business Continuity and Disaster Recovery (BC&DR) policy was found wanting.

So what happened


The attack on CodeSpaces was an extortion attempt, it is not clear from the CodeSpaces statement when the attacker had gained access to the Amazon EC2 control panel. What is known is that a DDoS attack was launched and a blackmail attempt was initiated with the attacker using a Hotmail account. CodeSpaces currently have no indication that a malicious insider was involved.

When CodeSpace started to investigate they found the attacker had control panel access but not the private keys.  According to their statement on the incident they believed that protected machines had not been accessed. However this did not prevent artefact’s being deleted via the control panel when the attacker realised CodeSpace was attempting to regain control. Codespace reported "In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted." The attackers have now appeared to of delivered what is a fatal blow to CodeSpaces .

How could it of happened


The critical factor to the attacker delivering a fatal blow was the attackers privileged access to the control panel for the hosted environment.

How and when the access was gained is not clear. Access to the Amazon EC2 control could have been obtained through a vulnerability within the control panel, knowledge of the credentials or brute forcing the password. It is unlikely since there has not been a spate of attacks on Amazon EC2 control panel that a vulnerability in the panel was exploited, but rather a social engineering attack on an administrator during the DDoS attempt or the password was brute forced prior to the attack indicating potential a weak password was used are the more likely options.

It could be a credible explanation that whilst trying to prevent the DDoS attack, an administrator might respond to a phishing attempt for credentials when in normal circumstances they more be more suspicious.  It is a common technique of attackers is to launch a DDoS attack to distract the administrators from the activities of hackers trying to break into a site. Whilst administrators are distracted during firefighting the DDoS attack and normal business activities such as responding to log events are ignored, these everyday activities would indicate additional malicious activities are underway.

Incident Response and BC&DR

A key part of any organisations BC&DR activities involves back up and protecting the back up files. CodeSpaces proudly discussed the Backups, Security and Continuity on their web site.

They claimed full redundancy; with data centres in 3 continents, they guaranteed 99% uptime.  For backups they claimed to backup clients data every time a change was made at multiple off-site locations. The backups were supposedly in real-time as they had invested a great deal of time and effort in developing a real-time backup solution that allows us to keep off-site, fully functional backups of clients data. They did state that backups are only as good as the recovery plan and claimed they had a recovery plan that it is well-practiced and proven to work time and time again.

However the password was gained, by having access to the EC2 Control panel the attacker was able to create multiple backdoor access routes and had full control over the artefacts including deleting them, affecting the availability. The attacker may of not been able to breach the confidentiality of the artefacts as they didn't gain access to private keys according to CodeSpaces.

Incident response procedures should of attempted to prevent remote access to the affected systems, in an in-house operation the network cable can be pulled and access obtained via a console. With hosted and cloud services this style of brute force disconnect from the internet is not possible. A better strategy would of been to create a new administrator level account, throw off all logged in users and disable all other accounts from login.

For BC&DR backups not only need to offsite but also stored offline, CodeSpaces were providing resiliency for clients rather than BC&DR for themselves.


Preventing it


With regard to the credentials to the EC2 Control panel, Amazon Web Services customers are responsible for credential management according to Amazon's terms and conditions. Amazon, however, has built-in support for two-factor authentication that can be used with AWS accounts and accounts managed by the AWS Identity and Access Management tool. AWS IAM enables control over user access, including individual credentials, role separation and least privilege.

A key part of any organisations BC&DR activities involves back up and protecting the back up files. Amazon do provide white papers and the tools and services to run BC&DR for an organisation, but it appears not only CodeSpaces ignoring the stronger authentication mechanisms that Amazon provide but they did the same for the support Amazon give to a BC&DR architectures.

The use of the cloud is not a replacement for a well thought out and implemented BC&DR policy.

What's Next


This attack could be conducted against a large number of organisations and not necessarily restricted to those hosted in the cloud. Organisations are not helping themselves in protecting sensitive data, in a recent survey by a  team of researchers from Columbia University (http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdrone.pdf) who discovered by reverse engineering  880,000 applications found on Google Play that the developers had hard coded secret authentication keys in the apps, which can lead to attackers stealing server resources or user data available through services such as Amazon Web Services

Extortion or Blackmail are common threats on the Internet, the BBC have recently reported that Nokia 'paid blackmail hackers millions' (http://www.bbc.co.uk/news/technology-27909096) to keep source code and keys secret. Previously it was the gambling industry that were prone to blackmail attempts via DDoS, however increasingly with organisation dependent on the internet anyone could become a victim.

As it appears that password compromise was the key factor, the secure use of strong passwords must be part of the culture of an organisation, staff awareness combined with strong computer generated random passwords with technology such as passwords vaults and two factor authentication would mitigate attacks on passwords.

Additionally, well designed and implemented disaster recovery an business continuity plans that are tested should be in place. Cyber attacks and the results need to be catered for in the plan.

Wednesday, 4 June 2014

How is your password attacked?

We protect most of our systems and information with authentication credentials consisting of a username and a password. This is single-factor authentication using something we know (the password).

The passwords we use are open to attack, either by guessing the password and using it to log in, or as a result of a breach where user credentials have been stolen and the lists are subsequently attacked.

Below are some common attack methods used against passwords, along with potential countermeasures.


Social engineering

Attackers will attempt to gain your authentication credentials simply by asking. This can also be combined with other attacks to make them more effective. Most passwords are based on something personal; by discovering details about you, the attacker can build a profile of likely words. Think of the film Wargames, in which Matthew Broderick discovers that the creator of WOPR has left a publicly accessible backdoor with his dead son’s name as the password.

Here, the countermeasures are to educate the user about the danger of social engineering and how attackers use social media as a profiling tool.


Sniffing/Logging

There are various forms of password sniffing or logging that can be used by an attacker. Typically, sniffing is where credentials sent over the network – in particular over wireless networks – can be intercepted (sniffed) by an attacker recording the transmitted packets. An additional method - Software Keyloggers -  relies on infecting computers with malware that captures key strokes being typed (key logging). This can be combined with screen capture to record the use of virtual keyboards and drop-down boxes (such as the selecting of letters of your password), typically used by banking Trojans. Finally, there are physical key loggers that can be attached or built into a keyboard to capture key strokes. The latest versions of these have wireless interfaces built-in. Physical key loggers were mentioned in some of the reports about the Sumitomo Mitsui Banking Corporation in 2004. Wireless accessible KVM (Keyboard, Video and Mouse) over IP were installed in attacks on Santander and Barclays branches in 2013.

Encryption of traffic over the network, up to date anti-malware on devices and awareness of attempts to install hardware are important countermeasures. The PCI DSS mandates looking for rogue wireless access points, so physical inspection can be combined with checks for malicious hardware.


Password brute forcing


There are various brute force attacks, including attacks on the login screen or against the stored credentials.


Single account


Login screens can be attacked by repeatedly guessing the password and submitting the guess until it is accepted. Lockout mechanisms, such as only allowing four guesses before freezing an account permanently or for a defined period of time, can prevent or slow down these attacks. Captcha can also be used to prevent most automated attacks. Log analysis of failed login attempts should indicate that a potential attack is underway.


Stolen password lists


Stolen passwords lists are often protected by a cryptographic function called a ’hash’; popular forms of hash algorithms are MD5 and SHA1. A hash converts the input into a fixed length message digest; the same input generates the same message digest. An attack will take a guess at a password, which is then hashed using the appropriate algorithm and the resulting message digest is then compared to those in the list of stolen password hashes: a match indicates a correct guess. This is a time consuming process which can be sped up using various techniques including Rainbow Tables, which are pre-computed message digests that can be compared to the stolen password list. If a match is detected, then the plain text version of the password can be found.

To prevent the use of pre-computed hash tables, passwords are often concatenated with a random value (‘salt’) unique to a system before being hashed. Other techniques to protect against brute forcing include using a hash algorithm multiple times: the attacker must know how many iterations were used. The Linux shadow password file contains a line per account; the password field consists of a number of elements that include the hash algorithm, the salt, and the message digest. Linux also applies the selected hash thousands of times.

Password brute forcing can make use of parallel and distributed processing. Some attack methods make use of multiple GPUs in a machine, and each GPU can have thousands of cores. A 25 GPU cluster can process 95^8 combinations in just 5.5 hours, enough to brute force every possible eight-character password containing upper- and lower-case letters, digits, and symbols.

Stolen password lists are often posted on bulletin boards for other hackers to crack, and some hackers offer password cracking services.


Botnets


Hackers can also use botnets, which can consist of tens of thousands to millions of machines, to attack passwords. They can be deployed to brute force passwords lists, or to brute force account credentials with each machine sending a few guesses to the login page to stay within the account lockout rules – of course, when millions of machines are used, accounts can be guessed and accessed.
Prevention

Given sufficient resources it is always possible to brute force a password, but a high work factor (defined as the amount of effort – usually measured in units of time – needed to break a cryptosystem) will make it impractical to complete a brute force attack.

Strong passwords are able to resist attempts to crack a user’s credentials. The strength is measured in its effectiveness in resisting guessing and brute-force attacks; this is a function of length, complexity, and unpredictability of the password.

Length


The longer the password, the larger the combination space will be. If we assume just lower case letters then the following applies; as the length of the password increases, the number of potential combinations increases exponentially.

Number of lettersSampleCombination space
1a26
2aa676
3aaa17576
8aaaaaaaa208827064576
10aaaaaaaaaa141167095653376

For more complex passwords (by adding upper case and numbers) the combination space increases further.

Number of lettersSampleCombination space
1A62
2A93844
3A9a238328
8A9aA9aA9218340105584896
10A9aA9aA9aA839299365868340224

Complex does not mean strong

A complex password is not necessarily a strong password, if we look at a typical complex password rule, such as:
  • Minimum eight characters
  • Must use upper and lower case
  • Must use numeric characters
  • Must use symbols
This can result in a password such as:
 
P4s5W0rd#
 
This is not a strong password, even though it meets the complexity rules. The complexity of a password depends on the combination of the symbols used within the password not being used in a predictable way. The number of available symbols is dependent on the characters accessible through the keyboard and accepted by the application.


Unpredictability


Part of preventing a password being broken is its unpredictability. A predictable password would be one found in a dictionary, for example. There is a class of password attacks known as a dictionary attack, in which word lists – often from a dictionary – are used as the source of guesses in the attack. Word lists are not just dictionary lists, but could be lists of football teams or players; the potential source of lists is vast with the Internet having lists of just about every topic from girl’s names to the top million used passwords. This means that, for those Manchester United fans who use a player’s name as their password, there is a list of every player that has ever been in their squad. The tools that perform these attacks automatically switch numbers and symbols for letters based on well accepted rules and will automatically append sequences of numbers to the end of the word. If you used the player’s name Ryan Giggs as the basis of your password – i.e. Ry4nGi66s1973 – this can be guessed by most tools that will accept a list of Man Utd players.

Don’t forget that social engineering or looking at your Facebook page could reveal information that may help an attacker select a word list to use in an attack; you could be making your password more predictable by what you say about yourself online.


Conclusion


In order to create a strong password that is resistant to attack a user must select a password that is long, complex and not based on dictionary words or using ‘leet speak’ to convert letters to numbers or symbols. The longer and more complex it is the more resistant the password will be to attack. Combining passwords (something you know) with a second factor, such as a token (something you have, like your mobile phone), will create a strong authentication system.

Tuesday, 3 June 2014

Do I have to change my password again!!!

Over the last few months we seemed to be bombarded with advice to change our passwords, but did we need to change passwords and did we need to rush out and do it immediately!

For the last three major vulnerabilities and breeches, listed below, we have been advised to change passwords, some of those advising password changes were clamming we do it immediately, others were more specific in the advice

  1. Heartbleed
  2. eBay
  3. GameoverZeus
Taking each of these in turn, what should we of done in each case..

Heatbleed

I heard advice very early on about changing passwords immediately, however it was not long before the media took advice from the experts and modified the initial advice.

Heartbleed infected the servers provide the services we used, often we need to authenticate (logon) to these services. Heartbleed could allow attackers to compromise servers and gain access to passwords. Changing passwords before the server had been fixed, meant attackers could still get on to the machines and get the passwords. The advise from security experts was once your service provider advised the server was no longer vulnerable, then change your password. The good service providers did advice their clients when to change passwords.

eBay

This was a lot simpler, if you used eBay you should of changed your password, very slowly eBay did advice its users to change their password. In this case attackers compromised eBay and stole a list of credentials, whether the attackers can crack all the passwords is a matter for debate. The point is they could, therefore you should change your password as quick as possible.

GameoverZeus

Seen and heard advice from many media outlets today, especially radio where the advice was change your password. This is very poor advice. Changing your password will not stop you being infected, if your are infected changing the password just gives the attackers your new password.

If you have a Windows machine you will need to take note, otherwise those using other operating systems can sit back and relax as GameoverZeus attacks Microsoft Operating Systems

GameoverZeus is a financial trojan, it affects client computers i.e. our home computers where we store our financial records and login to our online banking from, it is typically our personal home computer.

What users need to do is firstly ensure they have not been infected by running tools available from most reputable anti-malware / anti-virus vendors. These tools can detect and remove the infection. A list of tools is available from the UK governments get safe online website http://www.getsafeonline.org/nca

If you are not infected or have successful removed the infection you should stop your computer from being vulnerable to GameoverZeus, the malware uses vulnerabilities in the operating system and applications to infect your computer, patching and keep up to date. Automatic updates and tools such as Secunia Personal Software Inspector (PSI) can help with this.

If you were infected you will need to change your passwords, in this particular case the authorities and ISPs are trying to identity infected machines and advise the owners to disinfect their machines and change passwords. So if your ISP contacts your officially, or you discover you have been infected, change your password.

Watch out for

Scams, phishing emails etc trying to catch out the unaware and take advantage of those trying to keep out with the official advice. Every major vulnerability, breach and malware outbreak will be exploited by scammers trying to infect you. Don't open email attachments and don't follow web links in suspicious emails.

Good Practice

Good practice is to use strong passwords and change them regularly. Follow advice from the security experts on the strength of passwords, no dictionary words, no names. Use upper case, lower case, numbers and symbols and use long passwords.

Don't use the same username / password combination for all your accounts, a compromise of one could lead to all your accounts being compromised,

Cryptolocker and GameoverZeus

National Crime Agency Announcement

On 2 June the UK’s National Crime Agency warned that people have just two weeks to protect themselves against the Cryptolocker ransomware and a strain of the ZeuS (GameoverZeus) password sniffing malware – before both rise from the dead. The FBI disrupted the command and control systems for these pieces of malware, but the National Crime Agency thinks it is only a matter of time before a new command and control system is in place and attackers regain control of the malware.

Andy Archibald, deputy director of the NCA’s National Cyber Crime Unit, offered the following advice, “Our message is simple: update your operating system and make this a regular occurrence, update your security software and use it and, think twice before clicking on links or attachments in unsolicited emails.”

What are Cryptolocker and GameoverZeus?

Both these pieces of software are described as Malware, GameoverZeus is an advanced financial fraud Trojan and Cryptolocker extortion tool. Both are described in detail by the article published by Symantec
http://www.symantec.com/connect/blogs/international-takedown-wounds-gameover-zeus-cybercrime-network which describe both items of software, how they work and gives details on removing GameoverZeus.

How does this affect John or Jane Smith ?

Over the last two days it has been widely report in the media (TV, Radio, Internet, Newspaper) that people have two weeks to protect themselves from the malware and this is generating concern. A number of my colleagues have asked me about protecting their computers.

An important point to remember is not to panic, there are going to be phishing and malware campaigns designed to engineer the panicked individual into downloading malware. These campaigns will offer advice and tools on fighting the oncoming onslaught of malware and try and get your to open an attachment or visit a website, both of which will infect your machine.

It is important to get people to protect their computers, the advice given by Andy Archibald is sound security advice and should be what everyone is doing.

One of the points in an article published by the Register http://www.theregister.co.uk/2014/06/02/nca_gameoverzeus_cryptolocker_warning/ was that "More than 15,000 computers in Blighty alone have been hit by the ZeuS malware". In terms of infection this is a small proportion of personal computers in the UK. The Office for National Statistics report on "Internet Access - Households and Individuals, 2013" says that in Great Britain, 21 million households (83%) had Internet access in 2013. Although this does not give a accurate number of the number of computers in the UK it does indicate that they are tens of millions of computers in households across the UK. The actual infection rate of the Zeus malware is quite small.

It is important that people check their machines for infection, if they have been infected it needs to be removed and Symantec along with the other anti-virus companies have tools to do this. I do recommend that if you are not sure about your own anti-virus is to use a reputable online anti-malware tool that can be run from a website. Again all the reputable companies offer this type of software.

Protecting your machine

My advice is to ensure your operating system is updated and patched. The mechanism for doing this varies according to the operating system; for example, for Microsoft Windows 7, typing Windows Update into the search box in the start menu brings up the Update application so you can check for installed updates and see if there are any outstanding. Most operating systems allow a form of silent automatic update for critical issues.

A number of applications will allow you to check for updates: a useful tool is the Secunia Personal Software Inspector (PSI) https://secunia.com/vulnerability_scanning/personal/, which is a free computer security solution that identifies vulnerabilities in non-Microsoft (third-party) programs.

There is a vast selection of anti-virus and anti-malware software available and selection is down to personal preference. We do recommend that you select a reputable piece of software, and the top 100 list produced by Virus Bulletin has a summary of the performance of the most common antivirus/anti-malware software https://www.virusbtn.com/vb100/archive/summary. Selecting any of the software from the top quadrant https://www.virusbtn.com/vb100/RAP/RAP-quadrant-Aug13-Feb14-1200.jpg will protect your machine.

Conclusion

In summary to protect against malware you need to protect your machine, part of this is not falling for the phishing and malware email campaigns.
  • You need to ensure you are not already infected, there are a number of reputable online scanning tools that don't rely on binaries installed on your machine.
  • If infected, remove the infection. The well know anti-virus companies have the tools to this.
  • Install reputable anti-malware from a well know company
  • Ensure Operating systems, browsers and anti-malware are up to date
  • Keep the anti-virus definitions up to date.
 

Sunday, 27 April 2014

Activities

Looking forward to a busy few weeks, InfoSec is from the 29th April to the 1st May and I will be on the IT Governance stand on the 30th April to talk about PCI, Pen Testing and the Technical Services that IT Governance offer. My technical services colleagues will be on the stand on the other days, if you can't make the Wednesday, they will be more than happy to talk to you about your requirements. 

As part of the events related to InfoSec, I am looking forward to the ISSA-UK Infosec drinks on the Tuesday and the Information Security Bloggers meet-up on Wednesday evening where IT Governance Blog to which I contribute has been nominated for Corporate Blog of the year. 

I will also be attending two other PCI events in London during the week, including the “PCI SSC Assessor session London 2014” on Friday 2nd May. 

The following week I am speaking at the “ISO27001:2013, PCI DSS v3 and CES v1.0: New standards in the global cyber war” at the Churchill War Rooms, London. There are still some spaces left if you wish to attend, see the events page at the IT Governance website or book at the IT Governance stand at InfoSec next week. I will be speaking in the afternoon on Security as “‘Business as Usual’ - a recommendation of the PCI DSS v3” in that compliance is not a once year event but part of your everyday work practices. 

Final on the 13th May at the University of Bedfordshire, Polhill campus in Bedford I am giving a talk for the Bedford BCS branch and the IET Bedfordshire and Hertfordshire section on hacking the Internet of Things, if you are interested please book via the BCS event site.

If you are at any of these events I look forward to meeting you.

Monday, 21 April 2014

Hacking a door controller

As part of looking at RFID and the Internet of Things. I decided to look at RFID Door Access Control Systems and how they could be compromised. I wanted to show it is relatively easy to capture the RFID tags data and be able to clone them.

ADM2000-M Door access controller


The use of the Access Door Controller as a RFID sniffer was based on the work done by Kevin Bong, owner of the MiniPwner website and his minipwnerrfid article. Kevin's article describes an early version of the AD2000-M door controller than is currently available.

I used a AD2000-M access controller with an "Access Control V3."0 circuit board, which used a Nuvoton w78e052ddg 8-bit microcontroller, there is also an unidentified "ID module" attached to the circuit board. The ID module had a number of inputs and outputs which are labelled as follows.

GND OUT DR CFE VCC
GND CY ANT2 ANT1

Pins from the module were traced back to the Micro-controller pins 15 and 16, pin 16 was identified by Kevin in his article as being transmitting the captured TAG details to the Micro-controller. By sniffing this signal it is possible to read the submitted Tags serial numbers.
Part of AD2000-M Circuit - showing test pins
This is indicated that although the circuit board was visibly different from that in Kevin's article, the sniffer software should work. As the signals passed through, what looked like a set of unpopulated test pins, I soldered a set of pins to the board to make easier to connect to the circuit board.

Location of unpopulated test pins
Underside of the circuit board with header soldered in place
Header soldered to the circuit board
After soldering the header to the circuit board the GND and Out connections were connected to the Arduino as per Kevin's article

Header pins connected to a breadboard
Arduino connected to the Access Control unit
The Arduino sketch from Kevin's web site was uploaded to the Arduino and the serial monitor used to capture the scanned tags.
Serial Monitor display showing captured TAG numbers.
The next part of the project will be to clone or spoof the RFID tags.


Talk: Hacking the Internet of Things

I will be giving an introductory level talk titled Hacking the Internet of Things on Tuesday 13th May, details are available on the Bedfordshire branch of the BCS.

http://www.beds.bcs.org.uk/events.php

If you wish to attend you need to pre-book using the BCS event booking system https://events.bcs.org/book/1063/

Description of the talk

The Internet of Things describes a paradigm of how electronic devices including everyday items are now interconnected by various media to each other locally and across the Internet. This allows them to exchange information and to interact with us in order to make life easy. You can now control the heating in your home from a smart phone app or monitor the movement of hundreds of buoys free floating in ocean currents from anywhere in the world.

RFID Controlled Door lock
The Internet of Things has great potential for aiding us. However the potential for malicious activities is just as great. This talk discusses the Internet of Things and its potential. This will be followed by discussions and demonstrations of how the Internet of Things can be hacked to reveal details of our interactions or to take control of the environment around us.

Friday, 18 April 2014

SQL Injection, CISSP and Software Development

One of the topics of the CISSP is software development which covers the web application environment and vulnerabilities such as SQL Injection. SQL injection in its simplest form and the derivatives that have came about are probable the most effective attack tool in the hackers toolbox, whether black or white hat. The vulnerability is well know, as is the methods to mitigate the vulnerability, so why is there a problem? and why is the vulnerability still so effective.

A recent Ponemon study found:-

Measures to prevent SQL injection attacks are also lacking. Despite concerns about the threat, 52 percent do not take such precautions as testing and validating third party software to ensure it is not vulnerable to SQL injection attack. 

and that

44 percent of respondents say their organization uses professional penetration testers to identify vulnerabilities in their information systems but only 35 percent of these organizations include testing for SQL injection vulnerabilities. 

It also concluded

it used to require a high-level of expertise to construct a malicious query and conduct an SQL attack. Now the internet is flooded with tools that allow inexperienced individuals to obfuscate malicious queries, making it easy to be a bad guy, and even more difficult for SQL security measures to detect malicious queries.

The results are what I expected, I would a bit more into the detail and say the root cause of SQL vulnerabilities is the programming behind the applications. The developers don't understand SQL injection and don't know how to code to mitigate against such attacks.

History of SQL

The SQL injection has formally been around since Rain Forrest Puppy (aka Jeff Forristal) published papers in 1998 on the technique (http://phrack.org/issues/54/8.html#article). SQL Injection is as the name suggests a code injection attack used on data driven applications, such as web applications but can be used to attack any SQL database. In the attack malicious SQL statements are inserted into an entry field for execution when the page is submitted to the application.

Mitigating

The methods for mitigating SQL injection are well documented, the main methods are forms of input validation and restricting commands that can be run.

  • Parameterized statements
  • Enforcement at the coding level
  • Escaping
  • Pattern check
  • Database permissions

The Continuing problem

The problem is still very prevalent despite being widely known and methods of mitigating have been identified. The problem is prevalent in web applications; these are typically developed by coders who more experienced with design and usability issues than with business logic and server communication. Often tools and frameworks are used to develop application are using sophisticated front ends that auto generate code to drive the application, including the code to access databases.

In the past, I have hand coded applications using text editors as simple as notepad and used development environments such as Dreamweaver, which is not unique in its approach or particular bad, but the designer drags elements on to the screen, creates a layout and then enters details of the database to which it is to communicate and the code is generated automatically by the application to access the database.

My experience is that the application generated code is a lot more complex and larger than it needs to be to do the same function that I can write in a simple text editor. Further I find that web application developers and database application developers are not software engineers (programmers) and not trained in coding techniques in the same way. Often at University and colleges they will use examples of industrial applications for web and database front end development to give them experience of the tools they will use when employed before they really understand hand coding.

The problem with web applications will continue whilst developers are not aware of good secure programming practice and the tools used in development are not generating secure code.

Secure (Software) Development Lifecycle

A Software Development Lifecycle (SDL) is essentially a series of steps, or phases, that provide a model for the development and lifecycle management of an application or piece of software. The methodology within the SDL process can vary across industries and organizations, but standards such as ISO/IEC 12207 represent processes that establish a lifecycle for software, and provide a mode for the development, acquisition, and configuration of software systems. The intent of a SDL process it to help produce a product that is cost-efficient, effective, and of high quality. Once an application is created, the SDLC maps the proper deployment and decommissioning of the software once it becomes a legacy. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release, and maintenance (response). The maturity of the SDL can be measured with using a Software Assurance Maturity Model (SAMM) such as the OpenSAMM which has become part of the Open Web Application Security Project (OWASP).

Security is required to be consider all stages if security is to be built into the development rather than bolted on afterwards. If security is considered at the project initiation stage, it becomes part of the functional requirements, considered at the design stage, secure techniques will need to be used at the development stage and will be a requirement to be considered during testing and acceptance of the software. Microsoft have a good resource on Secure Development Lifecycle (https://www.microsoft.com/security/sdl/default.aspx) on their website.

Building security in, especially once the secure development lifecycle has matured will be easier and cheaper than trying to bolt on security after the functional testing has been completed.

Separation of testing and development

It is understand that developers are often not the best testers of a product, nor are end users. Both developers and end users will use cases they know will work or fail due to business logic and fail to use test cases that were not expected by the developers or expected when the functional requirements were generated. Testing application for functionality and security require two different approaches and less experienced the tester is the more likely they will not be able to test security requirements fully.

Applications should be written by developers who understand secure programming, then moved to a separate testing environment where security is tested as one of the acceptance criteria of the project by experienced testers. After certification and accreditation against the requirements, which include security, it is then moved into the production environment.

Open Web Application Security Project

The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. OWASP  build documents, tools, teaching environments, guidelines, checklists, and other materials to help organizations improve their capability to produce secure code. It provides tools for developers and tester to use to develop and test secure applications and should be considered the first port of call for an organisation wishing know more about web application secure coding and how to test the security of an application.

Conclusion

To wrap this article I will reiterate that the root cause of SQL Injection vulnerabilities is poor application development caused by lack of secure programming knowledge by developers. During the initial phase of an application project security is not considered as part of requirement development, this causes security to be ignored at the other stages of the software development lifecycle.

Additionally lack of use of skilled tester in the testing stage is not identifying the vulnerabilities, allowing through into the production environment. Once into production the increased number of attacks by script kiddies using automated tools that obfuscate attacks make it hard for the application to be defended.

I would recommend

  • The use of a secure development lifecycle to build security into the development project as a functional requirement.
  • Auto-generated code should be reviewed by a skilled program, so it is optimised and to ensure security requirements are part of the functionality the code delivers.
  • The use of code review by experienced reviews who understand security requirements and secure programming practice. his can be done by 3rd parties and the use of tools to help with the analysis
  • Better education of web developers into secure programming techniques.
  • Organisations sourcing 3rd party developers need to check secure programming knowledge of those developers.
  • The use of skilled software testers to test the application for all vulnerabilities.



Wednesday, 16 April 2014

Raspberry Pi and Serial Interfaces

A major use of the Raspberry Pi (RPi) is interfacing with the real world and other computers and often the communication takes place over a serial interface. I have written this as a result of my playing with the Raspberry Pi and using it connect to other devices. Please note this blog has used information from a number of sources in its compilation and I have not set out to plagiarise anyone but rather together information I found useful into a single source.

The RPi has a number of options for connecting to other devices including a serial interface using a universal asynchronous receiver/transmitter (UART) over the General-purpose input/output (GPIO) interface. The UARTs is used with communication standards such as EIA, RS-232, RS-422 or RS-485. The universal indicates that the data format and transmission speeds are configurable. The electric signalling levels and methods (such as differential signalling etc.) are handled by a driver circuit external to the UART. The GPIO on the Raspberry Pi is used to provide an interface to the world, it provides the following functionality through the double row of 26 pins.

  • Genuine GPIO (General Purpose Input Output) pins - 
  • I2C interface pins 
  • SPI interface, a similar concept to I2C but a different standard
  • Serial Rx and Tx pins for communication with serial peripherals
The Serial Peripheral Interface (SPI) bus is a synchronous serial data link, that operates in full duplex mode. It is used for short distance, single master communication, for example in embedded systems, sensors, and SD cards.Devices communicate in master/slave mode where the master device initiates the data frame. Multiple slave devices are allowed with individual slave select lines

I2C (Inter-Integrated Circuit) is a multimaster serial single-ended computer bus. It uses only two bidirectional open-drain lines, Serial Data Line (SDA) and Serial Clock Line (SCL). The I2C reference design has a 7-bit or a 10-bit address space.

I will be looking at uses of SPI and I2C later in another posting.

Signalling levels

Different signalling technology uses different voltages to indicate a logical '1' or '0', along with different device designs. For example RS232 uses a signal between +3v and +25v for a '1' and -3v and -25v for a '0' and RS485 uses a voltage differential.

Device Logic '1' Logic '0'
RPi +3.3v 0v
Arduino(*) +5v 0v

(*) Most Arduino are 5v, a few may be 3.3v

When using sensors for the Arduino with the RPi then you need to care with the signal voltages to prevent damage to the RPi.

Voltage warning

The RPI although having a 5V supply operates on 3.3v and connecting devices that use other voltages can damage the RPI board and components. Care must be taken when interfacing to other devices. The signalling voltages can damage the RPi and in particular if a power feed is used from another device this can damage the RPi as well.

When interconnecting devices and sensors to the RPi, care is required to ensure compatible voltage levels are used, and if necessary if voltages levels cannot be matched a logic level converter might be required such as the Sparkfun Logic Level Converter https://www.sparkfun.com/products/11978, I have a number of these myself and I do recommend them, however there are other devices and other methods of connecting different signalling voltages.

Powering the RPi through the GPI

It is possible to supply a 5v power connection on the GPIO pin. BUT, it has no backward protection and it was not really designed to be a 5volt input pin. The 3.3v pin can also be powered with 3.3v as the regulator has build in protection, but again it leaves your BCM2835 unprotected! Typically any power pins on GPIO area are used to power extended circuits.

Often this will be done as part of building a headless node (no keyboards, mouse or monitor) allowing the RPi to be powered via a serial interface or other connection.

One man's TX is another man's RX

I have often seen comment that when people have connected TTL to USB leads they had to switch the signal leads around. When connecting devices and leads together you can't just connect the labels. It needs a bit of thought.

A Transmission (TX) needs to be received (RX) and for two way communication, the remote TX needs to be connect to the local RX, this requires a crossover in the connection.


This can be combined with a logic level converter, when connecting pay attention to the direction of signal possible through the logic level converter, some channels may be unidirectional, others may be bidirectional.



RPi and 2 slices of serial

The RPi can use the serial connection in two modes


  • Console access
  • Serial Communication

Problems in using serial with other devices

If when trying to use the serial lines to communicate with other devices, the serial port generates errors about device not respond, not available and generally misbehaviours it is often as the serial lines are not under the sole control of the application being run, but still being controlled by the OS as part of console access. In order for reliable use the configuration of the serial lines needs to be configured.

Configuring the serial port

By default the RPi is configured to use the serial in a console mode in Raspbian and other distros for the RPi, the configuration  files that control the behaviour of the serial connections are the:-

/boot/cmdline.txt
/etc/inittab

These files need to me modified as follows. It is recommend that you copy the original files, prior to modifying them.

Modify the cmdline.txt file to remove reference to the ttyAMA0 device.

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

And the inittab file needs to have references to the ttyAMA0 device commented out.

#Spawn a getty on Raspberry Pi serial line
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Serial as a console connection

The initial configuration of the serial port allows it to be used for console access, allowing access to boot messages and providing a text based interface. Connection to the serial pins can be made with a TTL to USB cable such as the Adafruit cable. In addition to the cable if you are connecting to a PC you need your favourite terminal program such as Putty and it needs to connect to the serial port being used by the connection and configured to talk to the RPi. The Comm or serial port used by a TTL to USB cable can be found in Windows by examining the Device Manager screen.

RPi Default settings

Speed: 115200
Bits: 8
Parity: None
Stop Bits: 1
Flow Control: None


Programming the serial port

If the serial connection has been freed from the OS as described above, it can be used reliable within your own applications to interface with sensors and other devices.

The serial port is registered as a device using the name /dev/ttyAMA0 within the Raspbian distro, and similar names are used for other distros.

The port will often need to be configured and various opensource programme libraries are available for common programming languages that will help with configuring and programming the port.

From the command line the following can be used

stty -F /dev/ttyAMA0 9600

To configure the serial port and data can be sent or received easily using the following.

echo "hello, world" > /dev/ttyAMA0  # send a message
cat /dev/ttyAMA0                    # listen for a response

Hopefully the above has been useful, if you feel anything else needs to be added or explained, please drop me a comment.



Monday, 14 April 2014

Heartbleed and a warning from history

The OpenSSL Heartbleed vulnerability has caused a lot of confusion by the press and by companies racing to release information and advice. Due to the nature of my job I have been asked by family, friends and acquaintances on what to do.

What you should NOT do, is use the tools that are on the web and test service providers for the vulnerability, doing so WITHOUT PERMISSION is illegal in the UK and other countries around the world.

Lesson from history


On the 6th Oct 2005 Daniel James Cuthbert was convicted of breaking Section 1 of the Computer Misuse Act of 1990 by hacking into a tsunami appeal website 2004 New Year's Eve. Cuthbert, told the Magistrates Court yesterday that he had made a donation on the site, but when he received no final thank-you or confirmation page he became concerned it may have been a phishing site, so he carried out two tests to check its security. This action set off an Intruder Detection System in a BT server room and the telco contacted the police. This lead to him being arrested, prosecuted and losing his job and having difficult to getting a job due to a criminal history.

Testing for Heartbleed without permission could lead to you being in the same position

What you should do


The sensible approach for an individual is to respond to your service provider, whether it is online banking or an ISP, advice. They will advice if they have been affected and not all where, and if they were affected there will advise on when they have patched their services and whether you need to change your passwords. If you use different passwords on different services only changes those have been requested to.

Be Aware of Phishing emails


Only respond to communication from your service provider, double check advice by going to their web page by typing the URL and not following links in the email.

For companies the advice is to check if you used the affected versions of OpenSSL and patch. Their are a lot of legitimate scanning tools and testing companies that can test for the vulnerability and confirm remediation. Afterwards you may need to get clients to change passwords and change your SSL certificates.