Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

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.


Find out how we can help with your cyber challenge

Please enter your contact details using the form below for a free, no obligation, quote and we will get back to you as soon as possible. Alternatively, you can email us directly at busdev@www.dionach.com
Contact Us

Contact Us Reach out to one of our cyber experts and we will arrange a call