/var/log/messages
This section contains the latest news, announcements and thoughts from the MWR InfoSecurity team.
Full TextPresentation: Sec-T - Websphere MQ Security Uncovered
Sep 12, 2008
Martyn Ruks spoke at Sec-T in Stockholm detailing additional research by himself and others on Websphere MQ and Middleware generally. His previous years presentation on MQ security created additional interest in the subject and stimulated further research efforts. His presentation brought together information already in the public domain and new details about Websphere MQ security and the methods for subverting it.
Presentation: DefCon16 - Virtually Hacking
Aug 12, 2008
On Friday 8th August 2008 MWR InfoSecurity's John Fitzpatrick presented the talk 'Virtually Hacking' at DefCon 16 in Las Vegas. The presentation looked at VMware security and can be downloaded from:
http://labs.mwrinfosecurity.com/files/Publications/virtually-hacking_DEFCON16.pdf
Defcon 16 Talk Review: Time-Based Blind SQL Injection Using Heavy Queries and the Marathon Tool
Aug 11, 2008
Author: Matt Hillman
This talk by Chema Alonso and Jose Parada at the Defcon 16 security conference in Las Vegas introduced a method, and a tool, for performing time based blind SQL injection without the need to use delay functions of the database server.
Blind SQL injection allows data to be retrieved form a database through an SQL injection vulnerability even when that data is not directly output by the vulnerable application. The techniques used to accomplish this require repeated queries selecting a small piece of data, such as a single character or the a string length or a field name, and testing its value. Using conditionals, different behaviour is induced depending on whether the condition has guessed correctly about the data. Gradually then, information can be extracted.
For the technique to work however, a visible difference in the result of a true or false condition must be produced. If the application checks the result of the query more strictly, a generic error message may be given in all cases, removing the ability to differentiate between a true or a false condition. In these situations, timing attacks can be used. These traditionally take advantage of timing functions contained in certain SQL servers to cause the query to pause for a measurable length of time, say 10 seconds. The truth of the condition can then be inferred according to whether the query pauses for at least that length of time, or returns quickly.
If the underlying database does not support, or has disabled delay functions, and the only viable attack vector is timing based, SQL injection to extract information may seem futile. Alonso and Parada demonstrated a method for making this possible, inducing the database to pause longer for one condition by causing it to execute a heavy query.
A heavy query is a query which forces the database to do a lot of work. Such queries take the database server a length of time to process such that the difference between a true and a false condition, executing a light or a heavy query, can be measured reliably. Heavy queries take advantage of a problem common to large database design. Applications can grind to a halt processing poorly constructed queries which are usually hunted down by programmers and altered to be more efficient. There should then be many ways to construct a deliberately slow query.
To make the technique work, it is important to understand how the target database processes queries. Databases without optimisation evaluate conditions and clauses in a fixed order, left-to-right or right-to-left. Databases with optimisation however, estimate which part of a nested query or clause will be more expensive and executes the lighter one first. This allows the database to skip the heavy query if it is not needed to fully evaluate the condition. It is important to know how a given database operates to ensure that the outcome of the query returning quickly or slowly can accurately determine the truth of the condition given.
The following is a generic example of a query designed to perform heavy query based SQL injection attack:
http://server/script.aspx?vuln_param=1 and (<heavy query>)>0 and 300>(select top 1 ascii(substring(name,1,1)) from sysusers)
The heavy query is not filled in here, and more details on how heavy queries can be constructed are discussed later. The thing to note at this point is the structure of the query as a whole. The heavy query will only be performed by MSSQL if the last condition is true. This last condition also makes up the query which extracts the information we are interested in, comparing the value of the first letter of data we are interested in the usual manner of blind SQL injection.
As the light query is optimally executed first, the database server evaluates this side of the condition first. If it is false, it does not need to execute the heavy query to know the overall "and" condition is false, so it skips it, and the query returns quickly. If however, the last condition is true, the database must execute the heavy query to fully evaluate the query, and it returns slowly. In this way, it can be determined if the last condition is true or false, and data can gradually be inferred.
As well as providing a viable attack vector to otherwise unpractical SQL injection vulnerabilities, this kind of attack has an advantage in overcoming IDS detection. As there is usually no need for an application to use delay functions, signatures could be written to detect queries containing such functions. Using heavy queries however, no unusual query statements need to be present and the query looks a lot more like a legitimate query. The ability to create heavy queries in a variety of subtly different ways also makes evading signatures easier. Of course the presence of any generic SQL injection string could still potentially be caught by IDS systems, but the ability to leave out other identifying elements of a timing based attack does increase the chances of letting the query slip by.
By default, the marathon tool designed to automate this kind of attack uses default tables from the database it supports (Microsoft SQL Server, MySQL and Oracle) to reliably construct heavy queries independent of schema. For Oracle, the user_details, user_tables or all_objects tables will be used by default; for MySQL, information_schema.columns is used by default; and for Microsoft SQL Server, the default tables used are sys.databases and sysusers. These tables can be changed in the configuration if desired, and if a table name is already known or guessed, using it instead may aid in attempts to bypass IDS, as only tables legitimately used by the application will be included in the query.
To produce the slow processing effect required by this approach, Marathon uses multiple cross-joins on the tables selected for use. Cross-joins instruct the database to combine every record of the table with every other record. Marathon then tunes the query, varying the number of joins until an efficient delay time is found that is long enough to be accurately measured, but not too long so the attack is slowed down more than necessary. Parameters can be set to constrain this tuning both in terms of the minimum and maximum joins to use, and the minimum length of time a heavy query should take.
Marathon also supports useful features like setting cookies or authorisation data, and routing through proxies, to allow it to be used in a variety of circumstances.
The marathon tool is still being developed, and according to the authors is still in an alphas stage. It is functional, but it currently only supports extracting the schema from a database and not the actual data. Still it acts as a good proof-of-concept for this method of heavy query time based SQL injection.
While the Defcon presentation was given by only Chema Alonso and Jose Parada, the work behind it had many more contributors who should also be acknowledged, They include Daniel Kachakil, Rodolfo Bordón and Antonio Guzmán y Marta Beltrán. Further information can also be found at http://technet.microsoft.com/en-us/library/cc512676.aspx.
Defcon 16 Talk Review: The Pentest is Dead, Long Live the Pentest
Aug 11, 2008
Author: Matt Hillman
This insightful presentation at the Defcon 16 conference in Las Vegas commented on the history of the pentest, what worked and what didn't, and the direction which, in the speakers' eyes, the pentest should be moving towards today. The speakers, Taylor Banks and Carric, gave a warning at the start of the presentation that no punches would be pulled and that things which they felt were wrong with the industry and the people in it would be freely discussed.
They laid out what pentesting used to be like and where it came from, what it became, the problems it still faces and looked at what really adds value to a pentest and how we should be developing it as a service. Much of what they said rang true with MWR's experience and current goals and it was certainly interesting to see these ideas laid out. In this article I hope to captures much of what they were expressing in that talk.
The talk harked back to the early days of the pentest and its links with hacker culture. This is an aspect often missed in today's professional world, but acknowledging it allows for a great perspective on why pentesting evolved in the way it did, and contrasting it against the directions it took later helps us keep the good, throw out the bad, and improve the neglected. Just as hacker culture evolved, so did the pentest, as did business use of technology.
The talk described the dark days of early pentesting. They described pentesting as a "black art" in those early days, which much like security itself was little understood by those slowly beginning to use technology.
The only place for early pentesters to learn from was from small, underground communities. If this sounds like the same place hackers learnt their stuff, then its because they probably were the same places. There was no large security industry attracting practitioners; pentesters did what they did for the sheer love of it. Indeed to begin with, the term penetration tester didn't even exist and people would sometimes seek to simply "hire a hacker".
Early pentesting then was a much more obscure process in which someone was essentially let loose on the network to play hacker and see what they could turn up. People paying for pentests understood little about the arcane art and had to place trust in whatever was delivered at the end. This certainly gave the customer a perspective on the safety of their networks and systems they could not have gotten on their own, but the lack of any kind of accepted methodology brought with many shortcomings.
But strong competition tended to incline people away from accepted methodologies. To succeed a pentester or pentesting company needed to deliver the best report with the most findings, so revealing details of any methodology that gave you an edge would only give competitors the chance to yield the same results as you. In the still immature security industry there was little else at the time to act as a differentiator between a good and a bad pentest other than how many results were in a report.
The other major problem with this ad-hoc approach is that pentests were rarely repeatable. The presnters made the point that "if it ain't repeatable, it ain't a pentest... it's just a hack". But what is the difference between a hack and a pentest? An attacker only needs to be successful once to get in, but a pentest ought to cover as many possible weaknesses as possible. A pentest is different from a hack in that it is not just about "getting in", its about evaluating how easy other people might get in. And that means that the people fixing the systems need to know exactly how security was bypassed, and for effective retests to be possible a pentester, perhaps a different tester from the one who originally performed the test, needs to be able to reproduce the "hack" exactly.
As organisations grow, the ability for one person to do everything disappears rapidly. The ability to effectively share information among testers, and to communicate relevant information to the customer, is therefore vital to a good penetration test. The experience of seasoned pentesters should also not go to waste. No longer are we restricted to small underground communities trading bits of information. Progress in this area has been made with schemes such as CHECK and OWASP.
As the millennium approached, pentetration testing started to go more mainstream. The computing world grew massively, technology was being used in ever more sensitive areas, and computers became accessible to many more people. As such, the hacker community grew, and the pentesting community grew. Many tools had been developed to allow scanning and automated assessment, and this again made pentesting a more accessible profession.
Unfortunately, these tools do not solve the security problem. The bar is not raised very high if all that is performed is an automated scan with the results blindly handed on to a customer. It is easy to fall into the trap of thinking that a methodology is a simple checklist which can in time be completely automated with the tools that become available. But these do not give nearly as useful a picture as a test with expert, creative human input.
This issue is found in various training courses that can now be taken in "hacking" or pentesting. They tend to focus a lot on using the tools and specific nuances of technology and tricks of the trade. But a good pentest is also about understanding the process of an attack. How can a random collection of vulnerabilities and tools be combined to create a greater threat, and how do you go about finding all these weaknesses in a system in a reliable way.
What's more, we do not only have to deal with software vulnerabilities or open ports. Architectural or systemic problems in the way a system is designed can be a huge threat as well. Such things cannot easily be rooted out with automated tools, but by following an intelligent process with experience and creativity the flaws in the concepts of a system can be exposed.
So while methodologies capture past experience and allow known issues to be methodically tested for, which is certainly better than a purely ad-hoc approach based on the experience and disposition of whatever pentester you happened to get, it is equally important that these methodologies are flexible. Room must always be left for the human mind to do what it does best and creatively explore ways in which a given security system might be bypassed.
After all, this is precisely what malicious hackers do; they bypass the very restrictions that were in theory supposed to keep them out. So confirming that the restrictions you thought were in place are indeed in place, is only a low level of assurance. In reality, a full blown penetration test needs to go deeper than that and look at the things you *didn't* think of, not just test the things you already put in place.
So a large part of the value of a pentest is in the people performing the test. But knowing this does not by itself help evaluate the difference between good testers and bad testers, and it may seem that we are still stuck with the size of the report being the only differentiator.
So what can we do to fix this and take pentesting to the next level? One thing we can do is put some of that human creativity into reports. Reports should not just be a dry list of vulnerabilities, offering a stark view of your network with no guidance on what to do about it or context about what it all means to you in your environment. Instead it is far better to include personalised descriptions of security weaknesses found, detailing their potential impact to the client based on the knowledge the pentester has of what they do. This means good communication between the client and the pentester is vital, and the service should not stop with the report. Ongoing support and advice is also an important way to add value to a pentetration testing service.
Metrics are also useful in evaluating both the value of a pentest, and the relative risk to which you may be exposed at a given time. A simple vulnerability total is not necessarily enough here. Some vulnerabilities are much higher risk than others, some are more practical than others, or relate to core security architectural failures.
Metrics are certainly not the whole picture, but they do allow tests to be compared, and patterns to be seen over time. Is the security posture improving, staying the same, or actually getting worse? And in what areas are these trends found, perhaps application level issues are being dealt with better than deployment of new infrastructure, and if so perhaps a certain team in the client organisation needs some further training. Such things provide constructive business information that can really be used to help improve security as a process over time.
So what are the ingredients for a good modern pentest?
- Repeatability
- Process driven not tool driven
- Creative, expert input
- Strategically focussed, partnering closely with the client in an ongoing relationship
Defcon 16 Talk Review: Advanced Software Armouring and Polymorphic Kung-Fu
Aug 11, 2008
Author: Matt Hillman
At the Defcon 16 conference in Las Vegas, Nick Harbour showed off his new Windows executable packer, PE-Scrambler. It uses some interesting, and sometimes downright devious techniques to make analysis of the binary harder.
Rather than blindly manipulating the bits and bytes of the code to compress or encrypt it as many traditional packers, PE-Scrambler disassembles the code and manipulates it at a logical level to sabotage many of the methods used by disassemblers to analyse instructions and flow. The result is a binary that is hard to get any meaningful automatic analysis of program structure for.
The techniques used to do this include altering function calls to call a single dispatcher function, destroying the call tree; chunking the code into small pieces and relocating them throughout the binary; weaving bytecode together such that they have ambiguous disassembly; and some polymorphic substitution of certain pieces of code for obfuscated alternatives.
To achieve the destruction of the call tree, PE-Scrambler creates a dispatcher function and alters every function call to call this dispatcher instead. The dispatcher needs to know what functionality to jump to for each call without giving a disassembler too many hints, and it achieves this by checking the stack for the return value of that call. This value can identify which call instruction has called the dispatcher, and using this information a lookup table is created so the dispatcher knows what functional code to jump to. In this way, all calls can reach the appropriate functionality but it is impossible for a disassembler to know what function a given call relates to without knowledge of the lookup table mechanism.
For code relocation, a variety of methods are used. The simplest method takes a relocatable chunk, moves it, and the previous chunk connects to it with a simple unconditional JMP jump.
A slightly more advanced technique looks for parts of the code where it is known that the value of the zero flag will always be a certain value. A conditional jump is then added just after this, and the chunk of code following it relocated. We know that jump will always be taken, but most disassemblers performing static analysis will not notice this and will produce two possible code paths, making comprehension of program structure more complex.
The final technique for relocatable chunks is to insert predictable conditionals. This works much like the previous method, except this time the predictable conditional is arbitrarily manufactured and inserted by PE-Scrambler. These conditions do not have to be purely statically predictable and can take advantage of things that a human knows, but a disassembler would probably never assume. The example given in the presentation involves comparing ESP with 0x80000000, and while we as humans know that ESP will always reasonably be less than this, a disassembler does not.
My favourite method used by PE-Scrambler is the production of ambiguous or conflicting disassembly. This involves weaving instructions together such that instructions jump part way into their own bytecode, altering the meaning of those bytes to other instructions. If that wasn't cool enough, PE-Scrambler also takes advantage of the fact that according to Nick most disassemblers evaluate the false condition of a branch first, and once bytes have been disassembled the disassembler won't try to disassemble them again. By using overlapping instructions that form a conditional like this then, incorrect or conflicting disassembly can be produced. The presentation contained several examples of ways similar to this to produce flawed disassembly.
PE-Scrambler also performs some general polymorphic alterations to the code to further obfuscate it. This involves replacing certain instructions with misleading but equivalent instructions. This can break a disassemblers ability to automatically understand what is happening at a given point in the code, adding again tot he effort required to understand the program as a reverse engineer.
Despite these pretty cool tricks, PE-Scrambler is not perfect. As it uses disassembly to perform most of these tricks, there is no margin of error for its own disassembly. If errors occur, the resulting executable may be destroyed and fail to run. Currently there is a significant proportion of files for which this can be the case, but that is expected to drop as more fixes and tweaks are added. When it does work however, it works great. And even if you don't use PE-Scrambler itself, some of the techniques it uses should provide inspiration for things like manual obfuscation of shellcode or the like.
As well as PE-Scrambler, at the end of the presentation Nick demonstrated another tool called FindEvil. This uses the same disassembly engine as PE-Scrambler and measures the size of disassembly compared to the size of the binary. Using various ratios it makes a decision as to whether that binary is packed. Nick claimed that so far, he has had 100% success using FindEvil, though he didn't say how many files it has been tested with. It is, however, an interesting way to detect packers.