Posts Tagged software
=3.Mar.2011= [Thu] at [23:12] · Filed under 0day, Author: Derek Callaway, cansecwest, Digital Security, Exploits, fuzz testing, Software Assurance ·Tagged academic, analysis, application, assurance, blog, cansecwest, cgi, cloud, command, computing, development, exploitation, exploits, free, http, issues, language, license, network, newsgroup, objectives, private, problems, programming, protocol, public, regfuzz, research, scientific, security, software, solution, staff, tcl, testing, theory, tickling, tk, tool, toolkit, total, usenet, vancouver, vulnerabilities, web, whitepaper
Tcl/Tk
Ah, TCL, the Tool Command Language. Based on the research conducted by myself and my colleagues here at Security Objectives (most notably Shane Macaulay,) we have concluded that Tcl has a multitude of security issues, especially when being used in a network environment; and contemporarily speaking, network usage is almost unavoidable. In essence, we are urging the use of extreme caution in Tcl-based web development–whether it’s being used directly or indirectly. To generalize, we also advise against using Tcl for any network application or protocol (not just HTTP.) Security Objectives has published an in-depth analysis of practical Tcl vulnerabilities. The whitepaper, entitled “Tickling CGI Problems”, outlines the theoretical backbone of the phenomena in the first half and presents cases of real-world exploitation in the second half. However, the background theory along with some general programming and Hyper-Text Transfer Protocol knowledge is recommended in order to gain a firm understanding of the exploits themselves.
This is not to say that Tcl should not be used ever, so as a disclaimer we are not advocating any programming language over another. Our position is that the traditional approach to web security with Tcl has much room for improvement. Like any other programming language it works nicely in certain areas such as academic research, scientific computing, extensions, and software testing. With that being said, one project that comes to mind is regfuzz, a regular expression fuzzer written in Tcl which is quite useful. The distinction here is that regfuzz is not intended to be exposed to a public (or even a private) network. Surely, Safe-Tcl could successfully serve network clients in a hardened production environment given that assessed risks were rated low enough to suffice as acceptable. The problem is, that’s not the type of operations that occur in practice as evidenced by an overwhelming majority of cases.
The vulnerabilities exposed by the whitepaper affect TclHttpd, Lyris List Manager, cgi.tcl (which also uses Expect) as well as the Tcl language itself and interpreters thereof. Some of the attack methodologies and vulnerabilities identified are new to the public. Others are similar to well-known attacks or simply subversions of previous security patches, e.g. CVE-2005-4147. As time unfolds, there will surely be a surge in publicized Tcl weaknesses due to the research which is elaborated on within the whitepaper. If you’re interested in discovering vulnerabilities in Tcl software yourself, then there’s a grand list of references to Tcl-related things at http://www.tcl.tk/resource_dump.html. There is also a USENET newsgroup dedicated to it which is naturally called comp.lang.tcl.
For those of you attending CanSecWest 2011 in Vancouver, we are sponsoring the event. Professionals from Security Objectives will be in attendance to answer your queries regarding Tcl/Tk security or other areas of specialized research (information assurance, software assurance, cloud security, etc.) Of course, our professionals will also be available to field questions regarding Security Objectives’ product and service offerings as well. In addition, CanSecWest 2011 attendees receive special treatment when purchasing licenses for BlockWatch, the complete solution to total cloud security.
Like this:
Like Loading...
Permalink
=25.Sep.2009= [Fri] at [0:40] · Filed under Author: Derek Callaway, combinatorics, Digital Security, Discrete Mathematics, fuzz testing, Security Industry, Software Assurance, Systems Theory ·Tagged 2-exptime, active, aerospace, algorithmic, analysis, array, assurance, augment, bell, binary, binomial, blockwatch, bob, bugs, code, coefficient, complexities, concurrency, conditions, covering, curve, desktop, device, dynamic, earth, error, evaluation, factorial, feynman, functional, generator, halting, hardcore, hidden, instrumentation, inventions, issues, jenkins, jenny, linear, machine, mccarthy, molecular, nist, pairwise, pcp, perfection, polynomial, preconditions, problem, quality, quantum, race, research, samate, scientists, sequences, silicon, software, steering, stress, testing, turing, universal, vulnerabilities
binomial coefficients
..binomial coefficients?! That’s right. I’ve found the web site of a Mr. Bob Jenkins with an entire page dedicated to a pairwise covering array generator named jenny.c. I’m fairly sure that only the most hardcore of the software testing weenies have some notion of what those are so for the sake of being succinct I’ll be providing my own explanation here: A pairwise covering array generator is a program for silicon computing machines that deduces sequences of input value possibilities for the purposes of software testing; and yes, I did say silicon computers–since testing their software is really a question of the great Mr. Turing’s halting problem, the existence of a practical, affordable, and efficient nano/molecular computing device such as a DNA computer, Feynman machine, universal quantum computer, etc. would essentially predicate a swift solution to the problem of testing contemporary computer software in non-deterministic polynomial time. The only problem we would have then is how to test those fantastic, futuristic, (seemingly science fictive) yet wondrous problem-solving inventions as they break through laborious barriers of algorithmic complexities that twentieth century computer scientists could have only dreamed about: PCP, #P, PSPACE-complete, 2-EXPTIME and beyond.. The stuff that dreams are made of.
Now, let’s return to Earth and learn about a few things that make Jenny so special. Computer scientists learned early on in their studies of software testing that pairwise or test cases with two input values were the most likely to uncover erroneous programming or “bugs.” Forget the luxury of automation for a minute, old school programmers typed input pairs manually to test their own software. Code tested in that manner was most likely some sort of special-purpose console mode utility. (Celsius to Fahrenheit, anyone?) As the computing power of the desktop PC increased according to Moore’s law, it became time-effective to write a simple program to generate these input pairs instead of toiling over it yourself–I suppose not testing at all was another option. Today, still some software is released to market after only very minor functional and/or quality assurance testing. Regression, stress, security, and other forms of testing cost money and reduce time to market, but in reality significant return on investment acts as a hedge against any losses incurred. Even ephemeral losses justify the absolute necessity of these expenditures.
A Jenny built in modern times undoubtedly has the power to deductively prove that a software product of the eighties decade is comprised of components (or units) that are fundamentally error-free. However, the paradox remains that improvements in automated software testers share a linear relationship with improvements of software in general. Thus, pairwise has become “n-way” which describes the process of utilizing greater multiples of input values in order to cover acceptable numbers of test cases. The number of covering arrays generated in this fashion grows exponentially and can be calculated as a binomial coefficient (see formula below.)
(n choose r) in factorial terms
According to Paul Black, former SAMATE (Software Assurance Metrics and Tool Evaluation) project leader, researchers at NIST have pegged 6-way as the magic number for optimal fault interaction coverage (notably Rick Kuhn and Dolores Wallace.) This conclusion is based on hard evidence from studies on real-world software scenarios including medical devices and the aerospace industry. However, it would not surprise me to see this approximation rise significantly in the coming decades, just as the paradoxical relationship between general-purpose software and automated software testing programs shifts itself in accordance with Moore’s law. If not by Moore, then by some other axiom of metric progression such as Rogers’ bell curve of technological adoption.
I’ve also got a hunch that the tiny percentage of bugs in that “n is arbitrarily greater than 6″ range are some of the most critical, powerfully impacting software vulnerabilities known to man. They lie on an attack surface that’s almost non-existent; this makes them by definition, obscure, non-obvious, shadowy, and hidden. Vulnerabilities in this category are the most important by their very nature. Therefore, detecting vulnerabilities of this type will involve people and tools that are masters of marksmanship and artistic in their innovation. Research in this area is entering a steadfast beginning especially within the realms of dynamic instrumentation or binary steering, active analysis, fault propagation, higher-order preconditions/dependencies, concurrency issues, race conditions, etc. I believe that combining merits inherent in various analysis techniques will lead to perfection in software testing.
For perfection in hashing, check out GNU’s gperf, read how Bob used a perfect hashing technique to augment Jenny’s n-tuples; then get ready for our Big ßeta release of the BlockWatch client software (just in time for the holiday season!)
Like this:
Like Loading...
Permalink
=5.Jan.2009= [Mon] at [2:01] · Filed under Author: Derek Callaway, Digital Security, Security Industry, Systems Theory, WPF ·Tagged 25c3, anti-virus, api, automated, cansecwest, database, digital, forensics, gnu, gui, hacking, hash, information, linq, malware, maps, md6, merkle, meta-data, napster, nist, processes, pth, queue, research, rsa, screenshot, sha-3, signature, software, spam, stealth, system, tiger, tree, whitelist, WPF, xml
By now, the security industry must recognize that the future of Message-Digest algorithm 5 is hopelessly jeopardized. The rogue CA certificate presentation at 25C3 might as well have been the nail in the coffin. A little over a year ago, NIST opened up its Cryptographic Hash Algorithm Competition for the creation of SHA-3. In response, Ron Rivest (The ‘R’ in “RSA”) developed MD6 at MIT. Security Objectives’ has been tirelessly working on a little hashing project of its own–Pass The Hash.
The security industry is currently in the process of reluctantly accepting that the current signature-based approach to anti-virus and malware identification is futile. Therefore, our Pass The Hash solution utilizes a whitelist approach in conjunction with a custom hash tree data structure to wholly single out malware variants piece by piece. Moreover, non-disclosure agreements are a besetting factor in digital forensics investigations because the analyst cannot inquire about a malware specimen by sending it out verbatim; our solution solves that problem too.
Here’s how it works: you compute Tiger hashes of files on your system, query our central database, and we tell you what they belong to. If it doesn’t match one of our hashes, you know you’ve got a problem. Once you’ve identified a piece of malware, you can coordinate specifics with our community such as fixes, research, opinions, etc. All of this is in a really sleek WPF GUI because here at Security Objectives, we strive to make hacking look like the movies!
The hash computations that our software performs identify polymorphous variations similar to Context-Triggered Piecewise Hashes and Bloom Filters. There will also be an off-line mode where hashes can be compared against a local client-side database that deals with hash trees similar to our centralized database. Directories, drives, and even processes whose hashes need to be calculated are inserted into a dynamically managed queue; with the click of a button the queue can be re-prioritized, saved, elements can be removed, etc. Meta-data is associated with each hash object that describes attributes such as operating system, platform, user-specified information, etc.
When we first started working on this we were thinking “napster for malware” but it’s turned into so much more. More recently the description was “MRBL” (Malware Real-time Blackhole List,) similar to the MAPS SPAM countermeasure except that it actually utilizes whitelist technology. “malster” sounds cool, but we decided to name it Pass The Hash, indicative of the hash value computation and transmission taking place. This venture is clearly distinguishable from GNU Pth (Portable threads) because our acronym (PTH) is written in all caps. 
I can’t provide an exact release date right now–all I can say is very soon. Once it’s released you’ll be able to download it from our products page. The long-term plan is to slap an open source license on the client code, thereby exposing the XML API for the central database and LINQ for the local one. Organizations that require the achievement of total malware sovereignty can deploy a dedicated appliance that acts as a counterpart to the centralized hash database hosted by Security Objectives. So keep your eyes peeled for the upcoming release of Pass The Hash. In the meantime, sneek a peek at a screenshot.
Similar Research:
P.S. After a long hiatus, we plan to be hitting the conference circuit once again to present on the specifics of this new reactive malware eradication technology. We’ve been submitting CFP’s left and right, but you’re most likely to catch up with us at CanSecWest. Hope to see you there!
Like this:
Like Loading...
Permalink
=14.Aug.2008= [Thu] at [6:55] · Filed under Author: Derek Callaway, Digital Security, Software Assurance, Systems Theory ·Tagged backdoor, bots, cards, cheating, chips, collusion, flaw, gambling, gaming, logic, mathematical, money, no-limit, poker, random, software, threats, tournament, vulnerability
We recently published an advisory for PartyPoker, an online gambling site (SECOBJADV-2008-03.) It was for a weakness in the client update process, a class of vulnerability that can affect various kinds of software. The past few years have seen some vulnerabilities that are specific to online gaming software. Statically seeded random number generators that allow prediction of forthcoming cards and reel values on upcoming slot spins were researched in the early days of online gaming–let’s take a look at some additional threats.
Usually, forms of online cheating are pretty primitive. Justin Bonomo was exposed for using multiple accounts in a single tournament on PokerStars and of course collusion between multiple players occurs as well. Absolute Poker’s reputation took a pretty big hit when players discovered that a site owner used a backdoor to view cards in play. Many private and public bots are also in use. However, a good human poker player will beat a bot, especially in no-limit which is less mathematical than other variations of the game; bots are likely to be most useful in low-stakes fixed-limit games.
Earlier this year, a logic flaw was exploited on BetFair (oh, the pun!) because of a missing conditional check to test for chip stack equality when determining finishing positions. As a result, if multiple players with the same amount of chips were eliminated at the same time, they would all receive the payout for the highest position, instead of decrementing positions. For example, if there were three players that all had chip stacks of the same size and everyone went all-in, the winner of the hand would finish in first place and the other two players would both receive second place money. Interesting!
Like this:
Like Loading...
Permalink
=12.Feb.2008= [Tue] at [21:40] · Filed under Author: Shane Macaulay, Exploits, Security Industry, Software Assurance, Visualizations ·Tagged architecture, assessment, automated, binary, dime, exploit, metasploit, microsoft, regression, software, vendors
Microsoft Security Bulletin
MS08-010 – Critical CVE-2008-0076
None of the flaws I’ve ever found on Microsoft platforms have ever been public (that is, they have all been derived from internal projects) and it’s nice to see at least in this round of fixes that my bug scored a perfect 10.0 (a dime) on the bulletin. I actually did not test as many platforms and configurations as Microsoft. For those of you that are unaware, bug regression and the overall triage process can become quite intensive. I knew that this vulnerability/flaw/bug/exploit/whatever had wide reaching appeal, fairly easy to see from the fact that all architectures and versions as far back as possible are marked critical.
As with all doings in the security space, walking a line between disclosure and tight-lipped mums, the word practice is not easy. So, what can be said here? Nothing? Something? I guess I have to write something, the marketoid’s wouldn’t be happy if I did not.
Before I digress into any technical discussion, I will take this opportunity to say something about the exploit sales “industry?”. In this world, everything and everybody has their place, that said, any individual that thinks exploits are worth any money, has another thing coming. Look at it this way, if you’re in the business of purchasing information (exploits), by definition you are unaware of the value of that information thereby inherently you are in a position to devalue the time and emotional investment into the derivation of that work. So this means, you’re never going to get back enough cash to make up for your time, EVER!! Where I do see some value in exploit brokers, is exclusively in the capacity of having them take the burden of dealing with uninformed software vendors (the Microsoft/IBM/others process is fairly straight forward).
Now that that’s all done with, I don’t really want to talk about the exploit, at least until some poorly constructed version winds up in metasploit. I will say though that the bulletin is correct in its description and synopsis.
The fact that there are no mitigating factors or workarounds possible, gives me some incentive and reassurance that the tools and methodologies that we’re building into our product offering works.
We’re ramping up development for a big push this quarter and will be uploading some more screenshots and related minutia in the coming months.
Our product in brief is an automated tool for native application flaw finding. It can assess, at runtime in a dynamic way, the integrity of a given binary application. This process then produces test cases and reproductions of what is necessary to trigger the flaw for a developer (this way, reducing regression rates due to bug fixes as it’s much easier to fix something when you can interact with it as opposed to a simple warning message).
We’re working on a management interface (on top of the technical one), that will also enable the lay person to identify architectural problems in arbitrary software also. This is actually quite simple (with the support of our engine), in essence, a landscape or tomography view is laid out before the user, with associated peaks and valleys, this then changes over time (4D), and represents the surface area of your application binary’s response to input. That is, a dynamic environment that is rooted by a system of systems methodology. What becomes apparent is that (if you are in the capacity to fix these issues yourself), as time goes on, and you assign various resources (people) to fix the peaks and turn them into valley’s. The rate at which you push down the peaks (bugs), across the application is not constant, some issues are harder to fix than others and persist. This way, a self-relative understanding of where problem area of code exist poignantly reveal themselves as architectural flaws and appropriate steps can be taken to drive the business case that will support a rewrite.
Whew, that’s a mouthful. Needless to say, we’re working to create the best platform around for software sovereignty.
Like this:
Like Loading...
Permalink
