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
Well finally, here is the promised video…
The majority of the previous hardware issues have also now been solved which is good. The degrading CF cards was caused by a bad Alix board (I’d probably blown a resistor somewhere at some point). A replacement Alix board has arrived while I sell the other on eBay as faulty for any enthusiast who may wish to try and repair it. I am also using a SanDisk genuine SD card in an SD to CF adapter rather than some unbranded CF card. No filesystem errors and the disk now behaves as it should.
The motor controllers sometimes dropping/misinterpreting commands during heavy load was solved by a number of different fixes. Firstly, I believe with the USB to TTL converters the data lines are pulled up to 5v with a 4.7K resistor. I added a second 4.7K resistor in parallel to Tx to give the controller more of a chance against interference. I also added various smoothing capacitors, and edited my serial port byte transmit tool to restore the serial port settings graceefully on exit. Oh – I also cut the cables from their default 1m to the 12cm that I needed.. No more dropped commands.
(more…)
Tags: 4.7K resistor, alix, Alix board, DC to DC adapter, degrading CF, Linux robot, motor client, motor server, nc, netcat, parallel, sabertooth motor controllers, SD to CF adapter, smoothing capacitors, usb to ttl
Hi everyone,
As this is a relatively new blog, it’s great when we see one of our articles (http://www.adamsinfo.com/netcat-tutorial-for-linux-windows-howto-nc/) posted to the front page of linuxtoday.com.
We’ve had some great responses, and hope to get many more! Congratulations on our 10,000th unique visitor!
I’m planning to post an indepth tutorial to aircrack-ng and wireless network vulnerabilities later on today, so watch this space. As always please get in touch with any ideas or comments!
Thank you readers
Adam
Tags: adamsinfo, aircrack, Linux, netcat, tutorial
I wrote this article some time ago, but thought I’d publish it here for reference.
This text is dual licenced under the GFDL and GPL
There are two known versions of netcat. The version of netcat used here is the original Avian Research version. Not the newer GNU release
Contents:
- Netcat Basics - 1
- What is Netcat? - 1
- Netcat Syntax - 2
- Netcat Installation - 3
- What are the most basic uses? - 4
- Simple File Transfer - 4
- Tar - 5
- UDP - 6
Tags: advanced uses, command prompt, command shell, cryptcat, inetd, internetworking, ipv6, Linux, nc, nc11nt, netcat, netcat installation, netcat syntax, networking, proxy, proxying, scanning, simple file transfer, socket, spoofing, syslogd, tar, tcp, udp, windows