27 Oct 09 BASH Script – Blank Out CC Details

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

Duly spaced and indented:

Would love anyone to comment with variations.

Tags: bash, echo, grep, script, tr

18 Sep 09 Web Application Security Consultant Methodology

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.

Tags: acunetix, axunetix, burpsuite, curl, netcat, nmap, osi model, pen test, penetration test, script, Security Consultant, shell, sql, sql injection, web application, wget

09 Sep 09 Shell Return Codes – Ping Monitoring

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:

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.

Tags: bash, host, monitor, ping, return code, script, shell, shell script, uptime, variable