•  Oxford: +44 (0)1865 877830 
  • Manchester: +44 (0)161 713 0176 
  •  London: +44 (0)203 5983740 
  •  New York: +1 646-781-7580 
  • Dubai: +971 (0)4 427 0429

Security is a Process, not a Product

You are here

05

Sep

Security is a Process, not a Product

Security is a process, not a product - Strong IT security brands encourage the use of a single commercial product but this is not as secure as a process.

It’s not a novelty to say that the market is often regulated by the strong business brand and it is no exception for IT security. Companies will often use a single commercial product to try to achieve a good level of safety and compliance with main security standards. This seems especially true of larger companies. However, this business solution is conceptually wrong because “security is a process, not a product” (Bruce Schneier).

A good example of where process is an important consideration was demonstrated in a recent penetration test I was involved in. During the analysis of a large network I found an old version of a web application to manage tickets. As shown below the last post was in 2006:

 

Obviously, my focus was principally on this web application and shortly after I got a reverse shell:

uname -a
Linux ******** 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 i686 i386 GNU/Linux
cat /etc/*-release
Fedora Core release 3 (Heidelberg)
LSB_VERSION="1.3"
Fedora Core release 3 (Heidelberg)

Browsing the file system I looked around to see if there was anything interesting. My patience was rewarded by discovering the presence of a script in which there was a small list of username and passwords:

tail /home/scripts/******_ssh_users/******_ssh_users.sh
do_user "******" "******" "" "yes"
#do_user "******" "******" "" "yes"
#do_user "******" "******" "" "yes"
#do_user "******" "******" "" "yes"

Luckily, an account was still active, and through an SSH connection I got an interactive shell. However I was still a low privileged user and so it was time to get root. Before attempting any exploits I browsed around. More information usually means a better chance of a successful attack. After a short time looking around I noticed a list of screen session enabled:

There are several suitable screens on:
5679. ****** (Dead ???)
8329. ****** (Dead ???)
24216. ****** (Detached)
6152. ****** (Dead ???)
24335. ****** (Detached)
4657. ****** (Dead ???)
12466. ****** (Dead ???)
29954. ****** (Dead ???)
2964. ****** (Dead ???)
5731. ****** (Dead ???)
5749. ****** (Dead ???)
22720. ****** (Dead ???)
13417. ****** (Detached)
5680. ****** (Dead ???)
14619. ****** (Dead ???)
Remove dead screens with 'screen -wipe'.
Type "screen [-d] -r [pid.]tty.host" to resume one of them.

One of these sessions gave me a root access. Perhaps the system admin did not remember that he left a root screen open. This vulnerability is not attributable to specific software. Although the web application was not patched, the main problem was that there wasn’t any specific company procedure to prevent leaving the screen session open. Again “security is not a product but a process”.

Through manual penetration testing it’s possible to find out the main risks that your company are exposed to and the remedial actions required to remove the risks. This example shows how policies, procedures and user awareness are keys to effective information security management.

Posted by Michele

Leave a comment