anonymous real

Surviving the Week 12/28/12

The 2012 Web Session Intelligence & Security Report: Business Logic Abuse Edition

The business logic abuse scenarios presented by the Ponemon Institue are web scraping, account hijacking, click fraud, botnets causing denial of service, electronic wallet exploitation, coupon abuse, testing stolen credit cards, mobile device malware to take over customer accounts, app store/marketplace fraud, and mass registration.

NT OBJECTives provides a white paper on “Attacking and Exploiting the Top 10 Business Logic Attack Vectors” at –

Tool to Decrypt TruCrypt and PGP

ElcomSoft has built a utility that combs for encryption keys in snapshots of a PC’s memory to decrypt PGP and TrueCrypt-protected data.

ElcomSoft’s gear can extract these decryption keys from a copy of the computer’s memory, typically captured using a forensic tool or acquired over Firewire.

Croatian Banks Hacked by Anonymous

anonymous realAnonymous Croatia hacking crew defaced the websites of two Croatian Banks: Karlovacka Banka and Samoborska Banka.

The hackers left a message saying: “We are Anonymous. We don’t forgive. We don’t forget. You were stealing enough from people. Soon the other banks will fall”.


Security Researchers Identify Malware Infecting U.S. Banks

Security researchers from Symantec have identified an information-stealing Trojan program that was used to infect computer servers belonging to various U.S. financial institutions.

Dubbed Stabuniq, the Trojan program was found on mail servers, firewalls, proxy servers, and gateways belonging to U.S. financial institutions, including banking firms and credit unions, Symantec software engineer Fred Gutierrez said Friday in a blog post.

3,000,000 Verizon Wireless Accounts Leaked

A report surfaced this week that Verizon Wireless, a premier mobile carrier in the United States has been breached, with a result of three million customers being compromised. While the number may seem large, it represents a small fraction of the company’s user base.


html5 i am the future i am the browser

Surviving the Week 12/21/12

HTML5 Definition Complete, W3C Moves to Interoperability Testing and Performance

html5 i am the future i am the browser

The 5th revision of HTML is regarded as the future of web markup language. The long awaited specs for HTML5 have been finalized. This week, W3C published the complete definition of the HTML5 and Canvas 2D specifications. –

Multiple Vulnerabilities During the Week

Joomla ZtAutoLink Local File Inclusion –
Kiwi Syslog Web Access 1.4.4 SQL Injection –
Free Hosting Manager 2.0.2 Cross Site Scripting –
Banana Dance B.2.6 Inclusion / Access Control / SQL Injection –
Elite Bulletin Board 2.1.21 SQL Injection –
Drupal Core 6.x / 7.x Access Bypass / Code Execution –
SurgeFTP Remote Command Execution –
Cerberus FTP Server Cross Site Scripting –
TWiki 5.1.2 Command Execution –
D-Link DCS-9xx Password Disclosure –
Centreon 2.3.x SQL Injection –
phpwcms Remote Code Execution –

shreeraj shah presenting

XSS & CSRF with HTML5 – Attack, Exploit, and Defense (OWASP AppSecUSA Presentation Review)

shreeraj shah presentingThis very useful talk was as much an education in HTML5 for me as it was an education on how HTML5 can be abused. I am coming up to speed on HTML5 concepts.

Shreeraj Shah (@Shreeraj) Founder and Director of BlueInfy presented this talk, XSS and CSRF with HTML5 – Attack, exploit, and Defense, presented by

HTML5. It is tempting to think it would be designed with all the security knowledge acquired from its predecessor incorporated into its design and there are indeed efforts toward that reflected in the design. But any security veteran would suspect that nonetheless there are clever things that can be done and of course there are.

With XHR2, it is possible to contrive a cross origin tunnel that is amenable to CSRF. One overarching concept in HTML5 is Same Origin Policy (SOP) which as it turns out can be circumvented. img, script, and iframe evade SOP so attack payloads can be inserted in those tags. A dummy form with the attack payload in the POST can also be used to circumvent mechanisms that would otherwise catch it. Cookie replay can be forced by “withCredentials.”

I gather from this talk that XHR1 is not versatile enough to be useful as an attack, one must generally use XHR2. CORS (Cross Origin Resource Sharing) combined with XHR can allow for posting whatever (i.e. attacks) across domain. The push_state function can allow changing the address bar programatically. Defenses against attacks include Content Security Policy. Script src ‘self’ will prevent XSS. HTML5 also includes threading and messages that can be sent to other threads within the app; so the countermeasure for this is to write the app in such a way that it checks origin before posting the message.

My conclusions on this talk besides it being a very well done talk are that I need to get very familiar with HTML5 and probably code up a simple app in it that exercises the concepts.  Another talk given by Dan Kuykendall, the co-CEO of NTO (see my review elsewhere) shows quite vividly that a great many of the new software technologies (JSON, AJAX, REST, AMF, etc) are really just pushing the fruit deeper but once you get the fruit, the injection and perturbation techniques for attacking it are largely the same. This talk is a fine counterpoint to that one insofar as it addresses the architectural concerns that come with these new software technologies… i.e. the context in which the fruit is exploited.

Dan Kuykendall B-Sides

Get Off Your AMF & Don’t REST on JSON (OWASP AppSecUSA Presentation Review)

First off, in the spirit of full disclosure, two points: One is that this talk took place at the same time as the Shreeraj Shah talk I attended, but I did indeed effectively attend this talk as Dan presented it to me and one other employee of our company, NT OBJECTives after the conference.  And point two is: this is because Dan is the co-CEO of NTO of which I am an employee (lead software architect). So the usual caveats of conflict of interest or “of course he is going to write a positive review” apply but to that I would say that as a borderline autistic nerd of dubious social skills (i.e. guile), I’m not that good of an actor. So I am delighted that I can say sincerely that this talk was very informative and rivaling the others in that regard without having to run to the toilet afterwards.

Dan Kuykendall B-Sides

The fundamental theses of this talk are that the data to be perturbed for purposes of attack has gone deeper into the new protocols being employed to write web applications and also that a lot of these applications are for new technologies like mobile phones and as such the developers of the applications for these devices are making silly mistakes that secure-coding veterans of more conventional client-server platforms know to avoid. Or to state that latter one another way, with every new platform comes an opportunity to make the same old mistakes. On the former, whereas in previous years all one had to worry about were html query parameters, form inputs, and cookies (and the odd custom this that or the other), now there are JSON, AJAX, AMF, SOAP, REST, GWT-RPC, etc. and in several mobile apps there are proprietary binary data transports to worry about.

The business logic layer between the JSON, AJAX, etc. and the database is typically rather lax in security and often vulnerable to SQL injection attacks. AMF is a binary format but a quite well known one (by myself in particular, I wrote the parser for it in the new release of NTOSpider). Burp proxy shows the contents of AMF packets and it is easy to perturb string values with, for example, a SQL injection attack before forwarding the request on to the server. JSON and AJAX are more human readable than AMF and so they also are easy to attack. REST is more of a loosely defined suite of protocols all of which can be attacked in a conceptually similar way.

These new protocols do not necessarily retain the name=value paradigm in the strictest sense but with all of them one can recognize strings into which attack payloads can be inserted. The other half of the talk was an eye opening account of how easy it is to hack mobile apps. Passwords are often weak because people do not want to type elaborate passwords on a mobile phone, particularly where you have to switch between alpha and num several times which you do for a strong password.

Many apps are very stupidly written to use the phone’s MEID (the simcard ID with which the phone id’s you to the provider) as the authentication key. These are easily snooped. Even worse, some apps make the token gesture of asking for a password and then do not bother hashing it with the MEID. Effectively, the developers themselves have trojaned your mobile phone. Further, again to promote usability, session tokens often never expire.

So combined with these other vulnerabilities and the fact that some apps send info unencrypted as well, one can simply stroll around a shopping mall collecting MEIDs and session ids and then do whatever appearing to the server as these various users. There is a particular mobile phone app called bump which makes it easy to share contact information. Lovely idea but they use the GPS coordinates and not much else for authentication so one can fake GPS coordinates, intercept this traffic, and send errors to the phones in question which causes (likely) the users to rebump at which point you are the man in the middle snooping their personal information. A malicious URL can even be injected which allows for obtaining remote shell on the mobile device. The talk concludes by noting that 32% of apps are SQL injection vulnerable and that WAFs have not caught up with JSON, REST, AMF, and so forth.

The conclusions I come away with from this talk are many. Having worked on NTOSpider 6.0 which works with most of these new protocols, I was already keenly aware (and relieved) that attacking them is really just a matter of digging a little deeper for the fruit to attack as opposed to being some hugely intractable AI problem which means also that CSOs can and should still incorporate the use of automatic scanners (that are aware of the protocols) as part of their security strategy.

This is good for us at NTO and good for the industry in general as I don’t think anybody wants to give up the efficiency of automatic scanning and transition into a regime where the only way to ensure security is with hugely expensive manual pen testing and nothing else. Further, when there is a new platform despite it being basically the same as preceding platforms under the glamorous facade (mobile computer in your pocket, ooh aah, but still basically client-server), there is a taking a few steps backward before taking steps forward with such things as weak passwords, unencrypted transmission, bad authentication schemes, unvalidated inputs, etc. Security is in a lot of ways a “the more things change the more they stay the same” game.

There is more detailed information on this topic in our new whitepaper, The Widening Web Application Security Scanner coverage Gap in RIA, Mobile and Web Services.

Recorded presentation from 2012 OWASP AppSec USA “Get Off Your AMF and Don’t REST on JSON” by Dan Kuykendall.


Scott Sutherland NetSpi

SQL Server Exploitation (OWASP AppSecUSA Presentation Review)

Scott Sutherland NetSpiSQL Server Exploitation, Escalation, and Pilfering

The general thesis of this talk I attended by Scott Sutherland and Antti Rantasaari from @NetSpi is that SQL Server is mostly very well designed with respect to security so that most of the vulnerabilities are due to careless configuration… which abounds in the wild. Further, being integrated with the Windows operating system, that makes it open to approaches that use Windows API calls.

Often people use weak passwords, unencrypted connections, and same privilege levels for SQL Server as some easily hackable user domain for the convenience of the DBA and/or developers and then nobody bothers to change this when the application goes live. Another common thing people do is to put a blog on the same privilege level as the portion of the website that is to be PCI compliant. This rather begs the question of whether it is PCI compliant… if with the letter then certainly not with the spirit since blogs of course tend to be very susceptible to XSS and SQL injection and thus the “PCI compliant” portion of the site can likely be DB-enumerated as well once the blog is compromised.

The talk went into details of how to use Metasploit to hack vulnerable SQL server instances and execute SQL queries and even obtain command shells. For World War II history enthusiasts, this all has a familiar ring to it. The German Enigma machine coded messages were theoretically unhackable but the Bletchley Park team exploited human weaknesses in the form of sloppy use of the system that compromised its entropy. That seems to characterize most SQL Server exploits and underscores the need for an enterprise to be very regimented about sequestering off the dev environment and the dev test site where all the security is lax to expedite development from the live environment where everything needs to be properly locked down.

Ofer Maor

I>S+D! – Interactive Application Security Testing (IAST), Beyond SAST/DAST (OWASP AppSecUSA Presentation Review)

Ofer MaorThis talk, by Ofer Maor, CTO – Quotium (Follow on Twitter, @quotium) at 2012 AppSecUSA, addressed something that I see is an up and coming issue, interactive in-memory code testing. There are several talks about it and there is a lot of ambient chatter about this in the security community. As one who works for a company that offers an automatic application security (DAST) tool that prides itself on being as automatic as possible, I have a very particular perspective on this. Specifically, the idea that manual or partially manual security testing reasserts itself in each new generation of test paradigms.

In this case, rather than running a tool that looks for potential buffer overflows and other such things by grammatically analysing source code and then relying entirely on its report, one (possibly in addition to that) runs a tool that hooks the program dynamically and observes the behaviour as it happens and guides the tool to the next attack accordingly. At NTO, we have tried to avoid requiring user interaction as much as possible using it only when absolutely necessary, and our tool is a web application scanner, not a source or binary code analyser (not specifically that though it does do a bit of that in order to get deeper into the site). So our tool is analogous to what the speaker calls static and dynamic source code analysis. In the field of static source code analysis, until someone comes up with some super magic halting-problem-paradox-violating source code analysis algorithm, I am inclined to buy into the speaker’s implicit assertion that rather a lot of user (pen-tester) interaction with the tool may be necessary to maximize results on code reviews.

So the speaker’s tool is not a static or dynamic one, but an interactive code analyser. The calls that can be hooked by the speaker’s tool include HTTP request/responses, database queries, file system calls, string operations, memory, 3rd party libraries, external app calls, etc. It is binary based as opposed to source code based and therefore needs a good database of api calls and such to hook. Probably the definitive example, though certainly not the only one, of what one can do with the speaker’s tool is tainted input tracking… following an SQL injection (for example) through all stages of its propagation down to the database.

I was very impressed with the technical achievement that this speaker’s tool represents. And I agree with the implicit notion that no particular paradigm (automatic black box testing, fully manual pen-testing, tool-assisted semi-manual pen-testing) is entirely sufficient to maximize security. They need to be used in concert. If budget prescribes a triage approach to security however, I would say an automatic tool doing blackbox testing of Low Hanging Fruit is likely to achieve the greatest coverage within that limitation.

appsecusa austin 2012

WTF – WAF Testing Framework (OWASP AppSecUSA Presentation Review)

appsecusa austin 2012The fundamental idea of this talk was that testing a WAF for good data getting through as well as bad data not getting through is a very good idea and one we wholeheartedly agree with at NT OBJECTives.

Yaniv Azaria and Amichai Shulman from Imperva presented a new approach to evaluating web application firewall capabilities. Their talk included discussion of:

  • false positive / false negative rates,
  • evasion techniques and
  • whitelisting / blacklisting balance.

They demonstrated a tool that can be used by organizations to implement the methodology either when choosing an application protection solution or after deployment.

The tool tests a WAF both for blocking malicious traffic and allowing good traffic. The thesis is that most benchmarking products stress breadth and quantity rather than depth and quality. And a WAF that blocks everything would be flagged as perfectly fine by a lot of these products because they just test for blocking malicious data.

However, more than 75% of data is good. There are various ways to evade a WAF. Parameter pollution alters a parameter so that an attack payload is unaffected in its efficacy but its particular syntax evades, for example, a regex on the WAF designed to filter it. Complex SQL queries can also get past a WAF. The tool whose release is pending at the end of the year promises to provide for testing these things.

I have not been as verbose in my review of this talk because what I have written fairly succinctly captures the essence of it.

As I mentioned above, this is something we agree with at NTO, this functionality is part of the feature set of one of our NTODefend.

health care breaches

Surviving the Week 12/14/12, Most Healthcare Organizations Suffered Data Breaches

health care breachesMost Healthcare Organizations Suffered Data Breaches

Two separate reports released this week show the critical condition of U.S. healthcare organizations and hospitals when it comes to data breaches, with 94 percent of healthcare organizations hit by at least one data breach and close to half suffering more than five breaches in the past two years.
Use NTOSpider (DAST) or our SaaS solution, NTOSpider On-Demand, to scan your applications.


Tutorial on SQLi Labs

SQL Injection has been one of the most deadliest attack one can have. This tutorial seems to be a nice start to understand SQL Injection.

SQL Injection cheat sheet –
Also, our free tool, NTO SQL Invader, will help exploit SQLi vulnerabilities.


Microsoft Security Bulletin Summary for December, 2012

It was the final patch Tuesday for Microsoft in 2012 which fixes 5 critical vulnerabilities. Patch your Microsoft products. Details can be found at:


Multiple Vulnerabilities

Splunk 5.0 Custom App Remote Code Execution –
Achievo 1.4.5 Cross Site Scripting / SQL Injection –
ClipBucket 2.6 Revision 738 SQL Injection –
IBM System Director Agent DLL Injection –
Maxthon / Avant Browser XCS / Same Origin Bypass –
m0n0wall 1.33 Cross Site Request Forgery –

sherif koussa

Secure Code Reviews, Magic or Art (OWASP AppSecUSA Presentation Review)

sherif koussaContinuing my series of write-ups on the talks I attended at AppSecUSA this year.

Sherif Koussa (@Skoussa) who is a Principal Application Security Consultant at Software Secured presented this talk about source code reviews and proposed a methodology for going about it. Companies tend to take the “happens to someone else, never to us” attitude. There can also be “accidental security” in the form of inputs that happen to be filtered against, for example, SQL injection by being converted into integer. Security has to be more proactive and deliberate than that. The methodology goes like this: enumerate the inputs, autoscan for Low Hanging Fruit, manual review, weed out false positives, communicate to developers. Note the combination of automatic and manual assessment for maximum coverage.

The notion of a “trust boundary” was also discussed. This is something I have contemplated extensively in architecting software, not just security related but also in handling bad input that can crash the software. One implicitly or explicitly draws a trust boundary, that is, a boundary behind which you do not bother checking inputs and trust the code outside the boundary to do so. Because it is simply not feasible to wrap every line of code in a validating if statement… if for no other reason, you have to wrap the ifs in ifs, and those ifs in ifs, etc. until you stackfault the universe.

Koussa also mentioned naming identifiers something obvious vis-a-vis the security issues implied so those issues are not lost in subtlety. This is a subset of a greater principle to which I subscribe but not being a 900 pound gorilla security company am presently at a loss to coerce the industry to practice. The principle being to convince developers to write code that makes it easy for automated tools and manual reviewers to find problems without compromising the expressive power of the code. At NT OBJECTives, we build automated application security scanning tools. A lot of things I have seen fool scanners or that we have had to make not fool our scanner were things that were unnecessarily complicated like multiple assigns and copies of variables in javascript that cause the tool to get lost in attempting to profile the inputs. Developers just do this stuff without thinking of how it makes an automated tool’s job or a manual reviewer’s job more difficult. If there is a compelling reason to code that way then so be it but if it can be made more simple, by all means do.

Koussa wrapped up by calling for the need to report the findings to the developers with articulate reasons why it is vulnerable, business impact, and how to remediate.  It is difficult to argue with this of course but I also know why it is necessary to say it, though it may seem obvious.  Alot of reports are information glut that, if it presents the information this speaker was calling for at all, makes it a needle in the haystack of the glut.

Mark Haase

Reverse Engineering “Secure” HTTP API’s with an SSL Proxy (OWASP AppSecUSA Presentation Review)

Mark HaaseThis is a continuation of my series on the talks I attended at OWASP AppSecUSA in October of this year.

Alejandro Caceres, Computer Network Operations Engineer – Lunarline Inc.
Mark Haase, Sr. Security Software Engineer – Lunarline Inc. (Follow him on Twitter, @Mehaase)

The thesis of this highly valuable talk was that SSL does a fine job with the traffic being transmitted/received by the endpoints but does not protect against hostile endpoints. A general security maxim is proffered: make the cost of getting through the security more expensive than the assets protected by the security. I have well learned to think in these terms myself. Security is indeed an odds game.

SSL uses certificates with public/private key encryption but clients may not necessarily validate against the Verisign-issued certificate. In that case, such as with Apple Game Center (a mobile phone app), one can create a proxy that intercepts the traffic, lets the server think it is talking to the game center client, and create different certs to pass the traffic along to the client. Then the traffic can be snooped unencrypted.

In the case of Apple Game Center, this traffic is JSON packets. The application as it turns out does not validate inputs and so it is quite easy to stuff INT_MAX into the high score and thus cheat your way to a score that it is impossible to surpass. Countermeasures include implementing extra encryption on top of SSL.

The speakers were careful to note that it is wise to call the highest level API in whatever crypto library you are using since crypto is way too easy to screw up implementing it yourself.  This affirms my experience with crypto. The other more common countermeasure which is mentioned in other talks is cert pinning. Simply write the client app to insist on a very specific cert. The disadvantage of that is that any change on the server mandates a redeploy/update to all clients that are to work with the new cert.

I had heard of other man in the middle attacks, specifically the one where the server allows negotiating the cert and that gives an interceptor an opportunity to negotiate for a contrived cert and thus snoop arbitrary (on thusly insecure) SSL traffic. It rattles one’s conceits and is an admonishing splash of cold water to not get into the mindset of thinking that SSL security is solely about the strength of the cryptos it is using.