I just uploaded pywebfuzz version 0.6.0. There are a few improvements to the file reads happening to retrieve data in the fuzzdb.py module. The fuzzing data was also updated to reflect svn 167 of fuzzdb. Also added in this version is additions to the make_request function in the utils.py module. It now suppors expanded method support beyond GET and POST as well as error handling. You can download the updated version from here: http://code.google.com/p/pywebfuzz As always if you find bugs or problems please let me know. Thanks.
I didn’t really think this deserved an entire blog post but it was a bit too much for a Twitter post. It never ceases to amaze me that no matter how far software comes, it still has so far to go. You’d think that modern software shouldn’t break so easily. It’s just too easy to break things that are software dependent, even if that software processes credit cards every day and is PCI compliant.
I ran across these ViVOtech ViVOpay 8800 terminals at a local retailer. They look like this:
I found out that you could create a denial of service condition by performing functions out of order. The DoS is bad enough that it causes the connected computer to require a reboot. There are 4 steps:
- Swipe Card
- Hit the Ok/Accept soft button
- Sign your signature
- Hit the Ok/Accept soft button
The payment screen starts to print like it was successful then locks up (as seen in the picture above). Not sure if it would time-out at some point, the clerk I was dealing with didn’t seem to have that much patience. I verified this multiple times and the store was running out of terminals. I figured it was probably better to just pay for my product and leave.
You would think items like this would get caught in QA somewhere, but in a world of rushing products out the door it didn’t get caught. These were newer devices so I am assuming the software is recent but who knows.
It makes you think about other items you use every day and how easily you can make them fail just by modifying usage. Oh well, that’s life in a world run by software.
This year at Black Hat USA 2010 and Defcon 18 Marcin Wielgoszewski and I did a talk called Constricting the Web: Offensive Python for Web Hackers (video). The basic premise of our talk is that web architectures and technology are getting far more complicated and it is not sufficient just to run a vulnerability scanner on an application and call it done. Individuals tasked with testing these architectures are going to need to write their own tools and tests at some point. If you aren’t taking security beyond your vulnerability scanner then you aren’t performing the proper due care and due diligence required to protect your assets.
More information on tools and projects to come. I just don’t feel too much like writing today 
Write Your Own
It’s inevitable at some point you are going to have to write your own tools and tests. Modern web architectures no longer consist of a page with a simple backend web server. Complex items such as RIA technologies, APIs, aggregators, and custom protocols are now thrown in to the mix. Vendors continue to lag behind the technology curve which puts commercial tools at a disadvantage. All of these items need to be tested in order for organizations to have any type of success in their testing efforts.
This is where you take the code in to your own hands. It really isn’t as difficult as it may sound. I know quite a few people that shy away at the thought of writing their own code. I am not quite sure why there is so much apprehension about writing your own code. Maybe people are having C flashbacks from college or something.
Modern languages have quite a bit of the work already done for you. Python, which is my weapon of choice, has a vast amount of modules that allow interfacing with many different protocols. In the end all you need to do send and record your tests. Python is also a rapid development language that is easy to read and write, making it great for security people who don’t want to spend all day writing code.
Black Hat Wrap-up
We are participating in the Black Hat Wrap-up webcast. We are going to summarize our talk and highlight a few items. This is happening Thursday, August 19th at 4pm Eastern. Information on the webcast can be found here: https://www.blackhat.com/html/webcast/webcast-2010_BHUSAwrapup.html
Tools Released
We also released a couple of tools. Most notable is Marcin’s Burp API. It allows you to interface with Burp logs and turn them in to objects. This would allow you to do anything from replaying tests, creating your own macros, and even creating your own vulnerability scanner. Burp API information can be found here: http://mwielgoszewski.github.com/burpee/
I also released a stand alone encoder that I wrote a while back. The main reason was I just like having a stand alone encoder when I am doing assessments. It allows you to encode and decode values as well as wrap values with different characters. You can get more information on DharmaEncoder here: http://code.google.com/p/dharmaencoder/
Finally, I created a Python web fuzzing module called pywebfuzz. The pywebfuzz module allows you to have values available for testing from the fuzzdb project as well as some convenience functions for range generation and making requests. The module is in it’s early phases but still usable. I have a bunch of miscellaneous things I need to do to it before it is where I would like it to be. More information on pywebfuzz can be found here: http://code.google.com/p/pywebfuzz/
If you run in to bugs please let us know so we can get them fixed. If there are features you would like to be added please let us know that as well.
Conference Materials
The conference materials are posted on the Hexagon Security site. You can download them here: http://hexsec.com/docs
Ok, first order of business, I love Dropbox. If you are unfamiliar with Dropbox it is a popular cloud based syncing / storage / sharing application for your files. It allows you to store files, roll back changes, etc. You can get more familiar with them by visiting their site https://www.getdropbox.com
Now that I am done singing the praises of Dropbox, it’s time to get to the nitty gritty. This issue isn’t necessarily devastating for Dropbox, but could lead to some larger issues with other cloud based providers. The reason I am writing about this issue is because I think it can aid other individuals in the design of their applications. Let’s face it, cloud based applications and storage aren’t going anywhere.
What You Should Notice
One of the first things you should notice after installing Dropbox is that it sets up some files and folder structure for you.
A few of the folders are Documents, Photos, and Public. A couple of files that show up are This is your Dropbox.txt and if you have installed the iPhone app you get the iPhone intro.pdf. Your Public folder is where you can put files that you want to share with via a public URL.
So by default you get a Public folder with a public file that is shared called “Top Secret.txt”. If you go to the Dropbox menu you can obtain a link for the public file that has the following structure:
http://dl.dropbox.com/u/{acct number}/Top%20Secret.txt
So now you have a known resource with a known location. By simply requesting this resource and changing the account number you can enumerate through valid accounts. In doing this it will become apparent relatively quickly that account numbers are sequential. You would also notice that most people do not delete any of pre-installed default files even though they are unnecessary. These files are Dropbox’s way of communicating with you about what the folder should be for or about something the application does.
It is fairly simple to enumerate through account numbers and come up with a list of valid users, you could do this in just a couple of lines of Python code:
#!/usr/bin/env python import httplib f = open("dropbox_accts.txt", "w") for num in range(1440000, 1450000): request_string = "/u/{0}/Top%20Secret.txt".format(num) conn = httplib.HTTPConnection("dl.dropbox.com") conn.request("GET", request_string) req = conn.getresponse() if req.status == 200: print(req.status) f.write("{0}\n".format(num))
What this does is enumerate through account numbers from 1440000 to 1450000, and if there is a return on Top Secret.txt, it records the number in to a file called dropbox_accts.txt.
Why This Is A Problem
This is a problem for multiple reasons. First of all, it allows an attacker to determine valid accounts on the system. This gives an attacker a starting point for an attack on an account. Another thing to note is that it shows accounts are created sequentially which could lead to other issues.
Working on account enumeration it would be possible for an attacker or someone tracking Dropbox to determine how many new users they have per a certain period of time just by starting where they left off with their previous enumeration activities.
The issue might allow an attacker to try to obtain some information about a particular user through sifting through their public files, if they were guessed. Yes, an attacker would have to guess the name of a valid file but we as humans tend to name files descriptively, so it may be easier than it seems. There is no randomness attached to the filename /URI that would deter this type of activity. After sifting through this data it may be possible to determine the name of the individual who owns the account. Another thing you might find from this activity is an email address associated with the login of the account. If they were to obtain the email they would have the login (email), account number, and the person’s real name. It would not completely out of the question to find something like resume.doc in a user’s Public folder. This is a lot more than an attacker should have.
Now this shouldn’t be a huge deal because it is a “public” folder, it should be assumed that everything in there could be accessed by anyone, but people don’t always make the best choices when it comes to sharing. Many people who use Dropbox use this folder to share things with their friends, not the entire world.
Probably most important, is that they are using known resources and locations. This can be a particularly bad issue for cloud based applications due to their public nature. Every Dropbox account has several folders set up by default along with several files added. These rarely get changed and just get utilized by users. Giving an attacker known resources and locations goes a long way to a successful attack. It allows an attacker to gauge success or failure of a given attack and gives them ready-made resources on which to focus their attacks.
Dropbox uses these files in their private directory structure as well, which opens the doors for some interesting possibilities. I have not really dug in to their API or too much in to their web interface to really say where this might be an issue, but the groundwork can be done in relatively small period of time.
Without having any kind of knowledge how the back end of Dropbox works, it’s hard to tell whether any of the information (ie Account Number) that can be be enumerated can be used to attack user files at rest. It may be hugely important or totally innocuous. I am assuming they have probably thought of this, but you never know.
What’s The Takeaway
People designing cloud based applications and storage should be aware that creating items with known locations could increase their attack surface by giving attackers something to work with. This should be kept to a minimum. Users should be defining the structure of their storage and setting up names for their resources. If you need to communicate with users, it should be done in a message format vs leaving a standard named file in a known location.
Public resources, even though they are public should have some form of randomness added to their resource locations. This way, it is not extremely easy for an attacker to enumerate resources and gain information about the application and its users. It would be a better idea to take the approach that Flickr does with it’s randomized URLs for photos. That way it is not easy to map a resource to a given user or account number.
When numbers associated with accounts are exposed, they should take on some form of randomness or there should at least not be any exposed method that would allow someone to enumerate through them easily.
Threat modeling should be done on the application during the design phase allowing for the identification of issues before they get worked in to production. Always think about how the application could be abused. You would think this would be second nature by now, but so many organizations are not doing this.
If you are Dropbox user you should delete the default files that are created by Dropbox, especially the Top Secret.txt that is in your Public folder.
In Closing
In closing not extremely devastating on the surface for Dropbox, but definitely food for thought for anyone working on the design of cloud based applications. Issues like this are definitely not isolated to Dropbox. I wrote a tool about a year and a half ago (that I had forgotten about by the way) for pulling valid users and data out of Apple’s MobileMe service. An issue that still exists to this day. Cloud providers need to be thinking about this stuff in the design phase because it is hard to make changes after deployment.
I will be speaking at MITRE’s Social Media Strategy and Implementation Workshop in the Washington, DC area on September 28th. My topic is Attacking Social Networks. The goal of the talk is to show some of the darker aspects of social networking. These will be items and attack vectors that people may not be thinking about. Believe it or not some people are still oblivious to common social network attacks 
If you are in the DC area stop on by.
I haven’t really written much about Python lately. I have a feeling that is about to change Python is great because it is powerful and allows you to do things very quickly. I figured I would write a short post to show how to remove duplicates by just using the set type. This is probably the quickest and easiest way of removing duplicates in Python.
I don’t think I need to get in to how useful it can be to easily remove duplicates. I have used this many times in the past for doing everything from removing duplicate values from a list of SQL Injection checks to just determining how many unique occurrences I have for a given test.
set
Python has a type called a set. A set is basically an unordered collection of unique values. You can create a set by specifying a new empty set and adding values to it or by converting another type. The set conversion can be done over any iterable object.
Create a new empty set called myset:
myset = set()
You can add values to your set by using add or update:
myset.add("hello") myset.update("world")
Convert another type to a set called newset:
newset = set(another_type)
Sets in Python are nice for a couple of reasons. The first being they only keep unique values. This means that any type you convert to a set or anything you add to a set is unique. It will discard duplicate values. Secondly, you can test for membership in the set. Testing for membership will give you a True / False response based on whether a value exists in the set.
Here are some examples
Converting a list to a set.
Even strings are iterable objects in Python. String conversion to set.
The following shows True / False values for membership tests from the previous string conversion.
Practical Example
Let’s say you wanted to write a small program that took a file, removed the duplicates, and created a new file with only unique values. The file that contains the duplicates has one value per line, which means there is a newline at the end of each item. You want to maintain the newline in the new unique file that you are writing to as well. You will see the newlines in the following specified by “\n”.
The following is an example:
#!/usr/bin/env python import sys if len(sys.argv) < 3: print "Usage: remove_dups.py original_file.txt unique_file.txt" sys.exit(1) file1 = open(sys.argv[1]) file2 = open(sys.argv[2], "w") unique = set(file1.read().split("\n")) file2.write("".join([line + "\n" for line in unique])) file2.close()
I will explain a bit of what’s happening here. Let’s say we have copied this in to a file called remove_dups.py. This program takes two arguments, your original file and the name of the file you want to create without the duplicates. If it doesn’t have the two arguments the program exits.
Next both files are opened, with the second file opened for writing. The first file is read in splitting on newlines. The unique variable now contains the unique values. We then write to the second file every line concatenating a newline on the end. This makes the second file contain the unique values one per line.
You now now how to remove duplicates in Python using the set type. Knowing is half the battle
Update
I wrote this post very quickly and didn’t explain about my use of read() vs using readlines(). Marcin pointed out yesterday that it wasn’t clear. I wanted to show how you could use read() and split on newline characters. My hope was that you would see how you could split on any character when reading a file like commas, semicolons, asterisks, or anything really.
In the code example above, if you wanted to read in a file per line instead of splitting on the “\n” character you could just use readlines() instead.
MonkeyFist is a dynamic request attack tool. It allows you to do some interesting things with various forms of cross-site requests and play them back to the user’s browser. These requests may contain session information bypassing Cross-Site Request Forgery protection mechanisms. It’s really a lot more simple than it seems.
MonkeyFist is basically a small web server that performs some attacks on the data it receives based on information you provide in the payloads.xml file. To do a deeper dive in to the issues that MonkeyFist exploits you can refer to the white paper we wrote prior to Black Hat on Dynamic CSRF located on the docs page of Hexsec http://hexsec.com/docs
The best way to get familiar with MonkeyFist is just to dive right in. If you haven’t done so, you can go here to download it from the Hexsec Labs page http://hexsec.com/labs
MonkeyFist requires you be intimately familiar with the request you want to forge. This should be painfully obvious because you need to tell the tool how to construct the request in order for it to be successful.
The Files
There isn’t much to MonkeyFist, all of the files are pretty small. There are a few items in the zip file, but you really only need to worry about MonkeyFist.py and payloads.xml. All of the configuration for payloads in MonkeyFist is done through payloads.xml. We will get in to syntax in another post. In case you didn’t notice the .py extension, MonkeyFist is written in Python. So if your operating system doesn’t have Python installed (Probably just Windows systems) you are going to need it. I suggest version 2.5 or greater. The version that comes with most Linux distributions and OSX is fine. As a final note about the files, ensure that you run MonkeyFist from the same directory as the other files that come with it. Otherwise, it won’t know where they are located
Dependencies
In the beginning there were no further dependencies but I a saw it was necessary to potentially need to do some more complex parsing for the fixation payload. For that reason I decided to add lxml. I could have gotten away with a more simple parser, but was trying to think ahead a bit. To use the Fixation payload you are going to need to install a 2.x version of lxml. This would be different depending on your operating system. If you are using Ubuntu / Debian don’t just to to apt install lxml, it will give you an old version. Python setuptools helps a lot, it’s just a good idea to use that anyway.
For OSX Leopard (Make sure you have the development tools installed) I just ran:
sudo easy_install lxml
For Ubuntu you have to take a few other steps because you need a few dependencies and the development headers for Python.
If you don’t have setuptools installed:
sudo apt-get install python-setuptools
Then you need to apt-get install the following if you do not have them installed:
libxml2-dev
libxslt1-dev
python2.5-dev
After that you can go ahead and:
sudo easy_install lxml
If you have build problems you probably don’t have the build tools installed:
sudo apt-get install build-essential
Then run easy_install again.
If you decide not to run lxml or do not have the ability to install it, the tool will still run you just won’t be able to use the Fixation handler without a nice failure and error message
Payload Types
There are several types of payloads you can construct with MonkeyFist. Each of these would depend on what the goal of the attack would be or the type of content on a site you would have control over. The basic payload types are dynamic redirect, POST construct, dynamic page, and fixation.
Dynamic Redirect
The dynamic redirect payload simply parses any cross-domain information looking for session data to dynamically construct in to a GET based payload to send back to the user’s browser. Basically, the user would request something and the tool would respond with a 302 redirect to a location. The location value would be the constructed payload. The user’s browser would just request content like normal and follow the redirect and execute the payload.
This payload type is best used in instances where you have the ability to add images tags or other HTML to a site. This way it could be relatively hidden from a user’s browser.
Dynamic Page
This payload constructs a page that performs several functions depending on what type of attack you are performing. You can either have the page perform a GET or a POST for an attack. Both the GET and POST types will be submitted by the user’s browser. So what does the page do? The attack that you construct gets embedded in the page and after the attack happens the user is immediately redirected to a location of your choice. So you could perform an attack and immediately send someone to the Benny Lava video This could be combined with an URL shortener for further obfuscation.
This payload is best used in instances where you have the ability to embed hyperlinks to pages. Another thing to note about the dynamic page payload is that it makes POST based CSRF a whole lot easier to pull off. If you thought submitted data as a POST was a protection mechanism for CSRF you might want to rethink you point of view
POST Construct
This payload is a bit different because the POST request is made by the tool and not the user’s browser. This needs to be kept in mind when using it. You will not have the advantage of the browser being helpful and submitting header information. If the cross-domain leakage is enough that you can perform an entire POST request without the user’s browser then this payload can be used. Otherwise, it will be pretty useless to you
Fixation
The fixation payload allows you to make a request for data that you fixate on to the attack you send to the user. This is still experimental and only works in some narrow situations. This will be expanded later. This works as a modified page payload that performs and extra request and parses the response and gains the necessary information to perform the attack. This would be commonly used to make a request for tokens that you can fixate on to a request forged by the user’s browser.
Default Payload
The default payload gets matched when there is no cross-domain information for the tool to match with your entries in the payloads.xml file. It’s best to not perform an attack with this The best thing to do is to make this a link to some real content like an image. This can make the tool a bit more stealthy.
You need to specify a default payload. Not doing so would be like crossing the streams. Well maybe not that bad, but it wouldn’t be good.
MonkeyFist Running Options
There are only a couple of running options with MF and well, all of them do not work as of yet. So, the main one you need to be familiar with is -s. This is the standard attack mode. The -p option specifies the port you would like MF to run on. You won’t need privileged access unless you are trying to run on a low order port. The following would run MonkeyFist on port 8080 using standard attack mode:
./MonkeyFist -p 8080 -s
You can get the about information by running -a, just in case you were curious about what version you are running.
./MonkeyFist -a
Of course, if you need some reference there is always the ole’ help with -h
./MonkeyFist -h
There are a couple of other options that are planned for the future. A testing mode and a random mode will be added as well, but currently, they are not implemented.
Payloads
The payloads.xml file is where you define your attacks. This is where all of your work will be done. The exact options that are specified in this file are still being worked out. This is because as content goes, there needs to be flexibility when identifying these issues. There is a basic set of options that allow you to pull of some attacks even as MonkeyFist sits at version 0.4. Expect some changes in these options. The payloads.xml file will be covered in more detail in a future post.
The Others
You will notice a few other files in the MonkeyFist zip file. You might not want to delete them or you may have some unintended consequences. The page2.html file is blank, but it won’t be if you pull off any Page attacks. Contents are put in to this file dynamically and change per attack. Markup.py is something I didn’t write, it just allowed me to quickly generate some HTML. This was before I made the decision to use lxml. For now I am going to leave it in there, even though it is not the best option. FistLib.py is the most important. This is the workhorse that takes care of all the work.
In Closing
I think that’s it for a small intro on MonkeyFist. In future posts I will explain more about the payloads and how they are constructed. If you notice any problems while running MF please let me know. You can send an email to monkeyfist {at} hexsec {dot} com. This is still a work in progress so please don’t beat me up too bad. I do welcome your feedback though. Thanks.
Bypassing CSRF Protections With Dynamic CSRF
At our presentation at Black Hat and Defcon this year, Shawn Moyer and I gave a talk called Weaponizing the Web: More Attacks on User Generated Content. During the talk we discussed something we are calling Dynamic Cross-Site Request Forgery (CSRF). Dynamic CSRF methods can be used to create new attack vectors and compromise CSRF protection mechanisms. CSRF is often difficult to explain in the first place, so I just wanted to do a post about it and link our Dynamic CSRF White Paper.
Static CSRF Attacks
The current way people are exploiting CSRF issues is pretty static. A link may be crafted and people are tricked in to clicking on it or viewing a page with this link embedded. They may even do something such as create an auto-submitting POST that the user executes when visiting certain content. The moral is that someone crafts this attack for a specific location and chooses a vector for delivering it to users. On it’s own, this static CSRF attack method can be pretty devastating or perhaps totally innocuous. That’s just the nature of CSRF. There aren’t too many vulnerabilities that fall in to this category, which may be why it can sometimes be hard to understand.
Let’s just think about some things that would make CSRF even more dangerous. What if we had visibility in to CSRF tokens or even session identifiers? What if we knew for sure a user was on the site that we wanted to attack? What if we could use a central point to dynamically attack multiple sites? What if we could create a custom payload on the fly to include tokens and session data? What if we could request data in another process and fixate it on to a request that the user executes? CSRF would become much more dangerous. Well, it just did….
Dynamic CSRF Attacks
With Dynamic CSRF attacks the game changes a bit. Attacks can be adapted based on where requests are originating from. Sensitive information sent in a cross-domain fashion can be packaged in to a customized payload and sent to a location. Disjoined or bolted on components can be queried and fixated on to a user’s request. This opens up new opportunities for attacks. Dynamic CSRF allows you to run one central system and run attacks for multiple sites and applications with the ability to remove and repackage any leaked session information.
Using dynamic methods may allow for the bypass of CSRF protections. Whether these protections are leaked in the referer or if they can be requested by other means and fixated on to the request, bypassing may be possible. This makes requests that were previously not vulnerable to CSRF vulnerable again.
When not limited by static requests a few new attack vectors open up. I just wanted to highlight a couple here.
Getting Dynamic
In the next couple of sections I am going to point out some dynamic methods for bypassing CSRF protection mechanisms.
HTTP Redirect
A simple redirect attack can be made more devastating with the addition of session related data added to the request. So a user hits a piece of HTML on a web page that sends a GET request containing session data (Session IDs, CSRF Tokens, etc) in the referer. This session data can be taken from the referer and repackaged in to a payload that is sent to the users browser as a location for a 302 redirect.
A scenario for this type of attack might be embedding a hidden image tag that links to a location offsite. This image tag may leak session data through referer allowing a tool to repackage that session data and get the user’s browser to execute it as a payload. This could be used to bypass CSRF protections by using the CSRF tokens from the referer.
HTML-based Redirect
For this scenario a hyperlink could point to a page that is created dynamically per-each request. This page contains a hidden GET or POST that could contain session data taken from referer as mentioned previously in the HTTP Redirect. The page would then refresh to a legitimate destination. To a user there would only appear to be a short pause prior to their landing on the legitimate destination, but in the background an attack has happened.
This attack could be made more interesting with URL shortening services. People have become accustomed to URL shorteners due to their use of Twitter and other social networks. Using a URL shortener would mask the location of the dynamic page and may not raise further suspicion.
A scenario for this would be posting a link that is shortened with a URL shortener on a web site that supposedly links to a video on YouTube. When the user clicks the link a hidden action (GET or POST) is executed. After the hidden action takes place, the browser does a refresh to the expected destination (the YouTube video). The victim may get little or no indication that the hidden attack has happened.
Fixation Based Attacks
Here is where things get a bit interesting. This attack hinges on the ability to have a valid CSRF token and a valid session identifier, but those two values aren’t associated together from a session perspective. Say you are posting on a message board. This message board issues you a Session ID in a cookie and also issues you a token for use when posting. If these two values aren’t linked from a session perspective, it would allow for any valid token to be added to the request. Since the Session ID is in the cookie value, if a forged request had a valid token appended this would bypass CSRF protections.
What makes this fixation attack an interesting scenario is it requires no leaking of any session data in a cross domain fashion. As long as you have some visibility to the token, it can be requested and fixated to the request.
Other Scenarios
There are other scenarios as well. It really depends on how much session data gets leaked in a cross-domain fashion. For example, if the full session ID is leaked, there could be some real problems. It could allow for a tool to construct any GET or any POST to the target application.
MonkeyFist
MonkeyFist is a tool I wrote to PoC Dynamic CSRF attacks. The tool runs as a small service on a system listening for all incoming input. When it receives a request it looks in the referer to determine where the request is coming from. It then uses this information to parse a payloads file and look for the specific attack to construct for that domain. You can have multiple entries in the payloads file performing multiple types of attacks. Redirect, POST, Page (GET and POST) and an Experimental Fixation handler are all included in the application. You can learn more about MonkeyFist on the the Hexsec Labs page. It is not exactly where I would like it to be, but it works. More streamlining and modifications will come soon. I am still recovering from Black Hat and Defcon
I have some posts on MonkeyFist that are coming soon as well.
More Info
That’s it for a quick intro to Dynamic CSRF. If you would like more information you can read our white paper which is available here.
The Black Hat 2009 Sneak Peek is this Thursday. Black Hat is going to be giving a sneak peek of talks that they feel are interesting from their 2009 lineup. We are glad, once again, they have found one of our talks interesting enough to include in their sneak peek, especially given the lineup. Not sure why they picked our talk, but we will do our best not to let them down We will be discussing our talk called Weaponizing the Web: More Attacks on User-Generated Content. If you would like more information or would like to register for the webcast you can do so here
Hello Everyone. I just thought I would drop a quick note. Shawn Moyer and I are speaking at Black Hat US 2009. Our talk is called Weaponizing the Web: More Attacks on User Generated Content. We are going to be talking about attacking sites with user controlled content. In the modern web environment, that’s a whole lot of sites. This content can be turned around and used against the site, the user, or other sites.
If you are going to be out at Black Hat this year also check out Michael Murphy and Aaron LeMasters’ talk Rapid Enterprise Triaging(RETRI). Mike and Aaron are fellow members of Hexsec. Anyway, that’s all for now.
