Jan 01 2014

Πλαστογραφημένες δικτυακές αιτήσεις

Το Cross-Site Request Forgery δεν αποτελεί ιδιαίτερα γνωστή μέθοδο επίθεσης, αλλά να είσαστε σίγουροι ότι είναι αρκετά επικίνδυνη. Σε αυτό το άρθρο θα μάθουμε τι είναι και πώς υλοποιείται, στήνοντας το κατάλληλο δικτυακό περιβάλλον και πραγματοποιώντας μερικά ενδιαφέροντα πειράματα. Επιπρόσθετα, θα εξετάσουμε κι έναν απλό μηχανισμό άμυνας.

deltaHacker 027 (τεύχος Δεκεμβρίου 2013) | Πλαστογραφημένες δικτυακές αιτήσεις

Το Cross-Site Request Forgery (ή απλά CSRF) αποτελεί μια επίθεση που πραγματοποιείται με στόχο κάποιο ευπαθές website. Ωστόσο το θύμα αυτής της επίθεσης δεν είναι το εκάστοτε website, ούτε ο server που το φιλοξενεί, ούτε ο διαχειριστής του. Το θύμα αυτής της επίθεσης είναι κάποιος από τους χρήστες του website! Η επίθεση CSRF προβλέπει την ύπουλη αποστολή δικτυακών αιτημάτων (requests) προς κάποιο website, χωρίς τη συναίνεση του χρήστη (επισκέπτη). Εκεί κολλάει και το “request forgery” , αφού τα αιτήματα μοιάζουν να προέρχονται από τον χρήστη, ενώ στην πραγματικότητα είναι κατασκευασμένα από τον επιτιθέμενο. Τα εν λόγω αιτήματα κρύβονται σε ιστοσελίδες που έχει επίσης κατασκευάσει ο επιτιθέμενος, ενώ παραπέμπουν σε άσχετα websites. Έτσι δικαιολογείται κι ο όρος “Cross-site”, αφού η επίθεση λαμβάνει χώρα από έναν δικτυακό τόπο προς κάποιον άλλο. Όλα αυτά όμως είναι πολύ θεωρητικά. Ας δούμε για αρχή τι είναι αυτά τα δικτυακά αιτήματα και σε τι χρησιμεύουν, για να εξετάσουμε στη συνέχεια το πώς μπορούν να αξιοποιηθούν από τον επιτιθέμενο.

Διαβάστε ολόκληρο το άρθρο στο deltaHacker 027 (τεύχος Δεκεμβρίου 2013).

Το μηνιαίο περιοδικό deltaHacker είναι πλέον ηλεκτρονικό! Μάθετε για τις νέες, απίστευτες τιμές και κάντε τώρα την παραγγελία σας συμπληρώνοντας τη σχετική φόρμα.

Σημείωση για τους νέους φίλους: Δεν έχετε πάρει ακόμα συνδρομή στο περιοδικό; Δείτε αυτές τις προσφορές, μάλλον θα σας ενδιαφέρουν 🙂

Dec 25 2013

Automated testing: integrating TestRail with local QA environment

I recently completed a project with the goal of automating our functional testing infrastructure. I should actually call it semi-automation since a team of human engineers are still needed in order to build and fire test runs (which is not a downside, it was designed with that in mind). Below I will describe a rough plan for everybody who wants to do something similar. I won’t go into much details but I will surely give an overall workflow that is easy to follow.

The challenge here was mostly the integration of TestRail with the local QA environment, and this is what I am going to describe. If you don’t use TestRail, I am not sure if this will be of any benefit to you.

The tools

I suppose that to search for this article you have an idea of how to implement testing automation and have already installed some of the needed tools. In any case here are some of the tools I used:

  1. TestRail: TestRail is described as a “Test Case Management & Test Management Software Tool”, which is actually a pretty good description. You can think of it like a CMS to organize your tests. You can create different projects, categories, test suites and test cases. And then you can take some of these test suites as a whole or specific test cases and group them in what is called a “test run”. A test run is let’s say a runnable instance of the selected tests. The goal of the overall project was to automate the actual execution of each test run and report back the results to TestRail.
  2. Amazon Web Services (AWS): One or more servers where our tests would run on were needed, so some commodity EC2 instances served that need. You don’t have to buy something powerful to begin, a small EC2 instance can be enough.
  3. Selenium: In particular, Selenium Server and WebDriver, in order to run each test properly since they actually automate browser functionality and actions. Using a combination of those on the same machine you can either run the tests locally or remotely (perhaps on a cloud service like Sauce Labs or BrowserStack).
  4. Python with unittest to write the actual functional tests using the WebDriver API and py.test to execute the tests (perhaps in parallel) and get back their results.
  5. Headless Firefox, Chrome, Opera, PhantomJS and Xvfb to emulate a screen.
  6. Other standard languages/technologies like PHP, MySQL, git, cron, etc.

Integration workflow

Bear in mind that this is not what was eventually implemented (as it gets more complex down the road with multiple servers, parallel testing, etc) but it was my first working prototype and it should serve as a good basis to start with.

So here is how the TestRail integration works:

Read the rest of this entry »

Dec 20 2013

Vagrant configuration for Dionaea malware honeypot

I am happy to announce another small side-project. This time, I decided to make a Dionaea malware honeypot VM available with one command (no kidding!)

Lately, I have been playing around with Vagrant which is a fantastic tool to include in your development workflow. Apart from others, Vagrant allows you to create virtual machines and provision them using simple shell scripts or configuration management software like Chef, Puppet, etc. You can then package and distribute a VM among your team so everyone starts with the same base (no more worries about missing dependencies, different versions or platforms) or create baselines for various systems in your environment. Read here for more benefits.

In any case, I have created some simple shell scripts to automate the installation, configuration and execution of Dionaea. These three are included in a so-called Vagrantfile (Vagrant’s configuration file) which is applied to a VM upon launch. To use it, first install VirtualBox and Vagrant itself for your OS version.

The files are located in a GitHub repo here: https://github.com/ikoniaris/dionaea-vagrant

So, you can now have a working Dionaea VM up and running in minutes by simply issuing:

git clone https://github.com/ikoniaris/dionaea-vagrant && cd dionaea-vagrant
vagrant up

This will download (only the first time) a virtual disk, create a new Ubuntu 12.04 LTS VM on the fly and start it, install Dionaea and all of its dependencies and execute it as daemon along with p0f. And that’s it!

You can then login into the machine by typing “vagrant ssh” or using an SSH client (e.g. PuTTY) and connect to localhost:2222 — username: vagrant, password: vagrant. Once inside the VM, type “ifconfig” to find out the IP address assigned to the bridged adapter (eth1), which you can use to forward ports from your home router back to the VM. For a list of ports used by Dionaea type “sudo netstat -antp | grep dionaea”.

If you want to stop the machine type “vagrant halt” (on the outer terminal, not inside the machine). Every time you want to start the honeypot VM a simple “vagrant up” issued inside the dionaea-vagrant directory is enough! (hint: see the list of CLI commands for more)

Enjoy and if you have any feedback let me know!

PS. If you want to refer to this project you can use this dedicated page (will be updated soon): http://bruteforcelab.com/dionaea-vagrant

Dec 06 2013

To Kill a Centrifuge (Stuxnet Analysis)

Researcher Ralph Lagner‘s report on Stuxnet, a very informative and interesting document. Ralph has previously spoken about Stuxnet at TED as well.

Download (PDF, 3.41MB)

Video

Case Study: 10 Steps to Agile Development without Compromising Enterprise Security

Video

BlackHat USA 2012 – Owning Bad Guys (and Mafia) with Javascript Botnets

Video

Christiaan008: The Honey project and CIC News Engine

Page 10 of 30« First...89101112...2030...Last »