Most of you that are pentesters may have already tested plenty of webservices
using SOAP (Simple Object Access Protocol)* *for communication. Typically,
such SOAP messages are transferred over HTTP (Hypertext Transfer Protocol) and
are encapsulated in XML (*Extensible Markup Language*). Microsoft has developed
different representations of this protocols to reduce the network load. As these
representations/protocols aren’t really covered by typical tools out there, this
post will show you some of them, and a proxy which can be used to simplify the
testing.
I’ve recently found some sort of classic web vulnerabilities in the Google
Search Appliance (GSA) and as they are now fixed [0][1][2], I’d like to
share them with you.
First of all, some infrastructure details about the GSA itself. The GSA is used
by companies to apply the Google search algorithms to their internal documents
without publishing them to cloud providers. To accomplish this task, the GSA
provides multiple interfaces including a search interface, an administrative
interface and multiple interfaces to index the organization’s data.
The current trend of social coding finally arrived at ERNW! From now on, you
will find our public released tools and scripts commonly
on https://github.com/ernw. Therefore I would like to
share some thoughts/guidelines which you have to keep in mind if you want to be
a social coder:
Github and other repository hosts are great if you want to share opensource
tools with the community, as they will find a common platform with defined
workflows to extend/fix the work to get better software for everyone. What some
should note is that (especially in terms of decentralized version control
systems (DVCSs) like git, bazaar or mercurial) public really means public. Back
in earlier days, if you shared your code with others you probably created a
source code package of a defined version of your code. They will get the files
you published, nothing more (and nothing less). Beginning with websites like
sourceforge, a broader range of public VCSs came up (mostly driven by CVS or
SVN). At this time, others were able to view your commit history (if you granted
access to them) and all your mistakes you’ve done before your published code
state (for example accidentally committed sensitive data). Those mistakes can
still happen today. The difference with the DVCS used nowadays is that most of
the time you have lesser control of your commit history (in the same way if
someone had copied your history commit by commit in SVN, but then you may had
noticed it because of the high network traffic). With DVCS, everyone gets a full
copy (clone) of your repository even on a simple “checkout” (as called in SVN).
This means he/she is able to search your history locally and has all the time
he/she needs to do it. Even if you delete your repository (or modify the
history), the original state is shared over all who have cloned it beforehand
(thats one reason why DMCA takedowns are not that powerful/useful against git
repositories). Most of the public hosting platforms even included a search over
all repositories (which is really useful if you want to find some tool or try to
find the reason why a local tool doesn’t work).
Python has reached a defacto standard in exploit development lifecycles and most
of the proof of concept tools you’ll find out there are written in Python
(besides the metasploit framework, which is written in Ruby). Python allows to
write scripts handling with remote services, fiddling with binary data and
interacting with C libraries (or Java in case of Jython/.Net in IronPython) in a
fast and easy way. The huge standard library with it’s “battery included”
principle removes some of the dependency hell known from other
frameworks/languages. I want to share some of my python coding experiences with
you, and maybe this could give some helpful tips for your future work, to make
the world a bit safer 🙂 (PS: most of the examples are written in Python 3.x or
compatible to both Python branches).
With HTML 5 the current web development moves from server side generated content
and layout to client side generated. Most of the so called HTML5 powered
websites use JavaScript and CSS for generating beautiful looking and responsive
user experiences. This ultimately leads to the point were developers want to
include or request third-party resources. Unfortunately all current browsers
prevent scripts to request external resources through a security feature called
the Same-Origin-Policy. This policy specifies that client side code could only
request resources from the domain being executed from. This means that a script
from example.com can not load a resource from google.com via
AJAX(XHR/XmlHttpRequest).
In a .NET environment WCF services can use the proprietary WCF binary XML
protocol described
here.
Microsoft uses this protocol to save some time parsing the transmitted XML data.
If you have to (pen-) test such services, it would be nice to read (and modify)
the communication between (for example) clients and servers. One possibility is
Fiddler.
Fiddler’s strengths include its extensibility and its WCF binary plugins. Sadly,
these plugins can only decode and display the binary content as XML text.
One of our favorite tools for conducting penetration tests (especially, but not
only, web application tests) is
Portswiggers’s Burp Suite. Burp
allows to extend its features by writing own plugins. But because Burp is
written in Java, it only supports Java classes as plugins. Additionally, Burp
only allows to use one plugin at the same time which has to be loaded on
start-up.
Now we have written a Burp-Python proxy (called pyBurp) which adds some
features to the plugin system:
