SudoPoint

In the preceding article, I made mention to a concept referred to as “The Singularity“. This refers to a point in time where an almost infinite rate of technological advancement will occur. Leading up to this point, exponential increases in the rate at which technological breakthroughs and advancements are made is projected to result in an asymptote. The point in time at which this asymptote occurs is referred to as The Singularity. There is much speculation as to what the singularity will hold, and there has been suggestions of artificial intelligence constantly improving upon itself at increasing rates, eventually surpassing human intelligence. Others feel that it will be at that point when we become intimately linked with technology. I however, have a different opinion, and one in which we have started to see the repercussions of in terms of information security.

Events leading up to the singularity

In my mind there is a very clear trend occuring in terms of technological pressure. I hinted, in the previous article, at a certain “direction” which technology was moving. In it’s earliest form, technology was a simple manipulation of nature to achieve goals with greater ease. As time went on, technology became a vehicle for our separation from nature. We build great cities, so devoid of nature that we could no longer recall the absence of this codependency with technology. We then built technology to separate us from our neighbours, and ultimately from who we are. Eventually, we reached the zenith of this detour from nature and began to make advances in controlling nature. We started mapping DNA, made advances in neurology, psychology, physiology. We have already entered a period of time which I feel will culminate in fusing nature and technology. A full circle. There is already amazing work being done at places like the Cybernetics department at Reading University, where computer interfacing with the central nervous system is taking place. This technology could enable us to record thoughts and memories, and give us additional senses such as sonar. With the advent of such a tight integration of technology with nature, will this bring about the Singularity? I think not.

The Singularity

In my opinion, a logical further progression will most likely occur. One where the borders between that which is technological and that which is natural will fade away. Technology will become biological. We will no longer be reliant on technology wich is against nature, but rather, we would have progressed to a point whereby nature is technology. I see this happening already in various ways. For a simple explanation, let us look at at some remarkable work being done in the architecture and engineering fields whereby a fusion is occuring between architecture and nature. We have more sofisiticated, aggregated systems where geolocation data is becoming fused with more abstract layers of information. There is also the incredible field of nanotechnology, where we can actually transform biological systems into technological systems through the infusion of nanobots. If you just consider nanotechnology for a moment, you will realise that in the future, there lies the posibilitiy of real-life objects actually becoming data, compared to data being held about an object.

Although one could argue that molecular structures, DNA, RNA, all are *data* in their own right, my point is that they are not yet fully integrated with ‘our’ technology. It occurs to me that there might be this culmination of genetic research, nanotechnology, geo-engineering, and further advances in wireless data communication, Neotic Science etc.. which will bring about a unification of man and nature once more, but where nature is now the technology, and the object is the data.

As one can imagine, the need for security would be paramount. When objects become the data, we will no longer have the convenience of backups, or of recreating the data. The objects will have intrinsic value by virtue of both it’s natural qualities, but also it’s ability to influence events. Today we have mechanical systems becoming “smart”, and we are seeing the massive reprocussions that weak security is having on that. Imagine, if you will, when nature becomes “smart” in the same way. There will be even more at risk, there will be less room for error, and there will be potential for great societal advancement, or great tragedy.

As we climb steadily upwards, towards the asymptote of the singularity, the critical role of information security is becoming more and more apparent. In this article, I would like to deviate from the technical and focus on the philosophical for a moment, taking a critical look at the fundamental nature of information security in relation to the direction technology is taking us.

As is well know, that which holds the most value is no longer physical or financial resources, but rather, information. As the old saying goes “knowledge is power”, and this holds true even more so today. Wars have been fought over control of land, and resources in the past. Warfare is currently undergoing a frightening migration into the digital realm, where information is the resource over which many seek control through attacks of ever increasing complexity and sophistication.

Despite the ever adapting and evolving nature of attacks, our fundamental axioms for securing information has remained unchanged. At a very abstract level, security is one sided, in that we look at at the entity requesting access, and that entity is then matched to a matrix of entities and access scope. The problem with this, is we make a very problematic assumption on the separation of identities in the physical world, and their relating characteristics in the digital world.

Physical vs. Digital World

By delegating access scope based on the identity of the requestor, we rely on the stability and consistancy of the relationship between the digital entity, and the physical-world entity. Unfortunately, there are many problems with this; some of which have been highlighted with such attacks as identity/source spoofing and man-in-the-middle attacks. The reality of the situation is that there is nothing intrinsic in neither the physical world, nor the digital world which can ensure a verifiable link between an identity in the physical world and a digital entity. That is, with the exception of quantum data transmission such as with the E91 protocol for cryptographic key distribution. However, at this point in time, I am doubtful as to whether quantum physics alone would be able to solve the problems created by the methodologies information security is founded in.

If we, for a moment, imagine that this problem of securely relating a physical entity to a digital one had been solved, possibly by quantum physics, would that be sufficient? This leads us on to a fundamental problem with this atomistic view of individuals we have all come to adopt as common sense. As constructionists such as Brian Fay point out, there is no such thing as a concrete, persistant ’self’. We are constantly in a state of dynamic re-creation of self, always changing, never constant. Despite the seemingly intangible nature of this, it has implications for us in the field of information security. By basing security on a combination of identity and access scope, where the identity is something dynamic, fluctuating and non-concrete, we should not place trust in such an identity. It is known that people are not simple creatures; our minds are highly complex, just as the engulfing social constructs are complex. We cannot be certain that a person who is trustworthy today will be the same trustworthy person tomorrow. Circumstances, thoughts, ideologies, motivations, brain chemistry, social structures all change on a regular basis. A seemingly trustworthy accountant today, might become disgruntled tomorrow and misuse financial information he has access to.

What I would like to propose is that we look outside of the little box we have built ourselves. One idea is to shift the paradigm from giving access to entities, and instead, give access to collections of data. This would mean, instead of defining access control lists, we instead define business rules which govern what certain classes, groups or collections of data may do. We could define events which data would react to, and in so doing, interact with data in an indirect way. Entities would interact with systems which trigger events. Data react to events based on business rules.

New Paridigm

This is by no means a solution, but merely an idea of how the paradigm might be shifted. An additional idea might be to expand on recent work done around digital reputation. I think this has a lot of value, however, I do not see this being congruent with our current security paradigm. One of the potential values of a digital reputation scheme, such as with the Whuffie Bank, is that it generates an emergent white-listing system without need for centralized administration. I am personally in favour of the digital realm mimicing aspects of the physical world, as one could argue that nature has already solved many of the problems we are now trying to takle in our various levels of abstraction. In the natural world, the most respected have the most influence. Likewise, with a whuffie-like system, those with the best digital reputations have a greater ability to act. However, this falls prey to similar issues with the physical-digital entity relationship, whereby it is firstly far too easy to assume a fraudulent identity in the digital world, and secondly, it is possible to ‘cheat’ the system and increase your digital reputation through bots/malware/trickery.

Despite the shortfalls of digital reputation, I still feel it is important, as it is a forecefull broadening out from the confines of the traditional paridigm. I look forward to what solutions minds of tomorrow will present, and I hope that the rest of us will not hold back such adaptation and evolution of security.

Peering into the COOKIE Jar

Unlike traditional software systmes, the web is stateless by nature. This is a huge setback for using it as a platform for developing applications. All is not lost, however, as we have alternative methods of storing state information. The two most common methods are SESSIONS and COOKIES. These allow web programmers to have temporary access to data pertaining to a particular browser session for a website.

SESSIONS store this data on the web server, and are not directly accessible to the client. The web browsers merely submit the SESSION ID on each page request, and it is this SESSION ID which the server then uses to access the correct session data. COOKIES, on the other hand, store data in text files on the client machine. On each page request, the entire cookie is sent to the web server, thus allowing it to ‘remember’ the state of the web application for the particular client. However, if this COOKIE data is not sent and received in a secure way, it opens up some pretty awful vulnerabilities.

Apart from some of the obvious risks, such as sniffing HTTP traffic and viewing the contents of the COOKIE in full, the potential also exists for some malicious use of COOKIES on the client side.

SQL Injection via COOKIES

Some of the more vigilant web developers will do sensitization and validity checks on the GET and POST variables before using such data in an SQL statement. However, what about the data received from COOKIES? Suppose you have an SQL statement such as this one:

SELECT `allowed_functions` FROM `auth_table` WHERE `UserID` = $_COOKIE['UserID'];

If no encryption is used to ensure integrity and confidentiality of the COOKIE data, an attacker could simply change the UserID in the COOKIE data from an integer value to something like :

UserID=1 OR 1=1

This would most likely result in the attacker getting admin-level functionality. It is obvious that this is hugely problematic, and steps should be taken to preventing this from happening.

Privilege Escallation

A different vulnerability, much less complex than an SQL Injection, exists whereby an attacker can simply set the UserID value in the COOKIE file to different values until the admin account is found. Generally, the first few accounts are used for admins and testing accounts, so it probably would not be very difficult to find the ID of the/an admin account. For example :

UserID=1
UserID=2
UserID=3
…

Closing the COOKIE Jar

For protecting against SQL Injections via COOKIES, it is firstly vital to treat COOKIE data as being just as hostile as GET and POST, and thus should undergo sanitisation and validation just as other user input does. Secondly, it might be a good idea to implement something like PHP-IDS which checks GET, POST, REQUEST, COOKIE, SESSION and FILES.

By encrypting the contents of the COOKIE data, and sending the COOKIE via HTTPS, one can ensure that, firstly, the COOKIE will not be intercepted by a man-in-the-middle attack, and secondly, that a malicious user cannot manipulate the COOKIE data to perform either a privilege escalation or a SQL injection.

With the recent Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks on major websites and services, many system administrators might be looking at various techniques and technologies for protection against these threats. One basic (N)IDS technique against such attacks is log analysis. There are many tools for detecting brute forcing, and subsequently blocking access for the offending IP address. However, due to the lack of sanitization in sshd and ftpd log files, such tools open up very interesting possibilities for DoS attacks.

Scenario 1

Here is an example from an Ubuntu server of how sshd logs an invalid user login:

# ssh bob@myserver.com

# tail /var/log/auth.log

sshd[xxxx]: Invalid user bob from 20.0.0.20

That was as expected. So we see that we initially try to log in with user bob, however, because no such user exists, we see the log file indicating that someone from 20.0.0.20 was trying to authenticate with username bob. When a number of such log entries are made within a certain time period, automated IDS tools which monitor these log files will block access to the server for 20.0.0.20.

Scenario 2

Let’s look at what happens when we start to get creative with the usernames:

# ssh bob\ from\ 10\.0\.0\.10@myserver.com

# tail /var/log/auth.log

sshd[xxxx]: invalid user bob from 10.0.0.10 from 20.0.0.20

It should be clear to us that this attacker is attempting to brute force in from IP 20.0.0.20. However, log monitors are looking for the syntax:

sshd[.*]: invalid user <username> from <ip_address> .*

Therefore, what ends up happening is the 10.0.0.10 will be blocked instead of 20.0.0.20. This results in two very important consequences. Firstly, the attacker may continue to brute force in from 20.0.0.20, however they will most likely be unable to gain access, as there should not be any valid user accounts which contain “from x.x.x.x”. This, though, is not a problem for the attacker, as we shall now see. The second consequence is a resulting Denial of Service for 10.0.0.10. Because the attacker has been able to inject more than a single word representing the username into the logs, the attacker has essentially spoofed an IP address, as far as log monitors are concerned. The attacker therefore has the potential to block access to the server for valid, authorised IP addresses.

In Conclusion

If the attacker has knowledge of the IP address(es) from which administrators or other authorised users will be connecting from, although unlikely, they will be able to execute this DoS attack against these users. Although not an efficient or robust attack, this still posses a potential threat. There is thus a need for increased sanitisation of user input in log files, purely for the benefit of parsers, analysers and other code dependent on such logs. In addition, more robust regular expressions should be implemented in parsers to make provision for such injections.

A final point is that of custom scripts and software. Far too often we have cases such as this, where vulnerabilities occur either due to unknown scenarios or due to lack of knowledge. It is far too easy, as a system administrator with limited software development knowledge, to write monitoring scripts which allow for such vulnerabilities. It is therefore advisable that one stick to industry standards in terms of software used. This will guard against common vulnerabilities creeping in to your custom code, thus benefiting from the collective intelligence, rather than relying exclusively on one’s own abilities.

It is an unfortunate reality that there exists standards and specifications which are inherently insecure. As those in the information security industry will know, security is mostly a brief after thought in the IT field. I would like to focus, in this article, on the programatic treatment of integer variable assignments when compared to string variable assignments in the context of injection attacks.

When dealing with strings, it virtually a global syntax requirement to envelop the string data in quotation marks when performing the assignment or comparison. For example:

This is fairly basic syntax which everyone who has played around with a programming language will know. For the purposes of this article, it is important to note the differences between lines 2, and 4 in the above example code. Line 2 will result in an integer value being stored in the variable $myInteger, whereas line 4 will result in a string value being stored in the variable $otherInteger. If we now look at how SQL is handled, we see something similar.

A similar thing now happens. Line 2 results in a syntax error, as there is nothing demarcating the boundaries between operators and the string data. Line 3 and 4 operate as expected, and line five will convert the “10” into what ever data type `otherInteger` is defined as.

Due to the nature of integer and decimal data, there has never been a necessity to specify through syntax where the integer or decimal begins and ends, as they do not contain spaces as is the case with strings. This is why the SQL specifications for handling integer and decimal data do not require this. Unfortunately, this causes a large problem when we start to introduce variables into the picture. Take the following PHP code for example:

Suppose $x is set to 10, then `myInteger` will now hold ten for cases where the `id` field contains 1. This is all good, and what we expect. However, due to PHP’s “feature” of automatically casting variables into the required data type, $x could also contain a string. So, what would happen if $x were set to something other than an integer? What if $x were set to “1, `myString` = ‘pwned’” ? Now we start to see a big problem.

Let us take another, more realistic, example:

This would be a typical SQL statement to change a user’s password. We know that without properly escaping the quotation marks found in the $new_password string, we might have something like “SET `password` = ‘xyz’ # …..”, which would result in everything after the “xyz’” being commented out, resulting in every recordin the `myTable` table having the same password. This is commonly known and considered. However, how careful are we with our integer data?

You will notice that in line 3 $user_id is not encased in quotation marks, as we are expecting an integer to be inserted there, and integers are not to be encased in quotation marks, as per specification. However, what would happen if $user_id was actually a string containing “1 OR 1 = 1” ? Well, that would result in the following SQL query:

UPDATE `myTable`
SET `password` = ’some password’
WHERE `id` = 1 OR 1 = 1

This would have the exact same effect as the perviously mentioned injection attack, except now, we didn’t need to comment anything out, we didn’t need to insert quotation marks, we didn’t need to use any non alphanumeric characters other than ‘=’. This is a big problem, as this sort of injection attack would not be avoided by use of sanitization, or of parsing for quotation marks and special characters.

This brings me, finally, to my point; By not requiring syntactical encapsulation of integer and decimal data, we are making the specification insecure. However, if we were to start encapsulating integer and decimal data in quotation marks we would not be strictly following the specification. So, we have the choice of breaking specification and writing slightly more secure code, or sticking to specification and writing insecure code.

Obviously, the above vulnerability could by avoided by firstly ensuring that $user_id was in fact an integer, and not a string. However, it is just too easy to make a mistake, and there are far too many developers who are not even aware of such problems. You might also suggest that one might use a database abstraction class to programatically piece together the SQL in stages. However, you are still only as secure as the implementation of the abstraction class, and this still does not solve the issue of enforceability. It is therefore my recommendation that we start enforcing stricter security-related syntax in widely used specifications and enforce this syntax in the various implementations. It will go a long way to making the internet a more secure place for all.

It seems like every week there is a new attack vector emerging for web applications. There are SQL Injections, XSS, CSRF, and a whole lot more for web developers to now take precautions against. This can be quite a daunting task, and fairly unsuccessful unless done properly. One solution to this problem is to use a third-party security framework to assist you in combating these problems. PHP-IDS (PHP Intrusion Detection System) is an application-level quasi-IDS which provides an excellent base from which to secure your web application.

PHP-IDS works by analysing $_POST, $_GET, $_REQUEST and $_FILES arrays. The arrays undergo pattern matching against lists of patterns or “signatures” to detect various malicious attempts. It is important to note that because PHP-IDS is signature based, it cannot detect logical errors which could lead to security breaches. For example, if you forget to write code to protect unauthorised access to a certain script or page, PHP-IDS is not going to magically know that this should actually only be access by an authorised and authenticated user.

You can try out PHP-IDS’s capabilities by inserting malicious HTML/JavaScript/CSS etc. into their demo page. For example, you could type in something like :

<iframe src=’http://malicious-site.com’></iframe><b>Hello Innocent Victim</b>

Submit the form and have a look at the result. You should see some error messages appearing in red, indicating that the pattern matching has returned results, meaning that it has found suspicious activity. The nice thing about PHP-IDS is that you can configure how you wish to handle suspicious activity.

To make use of PHP-IDS in your web application, you first need to download and extract PHP-IDS from http://php-ids.org/downloads/ . Once done, move the extracted files into PHP’s includes directory. You are now able to make use of PHP-IDS in all of your web applications on this machine. To get the web application to initiate the PHP-IDS parsing engine, add the following code to your main PHP script :

1: require_once 'IDS/Init.php';
2:   $request = array(
3:       'REQUEST' => $_REQUEST,
4:       'GET' => $_GET,
5:       'POST' => $_POST,
6:       'COOKIE' => $_COOKIE
7:   );
8:   $init = IDS_Init::init('IDS/Config/Config.ini');
9:   $ids = new IDS_Monitor($request, $init);
10:  $result = $ids->run();
11:
12:  if (!$result->isEmpty()) {
13:   // Take a look at the result object
14:   echo $result;
15:  }

If we have a look at what is going on here, we will see that we first include the PHP-IDS script in line 1, and specify the order of the arrays to be parsed (lines 2 to 7). We load the configuration file in line 8 and initialise the parsing object in line 9. Now everything is in place, we can run the checks, which is what happens in line 10.

At this point PHP-IDS has done it’s thing and we can now handle the results as we see fit. In line 12 we basically define that, if there was a problem detected, we will do something. We would put our custom code to handle the problems where lines 13 and 14 are. You might, for example, want to email the contents of $result to someone, or you might like to halt the script all together. It’s up to you.

When dealing with the results, you will notice that PHP-IDE assigns an impact score. This is supposed to indicate how likely it is that an attack is taking place. You might wish to base your handling of $result on this score. It is recommended that anything with an impact score of greater than 15 be hard redirected to a safe page and an alert be sent out to an administrator with the details of the event.

PHP-IDE is not a magical silver bullet to solve all of your web application security needs. However, it is a great way to standardize security across your applications and cover a wide range of common vulnerabilities.

State of the Nation

As VoIP systems start gaining more and more momentum, the security aspects of VoIP are starting to come to the fore. Voice data is just as critical to maintained confidentiality as are other forms of data. Imagine eavesdropping occurring over a conversation between those in an organization’s IT department, or finance department, or at a higher level of government. Imagine even eavesdropping occurring over personal phone calls at home whilst making arrangements regarding your children.

The way things are moving, it is a certainty that the analogue transmission of voice will soon be a thing of the past. There is a constant move by governments to upgrade and improve technical infrastructure. Added to this, society as a whole becomes more technically savvy each day, and already expects a certain level of security and privacy in other day to day online activities. It is only a matter of time before similar expectations are made of VoIP. On the other side of the coin, malicious hacking activity is sharply increasing due to the proliferation of freely available tools which make it very easy for those with very limited knowledge to attack vulnerable systems.

In my opinion, those that should be taking the lead in VoIP security are the organizations already making use of the technology. Having dealt with VoIP servers and infrastructure for a few years now, there are some common things which I have picked up that occurs again and again. Here are some suggestions for securing a typical VoIP server:

#1 : Firewall

Firstly, let me state that a common misconception is that if there is a firewall, everything behind the firewall is protected. This is not the case. A poorly configured firewall can be just as useless as not having one at all. Secondly, firewalls only help in preventing certain types of attacks. They cannot, for example, guard against downloading viruses via email, phishing, or sql injections. In any case, a correctly configured firewall is a great starting point for securing your VoIP server.

As is standard practice, ensure that only necessary ports are enabled, such as SIP and AIX. Secondly, restrict SIP and AIX connections to those IP ranges which you are expecting incoming connections to be coming from. An ideal situation is to have all your infrastructure on a Virtual Private Network (VPN) and only allow incomming connections from IP addresses from within the VPN. This is not always possible though.

#2 Dial Plan

Something which I have seen recently is logic errors in dial plans leading to loss of revenue. As a rule of thumb, you do not want to place incoming calls in the same context as your internal SIP clients (for example) who will be making outgoing calls. Contexts should be used to separate out connections which can and cannot make outgoing calls, as well as other functionality. You would not want, for example, an incoming call into your call center being able to access the internal voice-mail system and then exploiting a transfer feature to make an outgoing, international phone call. Therefore, care should be taken when assigning contexts, to ensure proper separation of function takes place.

#3 Encrypt SIP Data

To provide privacy for SIP traffic, TLS should be used. (see RFC3261). SRTP can also be used for secure voice transmission. However, TLS is probably the best option, and is sufficiently simple to configure for most applications.

#4 Lock Down the VoIP Server

Finally, general security practices should be adhered to, such as regularly applying security patches, proper management of system user accounts, and regular vulnerability scans. If, for example, you have outdated software installed on the server which enables arbitrary code to be exploited, then it does not matter about all the firewall rules, encryption and dial plan analysis. The unfortunate reality is that it just takes a single point of weakness to bring all of your other security measures crashing down. It is therefore vitally important to get the basics right, and not only