About
Wow, a blog! :-) You can also follow me on tweeter on @paradoxengine
Accounts
Groups
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.
Click here to check if anything new just came in.
October 21 2011
"No More Free Bugs" Initiatives
Two years after the launch of the "No More Free Bugs" philosophy, several companies and Open Source projects are now offering programs designed to encourage security research in their products. In addition, many private firms are publicly offering vulnerability acquisition programs.This post is an attempt to catalog all public and active incentives. This includes traditional "Bug Bounty Programs" as well as "Vulnerability/Exploit Acquisition Programs".
Bug Bounty Programs
Sponsor
Target
Reward Barracuda Vulnerabilities in Barracuda appliances, including Spam/Virus Firewall, Web Filter, WAF, NG Firewall $500-$3,133.7 CCBill.com CCBill web application vulnerabilities $200-$500 Djbdns Verifiable security holes in the latest version of Djbdns $1000 Facebook Facebook web platform security bugs. No third-party applications Starting from $500 Google Chromium browser project and selected Google web properties bugs $500-$3,133.7 Hex-Rays Security bugs in the latest public release of Hex-Rays IDA Up to $3000 Mozilla Firefox, Thunderbird and selected Mozilla Internet-facing websites bugs $500-$3000, plus Mozilla T-shirt Piwik Flaws in Piwik web analytics software $200-$500 Qmail Verifiable security holes in the latest version of Qmail $5000 Tarsnap Tarsnap bugs, affecting either pre-release or released versions $1-$2000
Vulnerability/Exploit Acquisition Programs
Sponsor
Target
Reward
BeyondSecurity SecuriTeam High and medium impact bugs in widely spread software $n/a
Coseinc Unpublished security vulnerabilities for Windows, Linux and Solaris $n/a
Digital Armaments Vulnerability and/or exploit code for high value software $n/a
ExploitHub Legitimate market-place for non-zero-day Metasploit exploits $50~$1000
iSight Partners Bugs in typical corporate environment applications $n/a
Netragard 0-day exploits against well-known software $n/a
TippingPoint ZDI Undisclosed vulnerability research, affecting widely deployed software $n/a plus awards and benefits, depending on the contributor's status
VeriSign iDefence Security vulnerabilities in widely deployed applications $n/a
White Fir Design Bugs in WordPress code and plugins (with over 1 million downloads and compatible with the most recent WordPress) $50-$500
Contributions are welcome! If you are aware of an initiative not listed here, please leave a comment and we will update this page over time.
Just to clarify, we aim at indexing programs that are:
- Legal. Although black/gray market places exist, we don't certainly want to list them here
- Active. We want to keep track of ongoing initiatives. Even time-limited programs are eligible, as long as they are still accepting submissions
- Public. All entries must have publicly available details. This may range from accurate guidelines and rules to just a simple sentence stating the nature of the incentive
- Reward-based. In most cases, entries are "cash-for-bugs" programs. However, any kind of tangible reward is eligible. "No More Free Bugs" versus "No More Cheap Bugs" disputes are not considered here
September 01 2011
On exploits and assessing security
Everything started on a summer Friday, August 19 2011, 23:23 BST (so it might be reported to Sat 20 Aug, depending on your timezone).
Kingcope, a Greek hacker known for a long stream of 0days and trash Greek music soundtracks, posts a very short email on the Full-Disclosure mailing list. The email has a promising title, Apache Killer, and an attachment: killapache.pl.
The script is extremely simple: 84 lines of perl, comments included, capable of killing any Apache web server.
The core of the attack is extremely simple: the script sends a (perfectly legit) request to the Apache server, including a Range header similar to this:
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5-33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5-50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-
66,5-[..and many many more..].
What happens behind the scene is that Apache has to make separate copies of the response for each of those ranges and, guess what, it explodes.
The Range header (defined here in RFC 2616) has legitimate uses: for instance, PDF readers use it while you scroll down the page. Let us reiterate that the attack is a perfectly well formed request: "A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity."
On a side note, IIS only allows up to 5 ranges for each HTTP request, and it is not vulnerable - with the notable exception of IIS 5, but you don't have those around anymore, do you?
But back to our story. Apache reacted "quickly", issuing a security advisory [CVE-2011-3192] a mere 4 days after the release, on August 24 16:16 GMT [http://article.gmane.org/gmane.comp.apache.announce/58]. They acknowledged the bug, promising that "A full fix is expected in the next 48 hours.". Apache also provided a number of different mitigations, by using mod_rewrite, limiting the size of the request field or even a dedicated module.
+1 for having included so many mitigations inside the advisory, -1 for taking so long to give an official answer.
A number of different answers were surfacing by that time, including Spiderlab's suggestion of using ModSecurity (but truth be told the answer was already floating on some forums). The 24th was, in short, the moment where the general public started noticing the issue - also thanks to a The Register's article which, even though it drops a totally out of place comment on open source security, at least cites Zalewski.
And this is the interesting bit of the story: the bug was well known!
lcamtuf reported this exact issue in 2007 - just 4 years ago.
The reactions were, to say the least, wrong. William A. Rowe [of the Apache Software Foundation] answered: "With the host of real issues out there in terms of massively parallel DDoS infrastructures that abound, this is, as you say, quite a silly report.". Yeah, sure. The issue was also thought to be connected to the sliding window (Rowe: On the matter of your 1GB window (which is, again, the real issue), you have any examples of a kernel that permits that large a sliding window buffer by default).
Probably even lcamtuf did not understand the full impact of this issue - we are speaking about a full DOS against the default installation after all, even if it is very easily avoided - as he says: "William, again, this is not a critical issue; I did mention that, and if it were, I wouldn't report it that way". The issue was thus not really understood by both parties, or at least its full implications were not. If we go into the details of the bug report we must grant the fact that it focused more on the "network" attack vector - not exactly the one exploited by Kingcope's attack, which results in memory exhaustion. Siim Põder also tried to implement the attack, but failed. The thread then just died.
Bottom line: general failure of the community to identify and evaluate a risk in the absence of an exploit. So long for all the "risk assessment without full disclosure" talks: without an exploit, an entire community looking at the description of a bug in the most widespread web server of the world failed to evaluate risk.
At the same time, in the Apache dev@ mailing list there was not a single mention of the bug. Compare that to the mail thread [mod_deflate & range requests) from last August: http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/browser, or here. This exploit, in the end, resulted in a ticket on the ietf with a request for changing the standards [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311]: that's what we call impact.
And all because an exploit was not developed in the first place...
Kingcope, a Greek hacker known for a long stream of 0days and trash Greek music soundtracks, posts a very short email on the Full-Disclosure mailing list. The email has a promising title, Apache Killer, and an attachment: killapache.pl.
The script is extremely simple: 84 lines of perl, comments included, capable of killing any Apache web server.
The core of the attack is extremely simple: the script sends a (perfectly legit) request to the Apache server, including a Range header similar to this:
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5-33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5-50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-
66,5-[..and many many more..].
What happens behind the scene is that Apache has to make separate copies of the response for each of those ranges and, guess what, it explodes.
The Range header (defined here in RFC 2616) has legitimate uses: for instance, PDF readers use it while you scroll down the page. Let us reiterate that the attack is a perfectly well formed request: "A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity."
On a side note, IIS only allows up to 5 ranges for each HTTP request, and it is not vulnerable - with the notable exception of IIS 5, but you don't have those around anymore, do you?
But back to our story. Apache reacted "quickly", issuing a security advisory [CVE-2011-3192] a mere 4 days after the release, on August 24 16:16 GMT [http://article.gmane.org/gmane.comp.apache.announce/58]. They acknowledged the bug, promising that "A full fix is expected in the next 48 hours.". Apache also provided a number of different mitigations, by using mod_rewrite, limiting the size of the request field or even a dedicated module.
+1 for having included so many mitigations inside the advisory, -1 for taking so long to give an official answer.
A number of different answers were surfacing by that time, including Spiderlab's suggestion of using ModSecurity (but truth be told the answer was already floating on some forums). The 24th was, in short, the moment where the general public started noticing the issue - also thanks to a The Register's article which, even though it drops a totally out of place comment on open source security, at least cites Zalewski.
And this is the interesting bit of the story: the bug was well known!
lcamtuf reported this exact issue in 2007 - just 4 years ago.
The reactions were, to say the least, wrong. William A. Rowe [of the Apache Software Foundation] answered: "With the host of real issues out there in terms of massively parallel DDoS infrastructures that abound, this is, as you say, quite a silly report.". Yeah, sure. The issue was also thought to be connected to the sliding window (Rowe: On the matter of your 1GB window (which is, again, the real issue), you have any examples of a kernel that permits that large a sliding window buffer by default).
Probably even lcamtuf did not understand the full impact of this issue - we are speaking about a full DOS against the default installation after all, even if it is very easily avoided - as he says: "William, again, this is not a critical issue; I did mention that, and if it were, I wouldn't report it that way". The issue was thus not really understood by both parties, or at least its full implications were not. If we go into the details of the bug report we must grant the fact that it focused more on the "network" attack vector - not exactly the one exploited by Kingcope's attack, which results in memory exhaustion. Siim Põder also tried to implement the attack, but failed. The thread then just died.
Bottom line: general failure of the community to identify and evaluate a risk in the absence of an exploit. So long for all the "risk assessment without full disclosure" talks: without an exploit, an entire community looking at the description of a bug in the most widespread web server of the world failed to evaluate risk.
At the same time, in the Apache dev@ mailing list there was not a single mention of the bug. Compare that to the mail thread [mod_deflate & range requests) from last August: http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/browser, or here. This exploit, in the end, resulted in a ticket on the ietf with a request for changing the standards [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311]: that's what we call impact.
And all because an exploit was not developed in the first place...
June 21 2011
MS Access SQL Injection Cheat Sheet Reloaded
SQL Injections are still very popular, for both ethical and unethical attackers.Although numerous research covering this topic have been published, SQL Injection vulnerabilities in Microsoft Access powered websites didn't receive much attention.
Back in 2007, @_daath published the first MS Access SQL Injection Cheat Sheet. A few years later, NibbleSec decided to update the document in a brand new format. New stuff has been added as well as external resources have been merged.
Enjoy the reloaded MS Access SQL Injection Cheat Sheet
December 30 2010
TYPO3-SA-2010-020, TYPO3-SA-2010-022 explained
On 16th December, TYP03 released a new security update (TYPO3-SA-2010-022) for their content management system. Apparently, this web-based framework is widely used in many important websites.
Within this update, TYPO3 team fixed a vulnerability that I've discovered a few weeks ago. In detail, this discovery pertains to a previous vulnerability fixed in TYPO3-SA-2010-020 and discovered by Gregor Kopf.
TYP03 decided to follow a policy of least disclosure. Although it's an Open Source project, no technical details are available in the wild besides these (1,2). As I strongly believe that this practice does not improve the overall security (as mentioned in a previous post), I've decided to briefly explain this interesting flaw.
From the advisory, we can actually deduce two important concepts:
The patch (see this shell script) simply replaces the two equal signs with three (loose vs strict comparisons).
That's the affected code:
Having this knowledge, it is probably clear to the reader that the overall goal is to bypass the comparison between $juHash and $calcJuHash. While the former is user supplied (string or array), the latter is derived from a substr(md5_value,10) (string).
In PHP, comparisons involving numerical strings result in unexpected behaviors (at least for me before studying this chapter).
To further improve this attack, I've discovered another bypass (TYPO3-SA-2010-022) which allows the disclosure of TYPO3_CONF_VARS['SYS']['encryptionKey']. In this way, it is possible to retrieve the key once and download multiple files without repeating the entire process. Using multiple requests, this attack takes a few minutes (8-20 minutes in a local network). A real coder can surely enhance it.
As you can see from the exploit (posted on The Exploit Database), the fileDenyPattern mechanism bypass is pretty trivial. A demonstration video is also available here (slow connection, sorry).
Keep your TYPO3 installation updated! A patch is already available from the vendor's site.
@_ikki
Within this update, TYPO3 team fixed a vulnerability that I've discovered a few weeks ago. In detail, this discovery pertains to a previous vulnerability fixed in TYPO3-SA-2010-020 and discovered by Gregor Kopf.
TYP03 decided to follow a policy of least disclosure. Although it's an Open Source project, no technical details are available in the wild besides these (1,2). As I strongly believe that this practice does not improve the overall security (as mentioned in a previous post), I've decided to briefly explain this interesting flaw.
From the advisory, we can actually deduce two important concepts:
A Remote File Disclosure vulnerability in the jumpUrl mechanism [..] Because of a non-typesafe comparison between the submitted and the calculated hash, it is possible [..]In a nutshell, the JumpUrl mechanism allows to track access on web pages and provided files (e.g. /index.php?id=2&type=0&jumpurl=/etc/passwd&juSecure=1&locationData=2%3a&juHash=2b1928bfab)
The patch (see this shell script) simply replaces the two equal signs with three (loose vs strict comparisons).
That's the affected code:
Having this knowledge, it is probably clear to the reader that the overall goal is to bypass the comparison between $juHash and $calcJuHash. While the former is user supplied (string or array), the latter is derived from a substr(md5_value,10) (string).
In PHP, comparisons involving numerical strings result in unexpected behaviors (at least for me before studying this chapter).
If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically
If the string does not contain any of the characters '.', 'e', or 'E' and the numeric value fits into integer type limits (as defined by PHP_INT_MAX), the string will be evaluated as an integer. In all other cases it will be evaluated as a float.For instance, the following comparisons are always TRUE:
if(0=="php")-> TRUEAnd again, also the following comparisons are TRUE:
if(12=="12php")-> TRUE
if(110=="110")-> TRUE
if(100=="10E1")-> TRUE
if(array()==NULL) -> TRUE
[..]
If("0"=="0E19280311"){}Consequently, we can pad and wait till the substring of an md5 hash resembles this form. If you do the math, you will discover that the combined probability of having such calculated hash is considerably less than pure bruteforcing.
If("0"=="0E00106552"){}
If("0"=="0E81046233"){}
~37037037 max trials (worth case) VS 3656158440062976 all possibilitiesIn practice, the number of iterations is even less as "0000E13131" and similar strings are also accepted.
To further improve this attack, I've discovered another bypass (TYPO3-SA-2010-022) which allows the disclosure of TYPO3_CONF_VARS['SYS']['encryptionKey']. In this way, it is possible to retrieve the key once and download multiple files without repeating the entire process. Using multiple requests, this attack takes a few minutes (8-20 minutes in a local network). A real coder can surely enhance it.
As you can see from the exploit (posted on The Exploit Database), the fileDenyPattern mechanism bypass is pretty trivial. A demonstration video is also available here (slow connection, sorry).
Keep your TYPO3 installation updated! A patch is already available from the vendor's site.
@_ikki
December 29 2010
Unspecified vulnerabilities
If you're a pentester, it's probably not news to you that "least disclosure" policies for disclosing vulnerabilities are fruitless. Unfortunately, they are even counterproductive for the entire security ecosystem and I will try to convince you within this post.
Before going any further, let's explain what "least disclosure" actually means.
In a nutshell, least disclosure is about providing the least necessary facts of vulnerabilities that are needed to know if a user might be affected and what the possible impact would be. No technical details, no exploits, no proof-of-concept code.
As mentioned here, you may argue that it increases the overall security as a random "black hat needs to put some efforts in thinking and coding before he's able to exploit a vulnerability".
However, we all claim that "security through obscurity" is bad:
Thoughtful reader, please note that getting profit from vulnerabilities does not necessary implicate concealing details. For instance, see the Mozilla Security Bounty Program FAQ.
@_ikki
Before going any further, let's explain what "least disclosure" actually means.
In a nutshell, least disclosure is about providing the least necessary facts of vulnerabilities that are needed to know if a user might be affected and what the possible impact would be. No technical details, no exploits, no proof-of-concept code.
As mentioned here, you may argue that it increases the overall security as a random "black hat needs to put some efforts in thinking and coding before he's able to exploit a vulnerability".
However, we all claim that "security through obscurity" is bad:
- Aggressors don't have time constraints. They can analyze patches, read all documentation and spend nights on a single flaw
- No technical details in the wild generally means no signatures and detectors in security tools
- "Least Disclosure" tends to degenerate in "Unspecified Vulnerability in Unspecified Components". Please fix your computer and don't ask why
Thoughtful reader, please note that getting profit from vulnerabilities does not necessary implicate concealing details. For instance, see the Mozilla Security Bounty Program FAQ.
We're rewarding you for finding a bug, not trying to buy your silenceIf you enjoy the spirit, you may appreciate the following posts. Welcome back NibbleSec readers!
@_ikki
October 24 2010
Using RAP in PHP 5.3
If you try to use RAP [RDF API for PHP: http://www4.wiwiss.fu-berlin.de/bizer/rdfapi/index.html] on PHP 5.3:
1- define("RDFAPI_INCLUDE_DIR", $RAP_RELATIVE);
require_once(RDFAPI_INCLUDE_DIR . "RdfAPI.php");
require_once(RDFAPI_INCLUDE_DIR . "infModel/InfModelP.php");
require_once(RDFAPI_INCLUDE_DIR . "resModel/ResModelP.php");
require_once(RDFAPI_INCLUDE_DIR . "ontModel/OntModelP.php");
2- rename NAMESPACE() in _NAMESPACE() in OwlVocabulary.php and RdfsVocabulary.php
October 20 2010
Advanced Anti Evasion Super Mega Ultra
Okay, it's been 3 days, and people keep asking me to comment on Stonesoft's latest research: the Advanced Evasion Techniques (AET). The "details", so to speak, are on antievasion.com; I'm not going to link it not to raise their already ridiculous Google impact.
In brief, people at Stonesoft deliver an IPS which (in NSS already bland and relatively fair tests) fails 70% of evasion techniques.
So, they set forth and while (instead of?) fixing their broken stuff, they developed a new super secret l33t technique for evasion.
Of which they posted no details.
Not even a hint.
They got a ridiculous press impact, and we are not even able to know if it's true, bullshit, partial bullshit, or marketing slang. I'm inclined to think of the latter, given its dangerous likeness to Advanced Persistent Threats (APT).
In the meanwhile, may I remind you that almost all IPS already fail for the simple evasion techniques outlined by Ptacek and Newsham, as reported again by myself over and over? That they are misuse based and therefore utterly useless against zero days and targeted attacks?
What the heck are we talking about, people? Journalists, asking some questions, at times, would be part of your jobs!
Edited to add: it seems that the geniuses over at Stonesoft discovered that combining together several simple evasion techniques you can break systems that deal with each of them separately.
Wooooooooooah.
Pity this was already discovered six years ago by my colleague Davide Balzarotti.
In brief, people at Stonesoft deliver an IPS which (in NSS already bland and relatively fair tests) fails 70% of evasion techniques.
So, they set forth and while (instead of?) fixing their broken stuff, they developed a new super secret l33t technique for evasion.
Of which they posted no details.
Not even a hint.
They got a ridiculous press impact, and we are not even able to know if it's true, bullshit, partial bullshit, or marketing slang. I'm inclined to think of the latter, given its dangerous likeness to Advanced Persistent Threats (APT).
In the meanwhile, may I remind you that almost all IPS already fail for the simple evasion techniques outlined by Ptacek and Newsham, as reported again by myself over and over? That they are misuse based and therefore utterly useless against zero days and targeted attacks?
What the heck are we talking about, people? Journalists, asking some questions, at times, would be part of your jobs!
Edited to add: it seems that the geniuses over at Stonesoft discovered that combining together several simple evasion techniques you can break systems that deal with each of them separately.
Wooooooooooah.
Pity this was already discovered six years ago by my colleague Davide Balzarotti.
Reposted from
raistlin
raistlinSeptember 24 2010
September 21 2010
How to build modules for apache quickly
After losing half an hour configure makefiles and all this stuff, here is the quick version if you just want to test some modules.
1- download the latest apache2.2 version
2- ./configure --prefix=/targetdir --enable-so
3- make then make install
4- now grab the module you need, and run /targetdir/bin/apxs -cia yourmodule.c
done :)
August 24 2010
Online Mockup Solutions
The more I dwelve into the world of quick development (be it a Metasploit plugin or a proof of concept website) the more I feel the need to be able to quickly sketch what's in my mind.
Ok, this might have something to do with the fact that I try to delegate coding, but still, I'm always positive that shipping is a feature. Accordingly, being able to ship a design and sketch idea is better than nothing. Maybe there will be a social network one day for aborted design and ideas...
In the meantime, I've explored online solutions which lets you build a sketch (or mockup, or wireframe). I've been focusing on tools to build web sites/web applications, not binary interfaces, able to work with Chrome under Linux (or Firefox, if needed). And no lenghty registrations or lame trials.
So, here is my personal top 10 (9, ok) of mockup software
Lumzy is 100% free, and it only took me 10 seconds to sign up and be able to save projects. It can export in various format, it is easy to share projects, has a big library of ready-made objects and does even support a basic scripting language which can make the mockup browsable and actionable!
IPlotz takes a more integrated approach, providing very basic project management features which "real" designers will love. Anyway, even in its free mode where you only have one project it is as good as Lumzy
balsamiq.com, an Italian (!) startup provides very professional-looking mockups: unfortunately, they focus on the desktop version of their application. The web based editor would be superior to anything else, but it is apparent it is a demo and lacks feature such as saving or sharing.
Pencil project is a bit out of scope here: it requires a Firefox addon to be used in the browser: as such it is similar to a desktop application in the fact that it runs completely on the local machine. However, since it is embedded in the browser once it has been installed, I'm considering it here. Overall, the user experience is inferior when compared to the other solutions, even though I do appreciate the presence of various types of the same control: from a prototyping app I expect a lot of readymade components, otherwise I will just go for a standard "paintlike" software.
I appreciated Mockingbird for its great library of icons and web-oriented stuff. However, it will be non-free starting form the 1st of September, and that puts it off our competition.
In my opinion MockFlow doesn't really add anything from a tool perspective. However, it is still worth mentioning thanks to its wonderful store! Great idea.
ForeUI also only has a demo online, and in Java too. Doesn't meet the requirements, just like Inpreso which nags you with a billion popups even while you're testing it.
Fluidia looks promising but it's still in early alpha.
So, what did I like the most? In the end, I went for iPlotz: the rest are presented in my personal ranking.
PS: obviously, for the color palette I went for Kuler !
Ok, this might have something to do with the fact that I try to delegate coding, but still, I'm always positive that shipping is a feature. Accordingly, being able to ship a design and sketch idea is better than nothing. Maybe there will be a social network one day for aborted design and ideas...
In the meantime, I've explored online solutions which lets you build a sketch (or mockup, or wireframe). I've been focusing on tools to build web sites/web applications, not binary interfaces, able to work with Chrome under Linux (or Firefox, if needed). And no lenghty registrations or lame trials.
So, here is my personal top 10 (9, ok) of mockup software
Lumzy is 100% free, and it only took me 10 seconds to sign up and be able to save projects. It can export in various format, it is easy to share projects, has a big library of ready-made objects and does even support a basic scripting language which can make the mockup browsable and actionable!
IPlotz takes a more integrated approach, providing very basic project management features which "real" designers will love. Anyway, even in its free mode where you only have one project it is as good as Lumzy
balsamiq.com, an Italian (!) startup provides very professional-looking mockups: unfortunately, they focus on the desktop version of their application. The web based editor would be superior to anything else, but it is apparent it is a demo and lacks feature such as saving or sharing.
Pencil project is a bit out of scope here: it requires a Firefox addon to be used in the browser: as such it is similar to a desktop application in the fact that it runs completely on the local machine. However, since it is embedded in the browser once it has been installed, I'm considering it here. Overall, the user experience is inferior when compared to the other solutions, even though I do appreciate the presence of various types of the same control: from a prototyping app I expect a lot of readymade components, otherwise I will just go for a standard "paintlike" software.
I appreciated Mockingbird for its great library of icons and web-oriented stuff. However, it will be non-free starting form the 1st of September, and that puts it off our competition.
In my opinion MockFlow doesn't really add anything from a tool perspective. However, it is still worth mentioning thanks to its wonderful store! Great idea.
ForeUI also only has a demo online, and in Java too. Doesn't meet the requirements, just like Inpreso which nags you with a billion popups even while you're testing it.
Fluidia looks promising but it's still in early alpha.
So, what did I like the most? In the end, I went for iPlotz: the rest are presented in my personal ranking.
PS: obviously, for the color palette I went for Kuler !
August 22 2010
VASTO has a new home!
VASTO (the Virtualization ASsessment TOolkit) will leave this blog to findings only and will now be at vasto.nibblesec.org.
You can find version 0.3 right there!
You can find version 0.3 right there!
August 18 2010
Play fullscreen
My new favourite band
August 12 2010
MySQL Autobackup
Handy script to perform automatic mysql backup, the definitive backup script for MySQL!June 23 2010
Announcing VASTO 0.2
The new version of VASTO, now with Cloud tricks! VASTO 0.2 includes attacks against the Abiquo and Eucalyptus private cloud systems, and improved versions of the previously released VMware-targeting modules. You can grab a copy here.
VASTO 0.2 was released at SyScan 10 Singapore: the slides are embedded at the end of the article.
As usual, feedbacks are warmly welcome.
By the way, I'm also uploading some videos of my demo.
VASTO 0.2 was released at SyScan 10 Singapore: the slides are embedded at the end of the article.
As usual, feedbacks are warmly welcome.
Standing on the clouds
View more presentations from Claudio Criscione.
By the way, I'm also uploading some videos of my demo.
April 24 2010
March 22 2010
March 12 2010
Announcing VASTO beta
Today at Troopers10 I released the first beta of VASTO, the Virtualization ASsessment TOolkit. VASTO is being developed at Secure Network and wants to be the reference in penetration testing in virtualized environments.
You can find more information in the attached presentation, and download the binary here.
By the way, Troopers 10 was really an amazing conference, wonderful venue and great people.
You can find more information in the attached presentation, and download the binary here.
By the way, Troopers 10 was really an amazing conference, wonderful venue and great people.
February 19 2010
Older posts are this way
If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
