Information Security News |
Something I've noticed recently is that most of the websites I've been asked to assess now seem to be "new, improved, and with an API". Often the API is based on SOAP, and it's been an interesting discussion on how best to scan these new Web Services based on WSDL for vulnerabilities.
The simple way is to run the developers test suite, usually coded up as a project file in SoapUI, through BURP. However, what folks are finding is that the proxy function within SoapUI simply doesn't work, especially for HTTPS. And the SoapUI solution to get around this is pretty convoluted. The solutions that folks have generally come up with have also in some cases been complex, and most of them include the step "change the SoapUI test for this case from HTTPS to HTTP" (counting on BURP to flip it back to HTTPS). (http://ardsec.blogspot.ca/2012/08/soapui-to-burp-fuzz-away.html and http://gerionsecurity.com/2013/03/soapui-with-burp/ for instance lay out two ways to take this path).
These solutions against the grain for me, mostly because I'm lazy. If I need to update all of the test cases in an API, that's generally somewhere between 1-3 mods per API call, and when the developer comes out with the next version (as they are wont to do), I have to do all of that all over again. And if I miss one, that'll be the one that would have given me SQL injection or something else equally good.
So how do I get around this?
Simple. I use the "Invisible Proxy" feature within Burp (any other product would call this "transparent" instead of "invisible" proxy). Let's do this step by step:
You'll need two hosts - I use two VMs. Mainly because my mantra is that you really need a good reason to rn anything physical. Install SoapUI on one, and Burp on the other. I'm going to assume that these are both Windows boxes, but this works just as well with Linux of course
1/ Out of the box, run all the tests within the SoapUI project, as received from the developers
2/ Now flip out to a command prompt and dump your DNS cache, so you know which hosts are being called in the API (they're not always the hosts you think they are). In Windows, this is:
ipconfig /displaydns
or, since you just want the hostnames and IPs (in short, the actual DNS records), run:
ipconfig /displaydns | find "Record"
Many Linux hosts don't do DNS Caching, so you might need to run tcpdump and capture unique dns queries instead (or extract the DNS records used by the SOAP tests from your local DNS Server logs, but that's not as reliable)
3/ Next, on the SoapUI machine edit the local hosts file (c:\windows\system32\drivers\etc\hosts, or /etc/hosts) and add a host entry for each of the API targets. Instead of the real IP of the target, use the IP of the Burp machine, so that the Test Suite is directed at Burp.
4/ Over to Burp to the Burp machine, fire up Burp, and enable Transparent Proxy. Be sure to enable it for the address you are targeting as proxy, or enable it for everything. Also be very sure that you enable it for each port in use. I've noticed developers lately have started using not just tcp/80 and 443, but have started getting "cute" with the https ports, often using 4443, 8443, 8843 and so on. That pcap file created in step 2 might come in really handy, or you can just look at the various tests in the Test Suite to get all of these ports. You'll need a proxy set up for each tcp port in use.
For instance, setting up port 443 will look like:
and 
When you are done, your proxy Options screen should look like this â âInvisibleâ indicates a port that is proxying transparently (note that your screen will vary depending on ports in use)
5/ Back to your SoapUI machine, re-run your API tests - they'll all show nicely in the Burp Target pane!
6/ Still in Burp, everything is now set up to use Scanner, Repeater, Intruder or any of the other Burp functions. For instance, in Burp Scanner, the SOAP services above ended up with the issues listed below:
And yes, SQL injection was verified and worked, so did XML injection!
Interestingly, there is a security tab in SoapUI, where you can do some basic security tests - mostly looking for basic SQL Injection and XML Injection. Iâm still playing with this â so far Iâve been running both, and Burp is coming out ahead. However the SoapUI app is showing XSS vulnerabilties that Burp does not. Look for a second story on this after I've had some time to work it through.
Of course, the tools will only get you so far. Once you have a list of possible vulnerabilities, you still need to manually verify each one. And also of course, once you have the API all mapped out, playing with it manually (or with Repeater / Attacker and so on in Burp) will often net you your best findings.
What will you typically see? Developers are getting the idea that XSS and SQL injection are bad things, so in well run dev shops I'm seeing this easy stuff crop up less and less. However, every time I look at an API, I find this good stuff all over again. SQL injection in the API is just too much fun ! XML injection is also very common (of course) - you'll find that if you put this in your report as a finding, you'll have to add a page on what exactly that is, and how it impacts the security of the application, and in turn how it impacts the organization.
So, in short, APIs seem to be offering up the new âlow hanging fruitâ. If you've found something cool in a SOAP API, please let us know in our comment form. Or better yet, if you've found some other way to simplify proxying SoapUI through Burp or otherwise evaluating SOAP interfaces, please also let us know!
SoapUI plus Burp - it's like chocolate, but with more chocolate!
===============
Rob VandenBrink
Metafore
The list of companies suffering security breaches that spill users' password data or other personal information grew by at least two this week with disclosures from security firm Avast and music subscription service Spotify.
Prague-based Avast said its user support forum was hacked over the weekend. Attackers got access to cryptographically hashed passwords, usernames, and e-mail addresses for about 400,000 people who had accounts on the service, which was hosted on a third-party software platform. Credit card data, license numbers, and other personal information belonging to Avast customers at large were unaffected. The forum will remain offline for the time being, while the service is rebuilt and moved to a different platform.
"We realize that it is serious to have these usernames stolen and regret the concern and inconvenience it causes you," Avast CEO Vince Steckler wrote in an advisory posted Monday. "However, this is an isolated third-party system and your sensitive data remains secure."
Read 3 remaining paragraphs | Comments
A large number of people, mostly located in Australia, are reporting they have come under an unexplained attack that holds their iPhones and iPads hostage and demands they pay a $100 ransom.
The attack appears to work by compromising iCloud accounts associated with the disabled devices, according to an Apple support forum discussion that started Sunday morning and quickly accumulated several hundred posts. Commandeered devices typically emit a loud tone that's associated with a feature that helps users locate lost or stolen devices. iPhones and iPads also display the message: "Device hacked by Oleg Pliss. For unlock device, you need send voucher code by 100 usd/eur (Moneypack/Ukash/PaySafeCard) to email:[email protected] for unlock." In some cases—specifically, when a user hasn't assigned a strong passcode to a locked device—it can only be unlocked by performing a factory reset, which completely wipes all previously stored data and apps. The mass compromise is a variation on so-called ransomware scams, which initially targeted Windows PC users and earlier this month was found targeting smartphone users running Google's Android OS.
The forum accounts provide strong evidence that victims' Apple IDs and passwords have been compromised so that attackers can remotely lock connected devices using Apple's Find My iPhone service. But so far it remains unclear exactly how the attackers are compromising the iCloud accounts. While it's possible the hijackers used phishing attacks or hacked password databases to obtain the credentials, those explanations are undermined by the observation that the vast majority of victims were located in Australia and reported using a variety of e-mail providers. Typically, phishing campaigns and database compromises involving multiple providers affect users from more geographic regions.
Read 4 remaining paragraphs | Comments
Posted by InfoSec News on May 27
http://www.cio.com/article/753201/F5_Networks_Pounces_on_Fledgling_Anti_DDoS_Startup_Defense.netPosted by InfoSec News on May 27
http://www.computerworld.com/s/article/9248567/New_banking_Trojan_Zberp_offers_the_worst_of_Zeus_and_CarberpPosted by InfoSec News on May 27
http://www.nextgov.com/cybersecurity/2014/05/escalating-us-china-spying-war-mckinseys-loss-and-huaweis-gain/85216/Posted by InfoSec News on May 27
http://www.independent.co.uk/life-style/gadgets-and-tech/lulzsec-hacker-sabu-praised-by-fbi-for-helping-stop-more-than-300-cyber-attacks-9438035.html A quick note from reader James has alerted us that the anti-virus vendor avast has taken their support forum offline because it was breached this past weekend. His notice arrived over email and is pasted below. I could not find a formal notice on avast.com to corroborate, however the forums site is still unreachable at the time of this writing. There are no further details on the how the forum was breached.
I appreciate the realistic perspective communicated that 'we hash the passwords, but that does not make it fully secure'. If anyone happens to have any additional details they can share please post a comment.
Â
Dear DigiAngel,
The AVAST forum is currently offline and will remain so for a brief period. It was hacked over this past weekend and user nicknames, user names, email addresses and hashed (one-way encrypted) passwords were compromised. Even though the passwords were hashed, it could be possible for a sophisticated thief to derive many of the passwords. If you use the same password and user names to log into any other sites, please change those passwords immediately. Once our forum is back online, all users will be required to set new passwords as the compromised passwords will no longer work.
This issue only affects our community-support forum. No payment, license, or financial systems or other data were compromised.
We are now rebuilding the forum and moving it to a different software platform. When it returns, it will be faster and more secure. This forum for many years has been hosted on a third-party software platform and how the attacker breached the forum is not yet known. However, we do believe that the attack just occurred and we detected it essentially immediately.
We realize that it is serious to have these usernames stolen and regret the concern and inconvenience it causes you. However, this is an isolated third-party system and your sensitive data remains secure.
All the best,
Ondrej Vlcek
COO AVAST Software
Â
Â
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.