Linux: You may have been Compromised when..

December 9th, 2014

There are a number of warning signs that a system has been compromised. The cases below warrant further investigation. Of course, they aren’t all guarantees that your system has been compromised, however they can be strong indicators.

1. Your welcome banner shows the last log in from an unknown/foreign IP address:

Last login: Tue Dec  2 16:08:41 2014 from 190.234.106.143
root@mt:~#

2. The load on a usually idle system is suspiciously high:

root@mt:~# w
 17:06:39 up 62 days, 22:37,  1 user,  load average: 8.12, 8.14, 8.11
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    pwn              17:03    7.00s  0.00s  0.00s w

This could indicate that unknown processes are running.
Read the rest of this entry »

Another PHP tip

July 15th, 2010

While it’s all well and good to spend considerable time securing your PHP applications, there is something else that you can do, or rather not do. As a PHP programmer, I see people do one alarming thing: they download and install PHP applications from questionable sources.

While there are a lot of honourable programmers who offer their scripts for free, there are plenty of hackers who enjoy deploying applications that cause harm to others. I discussed this earlier, but it bears repeating: trust your source. Know your source.
Read the rest of this entry »

Timing operations in PHP with microtime

April 12th, 2010

Within PHP, we have a function called microtime(bool $float).

When microtime() is called without any arguments it will return a string in the form of “microseconds seconds” i.e. “0.70801200 1271088014” which is the number of seconds and microseconds since the Unix Epoch (0:00:00 January 1, 1970 GMT).

When microtime is called with a ‘1’, i.e. <? echo microtime(1); ?> it will return the number of microseconds alone which is going to be more useful for what we want to achieve, i.e. “1271088173.97”

So using this, we can now write a script that we want to time, for example:

<?php
echo “Script Startingn”;
$start_time = microtime(1);
for ($i = 0; $i < 10000000; $i++)
{
//perform some calculation
$n = $i%247;
}
$end_time = microtime(1);
echo “Our script took: ” . ($end_time – $start_time) . ” to runn”;
?>

The output of this script is:

adam@vm1-webserver01:/tmp$ php ./t.php
Script Starting
Our script took: 1.45122814178 to run

Now you can add a $start_time = microtime(1); to the top of any script that you have, and a $end_time = microtime(1); echo $end_time-$start_time; to the end of any script that you have to time it, or alternatively just time certain portions to see where you can optimize things.

BASH Script – Blank Out CC Details

October 27th, 2009

Edit: I should have pointed out originally, as I have now received feedback on this. This is NOT the best or optimal way of performing this task. I was trying to illustrate as many shell scripting principles as possible in terms of ‘if’, ‘for’, counters, etc, and how such a one liner has been put together. Perhaps I should have thought of a better way of illustrating such principles, but nevertheless, here it is!

Here’s a quick one liner, can’t think why anyone would ever have any use for it, but maybe the principle itself could be of use to someone! This will take a file containing listings of 16 digit numbers, i.e. 1234123412341234 and replace it with XXXXXXXXXXXX1234

for I in ` cat mylist `; do P=””; ctr=0; for I in `echo $I|grep -o .`; do let ctr=$ctr+1; if [ $ctr -gt 12 ]; then P=${P}${I}; else P=${P}”X”; fi; done; echo $P|tr -d ‘n’; echo -ne “n”; done

Duly spaced and indented:

for I in `cat mylist`; do

P=””
ctr=0;
for I in `echo $I|grep -o .`; do

let ctr=$ctr+1;
if [ $ctr -gt 12 ]; then

P=${P}${I};

else

P=${P}”X”;

fi;

done;
echo $P|tr -d ‘n’;
echo -ne “n”;

done

Would love anyone to comment with variations.


Web Application Security Consultant Methodology

September 18th, 2009

I wanted to share some thoughts on my general methodology when approaching web application pen testing. Depending on size, scope of work, complexity and a number of factors, there are two separate angles, usually both or a hybrid of both that I will take.

The first angle has to be the network security itself, all the way down the the physical security. As a penetration tester, I’ll test the web, database, storage and any other related networked devices inside and out. Port scanning their interfaces, spoofing IPs and MACs, asking myself questions such as “Does the database accept direct connections from any IP? Does Apache keep too many spare threads waiting?” We need to work our way from bottom to top of the OSI Model, a lot of which can be done using nc (Netcat) and a combination of scripts, as well as nmap.

Secondly, as the security consultant, I would then test the application itself and dependant or otherwise related applications. Crawl the site and it’s file hierarchy using wget or similar, and then run automated test tools, such as burpsuite, acunetix and a combination of curl/wget and shell scripts before manually drilling down into anything suspicious. Unfortunately for the user, the majority of web applications are insecure. A web crawl using a recursive wget, followed by some blind SQL injection checks will more often than not turn up the opportunity for SQL injection. Once this is done, the next query is how far I can go with the SQL injection. Do I have root access now to the database? Does the database user have unnecessary permissions? I should be able to SELECT and possible INSERT/UPDATE data. It’s unlikely that I should be able to actually alter, or even drop the database from the web user. Having table update priviledge on all tables is just as good as being able to drop the database itself though in terms of potential damage. This combination of security issues could lead to even further damage once the initial compromise has been made.

The next question is how far to proceed once an opportunity has been identified. Is demonstrating an opportunity for SQL injection sufficient, or does the opportunity need to be exploited? Once done, does data actually need reading or writing to the database or code changed? This generally depends on the scope of the work and purpose/setting of the systems under test. More will be discussed on this in later articles.

Once complete, I will generally report and rate the issues found from 1 to 5. 1 being informational, 2 being low severity, 3 being medium severity, 4 being high severity and 5 being critical severity. The database user having additional priviledges may fall into categories 3 or 4. An outdated but currently secure version of the webserver running may fall in to category 1, whilst an SQL injection opportunity will for sure fall in to category 5.

Scope depending, I can either discuss the issues and advise on strategies to resolve, or alternatively provide the report ready for the Client to pass on to his own IT consultant.

Shell Return Codes – Ping Monitoring

September 9th, 2009

BASH – The Bourne Again Shell amongst most if not all other shells allows each application to exit with a return code. Some shells and environments have limits on what range this integer can fall into. Something between 0 and 255 inclusive is always a safe bet. In BASH, the variable $? is populated with the return code of the last command to return control back to the shell. It is important to preserve the return code immediately after the application exits that we want to monitor, as subsequent commands will overwrite the variable. The ping tool returns 0 on success:

HOST=”192.168.1.5″
ping -c1 ${HOST} -q 2>&1 >/dev/null  #ping HOST once and do not print any output to the screen
RET=$?¬† #assign the return code to RET so we can preserve it for after the ‘if’
if [ ${RET} -eq 0 ]; then
#we were successful.
echo “We were successful”
else
#we weren’t successful
echo “Host ${HOST} failed ping monitoring on `date`” |mail -s “Uptime Monitoring” admin@example.com
fi

Now of course there are easier ways of achieving the above task, although I’ve laid out the script in this way hoping that the way I have laid it out illustrates capturing the code and preserving it beyond the ‘if’ that follows which would have overwritten it. Just as further illustration, calling ping invalid followed directly by echo $? shows a return code of ‘2’ – obviously the return code for such a failure. Calling echo $? again immediately after shows a return code of ‘0’ as the return code of ping was overwritten by the return code of the first echo statement. Bash builtins return codes to the shell as any other application would.