Never Ending Security

It starts all here

Category Archives: Vulnerability’s

3 Websites For Vulnerability Research

After doing some research, we have created a small list of websites that will help you to perform vulnerability research. Here it is,

1. Security Tracker

Security Tracker provides daily updating huge database to the users. It is really simple to use and effective. Anyone can search the site for latest vulnerability information listed under various categories. Best tool for security researchers.

2. Hackerstorm

Hackerstorm provides a vulnerability database tool, which allows users to get almost all the information about a particular vulnerability. Hackerstorm provides daily updates for free but source is available for those who wish to contribute and enhance the tool. Such huge data is provided by and its contributors.

3. Hackerwatch

Hackerwatch is not a vulnerability database, but it is a useful tool for every security researcher. It is mainly an online community where internet users can report and share information to block and identify security threats and unwanted traffic.

The Logjam Attack

In case you haven’t heard, there’s a new SSL/TLS vulnerability making the rounds. Nicknamed Logjam, the new attack is ‘special’ in that it may admit complete decryption or hijacking of any TLS connection you make to an improperly configured web or mail server. Worse, there’s at least circumstantial evidence that similar (and more powerful) attacks might already be in the toolkit of some state-level attackers such as the NSA.

This work is the result of an unusual collaboration between a fantastic group of co-authors spread all around the world, including institutions such as the University of Michigan, INRIA Paris-Rocquencourt, INRIA Paris-Nancy, Microsoft Research, Johns Hopkins and the University Of Pennsylvania. It’s rare to see this level of collaboration between groups with so many different areas of expertise, and I hope to see a lot more like it. (Disclosure: I am one of the authors.)

The absolute best way to understand the Logjam result is to read the technical research paper. This post is mainly aimed at people who want a slightly less technical form. For those with even shorter attention spans, here’s the TL;DR:

It appears that the the Diffie-Hellman protocol, as currently deployed in SSL/TLS, may be vulnerable to a serious downgrade attack that restores it to 1990s “export” levels of security, and offers a practical “break” of the TLS protocol against poorly configured servers. Even worse, extrapolation of the attack requirements — combined with evidence from the Snowden documents — provides some reason to speculate that a similar attack could be leveraged against protocols (including TLS, IPSec/IKE and SSH) using 768- and 1024-bit Diffie-Hellman.

I’m going to tackle this post in the usual ‘fun’ question-and-answer format I save for this sort of thing.

What is Diffie-Hellman and why should I care about TLS “export” ciphersuites?

Diffie-Hellman is probably the most famous public key cryptosystem ever invented. Publicly discovered by Whit Diffie and Martin Hellman in the late 1970s (and a few years earlier, in secret, by UK GCHQ), it allows two parties to negotiate a shared encryption key over a public connection.

Diffie-Hellman is used extensively in protocols such as SSL/TLS and IPSec, which rely on it to establish the symmetric keys that are used to transport data. To do this, both parties must agree on a set of parameters to use for the key exchange. In traditional (‘mod p‘) Diffie-Hellman, these parameters consist of a large prime number p, as well as a ‘generator’ g. The two parties now exchange keys as shown below:

Classical Diffie-Hellman (source).

TLS supports several variants of Diffie-Hellman. The one we’re interested in for this work is the ‘ephemeral’ non-elliptic (“DHE”) protocol variant, which works in a manner that’s nearly identical to the diagram above. The server takes the role of Alice, selecting (p, g, ga mod p)and signing this tuple (and some nonces) using its long-term signing key. The client responds gb mod p and the two sides then calculate a shared secret.

Just for fun, TLS also supports an obsolete ‘export’ variant of Diffie-Hellman. These export ciphersuites are a relic from the 1990s when it was illegal to ship strong encryption out of the country. What you need to know about “export DHE” is simple: it works identically to standard DHE, but limits the size of p to 512 bits. Oh yes, and it’s still out there today. Because the Internet.

How do you attack Diffie-Hellman?

The best known attack against a correct Diffie-Hellman implementation involves capturing the value gand solving to find the secret key a. The problem of finding this value is known as the discrete logarithm problem, and it’s thought to be a mathematically intractable, at least when Diffie-Hellman is implemented in cryptographically strong groups (e.g., when p is of size 2048 bits or more).

Unfortunately, the story changes dramatically when p is relatively small — for example, 512 bits in length. Given a value gmod p for a 512-bit p, itshould at least be possible to efficiently recover the secret a and read traffic on the connection.

Most TLS servers don’t use 512-bit primes, so who cares?

The good news here is that weak Diffie-Hellman parameters are almost never used purposely on the Internet. Only a trivial fraction of the SSL/TLS servers out there today will organically negotiate 512-bit Diffie-Hellman. For the most part these are crappy embedded devices such as routers and video-conferencing gateways.
However, there is a second class of servers that are capable of supporting 512-bit Diffie-Hellman when clients request it, using a special mode called the ‘export DHE’ ciphersuite. Disgustingly, these servers amount to about 8% of the Alexa top million sites (and a whopping 29% of SMTP/STARTLS mail servers). Thankfully, most decent clients (AKA popular browsers) won’t willingly negotiate ‘export-DHE’, so this would also seem to be a dead end.
It isn’t.
ServerKeyExchange message (RFC 5246)
You see, before SSL/TLS peers can start engaging in all this fancy cryptography, they first need to decide which ciphers they’re going to use. This is done through a negotiation process in which the client proposes some options (e.g., RSA, DHE, DHE-EXPORT), and the server picks one.

This all sound simple enough. However, one of the early, well known flaws in SSL/TLS is the protocol’s failure to properly authenticate these ‘negotiation’ messages. In very early versions of SSL they were not authenticated at all. SSLv3 and TLS tacked on an authentication process — but one that takes place only at the end of the handshake.*

This is particularly unfortunate given that TLS servers often have the ability to authenticate their messages using digital signatures, but don’t really take advantage of this. For example, when two parties negotiate Diffie-Hellman, the parameters sent by the server are transmitted within a signed message called the ServerKeyExchange (shown at right). The signed portion of this message covers the parameters, but neglects to include any information about which ciphersuite the server thinks it’s negotiating. If you remember that the only difference between DHE and DHE-EXPORT is the size of the parameters the server sends down, you might start to see the problem.

Here it is in a nutshell: if the server supports DHE-EXPORT, the attacker can ‘edit’ the negotiation messages sent from the a client — even if the client doesn’t support export DHE — replacing the client’s list of supported ciphers with only export DHE. The server will in turn send back a signed 512-bit export-grade Diffie-Hellman tuple, which the client will blindly accept — because it doesn’t realize that the server is negotiating the export version of the ciphersuite.From its perspective this message looks just like ‘standard’ Diffie-Hellman with really crappy parameters.

Overview of the Logjam active attack (source: paper).

All this tampering should run into a huge snag at the end of the handshake, when he client and server exchange Finished messages embedding include a MAC of the transcript. At this point the client should learn that something funny is going on, i.e., that what it sent no longer matches what the server is seeing. However, the loophole is this: if the attacker can recover the Diffie-Hellman secret quickly — before the handshake ends — she can forge her own Finished messages. In that case the client and server will be none the wiser.

The upshot is that executing this attack requires the ability to solve a 512-bit discrete logarithm before the client and server exchange Finished messages. That seems like a tall order.

Can you really solve a discrete logarithm before a TLS handshake times out?

In practice, the fastest route to solving the discrete logarithm in finite fields is via an algorithm called the Number Field Sieve (NFS). Using NFS to solve a single 512-bit discrete logarithm instance requires several core-years — or about week of wall-clock time given a few thousand cores — which would seem to rule out solving discrete logs in real time.

However, there is a complication. In practice, NFS can actually be broken up into two different steps:

  1. Pre-computation (for a given prime p). This includes the process of polynomial selection, sieving, and linear algebra, all of which depend only on p. The output of this stage is a table for use in the second stage.
  2. Solving to find a (for a given gmod p). The final stage, called the descent, uses the table from the precomputation. This is the only part of the algorithm that actually involves a specific g and ga.
The important thing to know is that the first stage of the attack consumes the vast majority of the time, up to a full week on a large-scale compute cluster. The descent stage, on the other hand, requires only a few core-minutes. Thus the attack cost depends primarily on where the server gets its Diffie-Hellman parameters from. The best case for an attacker is when p is hard-coded into the server software and used across millions of machines. The worst case is when p is re-generated routinely by the server.

I’ll let you guess what real TLS servers actually do.
In fact, large-scale Internet scans by the team at University of Michigan show that most popular web servers software tends to re-use a small number of primes across thousands of server instances. This is done because generating prime numbers is scary, so implementers default to using a hard-coded value or a config file supplied by your Linux distribution. The situation for export Diffie-Hellman is particularly awful, with only two (!) primes used across up 92% of enabled Apache/mod_ssl sites.

Number of seconds to solve a
512-bit discrete log (source: paper).

The upshot of all of this is that about two weeks of pre-computation is sufficient to build a table that allows you to perform the downgrade against most export-enabled servers in just a few minutes (see the chart at right). This is fast enough that it can be done before the TLS connection timeout. Moreover, even if this is not fast enough, the connection can often be held open longer by using clever protocol tricks, such as sending TLS warning messages to reset the timeout clock.

Keep in mind that none of this shared prime craziness matters when you’re using sufficiently large prime numbers (on the order of 2048 bits or more). It’s only a practical issue you’re using small primes, like 512-bit, 768-bit or — and here’s a sticky one I’ll come back to in a minute — 1024 bit.

How do you fix the downgrade to export DHE?

The best and most obvious fix for this problem is to exterminate export ciphersuites from the Internet. Unfortunately, these awful configurations are the default in a number of server software packages (looking at you Postfix), and getting people to update their configurations is surprisingly difficult (see e.g., FREAK).

A simpler fix is to upgrade the major web browsers to resist the attack. The easy way to do this is to enforce a larger minimum size for received DHE keys. The problem here is that the fix itself causes some collateral damage — it will break a small but significant fraction of lousy servers that organically negotiate (non-export) DHE with 512 bit keys.

The good news here is that the major browsers have decided to break the Internet (a little) rather than allow it to break them. Each has agreed to raise the minimum size limit to at least 768 bits, and some to a minimum of 1024 bits. It’s still not perfect, since 1024-bit DHE may not be cryptographically sound against powerful attackers, but it does address the immediate export attack. In the longer term the question is whether to use larger negotiated DHE groups, or abandon DHE altogether and move to elliptic curves.

What does this mean for larger parameter sizes?

The good news so far is that 512-bit Diffie-Hellman is only used by a fraction of the Internet,even when you account for active downgrade attacks. The vast majority of servers use Diffie-Hellman moduli of length at least 1024 bits. (The widespread use of 1024 is largely due to a hard-cap in older Java clients. Go away Java.)

While 2048-bit moduli are generally believed to be outside of anyone’s reach, 1024-bit DHE has long been considered to be at least within groping range of nation-state attackers. We’ve known this for years, of course, but the practical implications haven’t been quite clear. This paper tries to shine some light on that, using Internet-wide measurements and software/hardware estimates.

If you recall from above, the most critical aspect of the NFS attack is the need to perform large amounts of pre-computation on a given Diffie-Hellman prime p, followed by a relatively short calculation to break any given connection that uses p. At the 512-bit size the pre-computation only requires about a week. The question then is, how much does it cost for a 1024-bit prime, and how common are shared primes?

While there’s no exact way to know how much the 1024-bit attack would cost, the paper attempts to provide some extrapolations based on current knowledge. With software, the cost of the pre-computation seems quite high — on the order of 35 million core-years. Making this happen for a given prime within a reasonable amount of time (say, one year) would appear to require billions of dollars of computing equipment if we assume no algorithmic improvements.Even if we rule out such improvements, it’s conceivable that this cost might be brought down to a few hundred million dollars using hardware. This doesn’t seem out of bounds when you consider leaked NSA cryptanalysis budgets.

What’s interesting is that the descent stage, required to break a given Diffie-Hellman connection, is much faster. Based on some implementation experiments by the CADO-NFSteam, it may be possible to break a Diffie-Hellman connection in as little as 30 core-days, with parallelization hugely reducing the wall-clock time. This might even make near-real-time decryption of Diffie-Hellman connections practical.

Is the NSA actually doing this?

So far all we’ve noted is that NFS pre-computation is at least potentially feasible when 1024-bit primes are re-used. That doesn’t mean the NSA is actually doing any of it.

There is some evidence, however, that suggests the NSA has decryption capability that’s at least consistent with such a break. This evidence comes from a series of Snowden documents published last winter in Der Spiegel. Together they describe a large-scale effort at NSA and GCHQ, capable of decrypting ‘vast’ amounts of Internet traffic, including IPSec, SSH and HTTPS connections.

NSA slide illustrating exploitation
of IPSec encrypted traffic (source: Spiegel).

While the architecture described by the documents mentions attacks against many protocols, the bulk of the energy seems to be around the IPSec and IKE protocols, which are used to establish Virtual Private Networks (VPNs) between individuals and corporate networks such as financial institutions.

The nature of the NSA’s exploit is never made clear in the documents, but diagram at right gives a lot of the architectural details. The system involves collecting Internet Key Exchange (IKE) handshakes, transmitting them to the NSA’s Cryptanalysis and Exploitation Services (CES) enclave, and feeding them into a decryption system that controls substantial high performance computing resources to process the intercepted exchanges. This is at least circumstantially consistent with Diffie-Hellman cryptanalysis.

Of course it’s entirely possible that the attack is based on a bad random number generator, weak symmetric encryption, or any number of engineered backdoors. There are a few pieces of evidence that militate towards a Diffie-Hellman break, however:

  1. IPSec (or rather, the IKE key exchange) uses Diffie-Hellman for every single connection, meaning that it can’t be broken without some kind of exploit, although this doesn’t rule out the other explanations.
  2. The IKE exchange is particularly vulnerable to pre-computation, since IKE uses a small number of standardized prime numbers called the Oakley groups, which are going on 17 years old now. Large-scale Internet scanning by the Michigan team shows that a majority of responding IPSec endpoints will gladly negotiate using Oakley Group 1 (768 bit) or Group 2 (1024 bit), even when the initiator offers better options.
  3. The NSA’s exploit appears to require the entire IKE handshake as well as any pre-shared key (PSK). These inputs would be necessary for recovery of IKEv1 session keys, but are not required in a break that involves only symmetric cryptography.
  4. The documents explicitly rule out the use of malware, or rather, they show that such malware (‘TAO implants’) is in use — but that malware allows the NSA to bypass the IKE handshake altogether.

I would stipulate that beyond the Internet measurements and computational analysis, this remains firmly in the category of  ‘crazy-eyed informed speculation’. But while we can’t rule out other explanations, this speculation is certainly consistent with a hardware-optimized break of Diffie-Hellman 768 and 1024-bit, along with some collateral damage to SSH and related protocols.

So what next?

The paper gives a detailed set of recommendations on what to do about these downgrade attacks and (relatively) weak DHE groups. The website provides a step-by-step guide for server administrators. In short, probably the best long-term move is to switch to elliptic curves (ECDHE) as soon as possible. Failing this, clients and servers should enforce at least 2048-bit Diffie-Hellman across the Internet. If you can’t do that, stop using common primes.

Making this all happen on anything as complicated as the Internet will probably consume a few dozen person-lifetimes. But it’s something we have to do, and will do, to make the Internet work properly.


* There are reasons for this. Some SSL/TLS ciphersuites (such as the RSA encryption-based ciphersuites) don’t use signatures within the protocol, so the only way to authenticate the handshake is to negotiate a ciphersuite, run the key exchange protocol, then use the resulting shared secret to authenticate the negotiation messages after the fact. But SSL/TLS DHE involves digital signatures, so it should be possible to achieve a stronger level of security than this. It’s unfortunate that the protocol does not.

Raptor – A Web-based Source Code Vulnerability Scanner


Raptor is a web-based (web-serivce + UI) github centric source-vulnerability scanner i.e. it scans a repository with just the github repo url. You can setup webhooks to ensure automated scans everytime you commit or merge a pull request. The scan is done asynchonously and the results are available only to the user who initiated the scan.

Some of the features of the Raptor:

  • Plug-in architecture (plug and play external tools and generate unified reports)
  • Web-service can be leveraged for custom automation (without the need of the UI)
  • Easy to create/edit/delete signatures for new vulnerabilities and/or programming languages.

This tool is an attempt to help the community and start-up companies to emphasize on secure-coding. This tool may or may not match the features/quality of commercial alternatives, nothing is guaranteed and you have been warned. This tool is targetted to be used by security code-reviewers and/or developers with secure-coding experience to find vulnerability entrypoints during code-audits or peer reviews. Please DO NOT trust the tool’s output blindly. This is best-used if you plug Raptor into your CI/CD pipeline.


0.1 beta


Integrated Plugins (currently):

  • Mozilla ScanJS – for client-Side JavaScript, Node.JS, FireFox OS support
  • Brakeman – for Ruby On Rails support
  • RIPS – for PHP support
  • [Android] – for insecure permissions

Avaiables Rulepacks (currently):

  • ActionScript – supports ActionScript 2.0 & 3.0 source/sinks
  • Java – partial support for Android. J2EE and JSP support yet to be added.

Installation (Tested on a Ubuntu 14.04 x64 LAMP instance)

Installation Video: YouTube Install

$ wget -O
$ unzip
$ cd raptor-master
$ sudo sh



Installation Video: YouTube Usage

cd raptor-master
sudo sh #starts the backend web-service

Now point your browser to Raptor Home

Login with any username and any password (but remember the username to view scan history)

Rules Editor

You can use the bundled light-weight, GUI client-side rules editor for adding any new/custom rule(s) for your specific requirements(s) or any other plain-text editor as the rulepack files are just simple JSON structures. Use your browser to open rules located in ‘backend/rules’. When you are done, save your new/modified rules file in same directory i.e. ‘backend/rules’. All you need to do now is a minor edit, here: Init Script. Append your new rulepack filename to this array without the ‘.rulepack’ extension and restart the backend server. You are all set!

You can access it here: Rules Editor


Want to contribute? Great! Get in touch with me if you have an idea or else feel free to fork and improve. :)



GNU GPL v2.0

Free Software, Hell Yeah!

More information can be found on: and on

Securing Web Application Technologies – [SWAT] Checklist

Securing Web Application Technologies
[SWAT] Checklist

The SWAT Checklist provides an easy to reference set of best practices that raise awareness and help development teams create more secure applications. It’s a first step toward building a base of security knowledge around web application security. Use this checklist to identify the minimum standard that is required to neutralize vulnerabilities in your critical applications.


Display Generic Error Messages Error messages should not reveal details about the internal state of the application. For example, file system path and stack information should not be exposed to the user through error messages. CWE-209
No Unhandled Exceptions Given the languages and frameworks in use for web application development, never allow an unhandled exception to occur. Error handlers should be configured to handle unexpected errors and gracefully return controlled output to the user. CWE-391
Suppress Framework Generated Errors Your development framework or platform may generate default error messages. These should be suppressed or replaced with customized error messages as framework generated messages may reveal sensitive information to the user. CWE-209
Log All Authentication Activities Any authentication activities, whether successful or not, should be logged. CWE-778
Log All Privilege Changes Any activities or occasions where the user’s privilege level changes should be logged. CWE-778
Log Administrative Activities Any administrative activities on the application or any of its components should be logged. CWE-778
Log Access To Sensitive Data Any access to sensitive data should be logged. This is particularly important for corporations that have to meet regulatory requirements like HIPAA, PCI, or SOX. CWE-778
Do Not Log Inappropriate Data While logging errors and auditing access is important, sensitive data should never be logged in an unencrypted form. For example, under HIPAA and PCI, it would be a violation to log sensitive data into the log itself unless the log is encrypted on the disk. Additionally, it can create a serious exposure point should the web application itself become compromised. CWE-532
Store Logs Securely Logs should be stored and maintained appropriately to avoid information loss or tampering by intruder. Log retention should also follow the retention policy set forth by the organization to meet regulatory requirements and provide enough information for forensic and incident response activities. CWE-533


Use SSL Everywhere Ideally, SSL should be used for your entire application. If you have to limit where it’s used then SSL must be applied to any authentication pages as well as all pages after the user is authenticated. If sensitive information (e.g. personal information) can be submitted before authentication those features must also be sent over SSL.
EXAMPLE: Firesheep
Disable HTTP Access For All SSL Enabled Resources For all pages requiring protection by SSL, the same URL should not be accessible via the non-SSL channel. CWE-319
Use The Strict- Transport-Security Header The Strict-Transport-Security header ensures that the browser does not talk to the server over non-SSL. This helps reduce the risk of SSL stripping attacks as implemented by the sslsniff tool.
Store User Passwords Using A Strong, Iterative, Salted Hash User passwords must be stored using secure hashing techniques with a strong algorithm like SHA-256. Simply hashing the password a single time does not sufficiently protect the password. Use iterative hashing with a random salt to make the hash strong.
EXAMPLE: LinkedIn password leak
Securely Exchange Encryption Keys If encryption keys are exchanged or pre-set in your application then any key establishment or exchange must be performed over a secure channel
Set Up Secure Key Management Processes When keys are stored in your system they must be properly secured and only accessible to the appropriate staff on a need to know basis. CWE-320
Disable Weak SSL Ciphers On Servers Weak SSL ciphers must be disabled on all servers. For example, SSL v2 has known weaknesses and is not considered to be secure. Additionally, some ciphers are cryptographically weak and should be disabled.
Use Valid SSL Certificates From A Reputable Ca SSL certificates should be signed by a reputable certificate authority. The name on the certificate should match the FQDN of the website. The certificate itself should be valid and not expired.
EXAMPLE: CA Compromise (
Disable Data Caching Using Cache Control Headers And Autocomplete Browser data caching should be disabled using the cache control HTTP headers or meta tags within the HTML page. Additionally, sensitive input fields, such as the login form, should have the autocomplete=off setting in the HTML form to instruct the browser not to cache the credentials. CWE-524
Limit The Use And Storage Of Sensitive Data Conduct an evaluation to ensure that sensitive data is not being unnecessarily transported or stored. Where possible, use tokenization to reduce data exposure risks.


Establish A Rigorous Change Management Process A rigorous change management process must be maintained during change management operations. For example, new releases should only be deployed after process
EXAMPLE: RBS production outage (
Define Security Requirements Engage the business owner to define security requirements for the application. This includes items that range from the whitelist validation rules all the way to nonfunctional requirements like the performance of the login function. Defining these requirements up front ensures that security is baked into the system.
Conduct A Design Review Integrating security into the design phase saves money and time. Conduct a risk review with security professionals and threat model the application to identify key risks. The helps you integrate appropriate countermeasures into the design and architecture of the application. CWE-701
Perform Code Reviews Security focused code reviews can be one of the most effective ways to find security bugs. Regularly review your code looking for common issues like SQL Injection and Cross-Site Scripting. CWE-702
Perform Security Testing Conduct security testing both during and after development to ensure the application meets security standards. Testing should also be conducted after major releases to ensure vulnerabilities did not get introduced during the update process.
Harden The Infrastructure All components of infrastructure that support the application should be configured according to security best practices and hardening guidelines. In a typical web application this can include routers, firewalls, network switches, operating systems, web servers, application servers, databases, and application frameworks. CWE-15
Define An Incident Handling Plan An incident handling plan should be drafted and tested on a regular basis. The contact list of people to involve in a security incident related to the application should be well defined and kept up to date.
Educate The Team On Security Training helps define a common language that the team can use to improve the security of the application. Education should not be confined solely to software developers, testers, and architects. Anyone associated with the development process, such as business analysts and project managers, should all have periodic software security awareness training.


Don’t Hardcode Credentials Never allow credentials to be stored directly within the application code. While it can be convenient to test application code with hardcoded credentials during development this significantly increases risk and should be avoided.
EXAMPLE: Hard coded passwords in networking devices
Develop A Strong Password Reset System Password reset systems are often the weakest link in an application. These systems are often based on the user answering personal questions to establish their identity and in turn reset the password. The system needs to be based on questions that are both hard to guess and brute force. Additionally, any password reset option must not reveal whether or not an account is valid, preventing username harvesting.
EXAMPLE: Sara Palin password hack (
Implement A Strong Password Policy A password policy should be created and implemented so that passwords meet specific strength criteria.
Implement Account Lockout Against Brute Force Attacks Account lockout needs to be implemented to guard against brute forcing attacks against both the authentication and password reset functionality. After several tries on a specific user account, the account should be locked for a period of time or until manually unlocked. Additionally, it is best to continue the same failure message indicating that the credentials are incorrect or the account is locked to prevent an attacker from harvesting usernames. CWE-307
Don’t Disclose Too Much Information In Error Messages Messages for authentication errors must be clear and, at the same time, be written so that sensitive information about the system is not disclosed. For example, error messages which reveal that the userid is valid but that the corresponding password is incorrect confirms to an attacker that the account does exist on the system.
Store Database Credentials Securely Modern web applications usually consist of multiple layers. The business logic tier (processing of information) often connects to the data tier (database). Connecting to the database, of course, requires authentication. The authentication credentials in the business logic tier must be stored in a centralized location that is locked down. Scattering credentials throughout the source code is not acceptable. Some development frameworks provide a centralized secure location for storing credentials to the backend database. These encrypted stores should be leveraged when possible. CWE-257
Applications And Middleware Should Run With Minimal Privileges If an application becomes compromised it is important that the application itself and any middleware services be configured to run with minimal privileges. For instance, while the application layer or business layer needs the ability to read and write data to the underlying database, administrative credentials that grant access to other databases or tables should not be provided. CWE-250


Ensure That Session Identifiers Are Sufficiently Random Session tokens must be generated by secure random functions and must be of a sufficient length so as to withstand analysis and prediction. CWE-6
Regenerate Session Tokens Session tokens should be regenerated when the user authenticates to the application and when the user privilege level changes. Additionally, should the encryption status change, the session token should always be regenerated CWE-384
Implement An Idle Session Timeout When a user is not active, the application should automatically log the user out. Be aware that Ajax applications may make recurring calls to the application effectively resetting the timeout counter automatically. CWE-613
Implement An Absolute Session Timeout Users should be logged out after an extensive amount of time (e.g. 4-8 hours) has passed since they logged in. This helps mitigate the risk of an attacker using a hijacked session. CWE-613
Destroy Sessions At Any Sign Of Tampering Unless the application requires multiple simultaneous sessions for a single user, implement features to detect session cloning attempts. Should any sign of session cloning be detected, the session should be destroyed, forcing the real user to re-authenticate.
Invalidate The Session After Logout When the user logs out of the application the session and corresponding data on the server must be destroyed. This ensures that the session can not be accidentally revived. CWE-613
Place A Logout Button On Every Page The logout button or logout link should be easily accessible to the user on every page after they have authenticated.
Use Secure Cookie Attributes (I.E. Httponly And Secure Flags) The session cookie should be set with both the HttpOnly and the Secure flags. This ensures that the session id will not be accessible to client-side scripts and it will only be transmitted over SSL, respectively. CWE-79
Set The Cookie Domain And Path Correctly The cookie domain and path scope should be set to the most restrictive settings for your application. Any wildcard domain scoped cookie must have a good justification for its existence.
Set The Cookie Expiration Time The session cookie should have a reasonable expiration time. Non-expiring session cookies should be avoided.


Conduct Contextual Output Encoding All output functions must contextually encode data before sending it to the user. Depending on where the output will end up in the HTML page, the output must be encoded differently. For example, data placed in the URL context must be encoded differently than data placed in JavaScript context within the HTML page.
EXAMPLE: Resource:
Prefer Whitelists Over Blacklists For each user input field, there should be validation on the input content. Whitelisting input is the preferred approach. Only accept data that meets a certain criteria. For input that needs more flexibility, blacklisting can also be applied where known bad input patterns or characters are blocked. CWE-159
Use Parameterized SQL Queries SQL queries should be crafted with user content passed into a bind variable. Queries written this way are safe against SQL injection attacks. SQL queries should not be created dynamically using string concatenation. Similarly, the SQL query string used in a bound or parameterized query should never be dynamically built from user input.
EXAMPLE: Sony SQL injection Hack (
Use Tokens To Prevent Forged Requests In order to prevent Cross-Site Request Forgery attacks, you must embed a random value that is not known to third parties into the HTML form. This CSRF protection token must be unique to each request. This prevents a forged CSRF request from being submitted because the attacker does not know the value of the token. CWE-352
Set The Encoding For Your Application For every page in your application set the encoding using HTTP headers or meta tags within HTML. This ensures that the encoding of the page is always defined and that browser will not have to determine the encoding on its own. Setting a consistent encoding, like UTF-8, for your application reduces the overall risk of issues like Cross-Site Scripting. CWE-172
Validate Uploaded Files When accepting file uploads from the user make sure to validate the size of the file, the file type, and the file contents as well as ensuring that it is not possible to override the destination path for the file. CWE-434
Use The Nosniff Header For Uploaded Content When hosting user uploaded content which can be viewed by other users, use the X-Content-Type-Options: nosniff header so that browsers do not try to guess the data type. Sometimes the browser can be tricked into displaying the data type incorrectly (e.g. showing a GIF file as HTML). Always let the server or application determine the data type. CWE-430
Validate The Source Of Input The source of the input must be validated. For example, if input is expected from a POST request do not accept the input variable from a GET request. CWE-20
Use The X-Frame- Options Header Use the X-Frame-Options header to prevent content from being loaded by a foreign site in a frame. This mitigates Clickjacking attacks. For older browsers that do not support this header add framebusting Javascript code to mitigate Clickjacking (although this method is not foolproof and can be circumvented).
EXAMPLE: Flash camera and mic hack (
Use Content Security Policy (CsP) Or X-Xss- Protection Headers Content Security Policy (CSP) and X-XSS-Protection headers help defend against many common reflected Cross-Site Scripting (XSS) attacks. CWE-79


Apply Access Controls Checks Consistently Always apply the principle of complete mediation, forcing all requests through a common security “gate keeper.” This ensures that access control checks are triggered whether or not the user is authenticated. CWE-284
Apply The Principle Of Least Privilege Make use of a Mandatory Access Control system. All access decisions will be based on the principle of least privilege. If not explicitly allowed then access should be denied. Additionally, after an account is created, rights must be specifically added to that account to grant access to resources. CWE-272
Don’t Use Direct Object References For Access Control Checks Do not allow direct references to files or parameters that can be manipulated to grant excessive access. Access control decisions must be based on the authenticated user identity and trusted server side information. CWE-284
Don’t Use Unvalidated Forwards Or Redirects An unvalidated forward can allow an attacker to access private content without authentication. Unvalidated redirects allow an attacker to lure victims into visiting malicious sites. Prevent these from occurring by conducting the appropriate access controls checks before sending the user to the given location. CWE-601

WAP – Web Application Protection

WAP – Web Application Protection

WAP 2.0 is a source code static analysis and data mining tool to detect and correct input validation vulnerabilities in web applications written in PHP (version 4.0 or higher) and with a low rate of false positives.

WAP detects and corrects the following vulnerabilities:

  • SQL Injection (SQLI)
  • Cross-site scripting (XSS)
  • Remote File Inclusion (RFI)
  • Local File Inclusion (LFI)
  • Directory Traversal or Path Traversal (DT/PT)
  • Source Code Disclosure (SCD)
  • OS Command Injection (OSCI)
  • PHP Code Injection

This tool semantically analyses the source code. More precisely, it does taint analysis (data-flow analysis) to detect the input validation vulnerabilities. The aim of the taint analysis is to track malicious inputs inserted by entry points ($_GET, $_POST arrays) and to verify if they reaches some sensitive sink (PHP functions that can be exploited by malicious input). After the detection, the tool uses data mining to confirm if the vulnerabilities are real or false positives. At the end, the real vulnerabilities are corrected with the insertion of the fixes (small pieces of code) in the source code.

WAP is written in Java language and is constituted by three modules:

  • Code Analyzer: composed by tree generator and taint analyser. The tool has integrated a lexer and a parser generated by ANTLR, and based in a grammar and a tree grammar written to PHP language. The tree generator uses the lexer and the parser to build the AST (Abstract Sintatic Tree) to each PHP file. The taint analyzer performs the taint analysis navigating through the AST to detect potentials vulnerabilities.
  • False Positives Predictor: composed by a supervised trained data set with instances classified as being vulnerabilities and false positives and by the Logistic Regression machine learning algorithm. For each potential vulnerability detected by code analyser, this module collects the presence of the attributes that define a false positive. Then, the Logistic Regression algorithm receives them and classifies the instance as being a false positive or not (real vulnerability).
  • Code Corrector: Each real vulnerability is removed by correction of its source code. This module for the type of vulnerability selects the fix that removes the vulnerability and signalizes the places in the source code where the fix will be inserted. Then, the code is corrected with the insertion of the fixes and new files are created.

More information can be found at:

WebPwn3r – Web Applications Security Scanner.


Web Applications Security Scanner

WebPwn3r is a Web Applications Security Scanner coded in Python to help Security Researchers to scan Multiple links in the same time against Remote Code/Command Execution & XSS Vulnerabilities.

WebPwn3r - Web Applications Security Scanner.


  • Scan a URL or List of URL’s
  • Detect and Exploit Remote Code  Injection Vulnerabilities.
  • ~ ~ ~ Remote Command  Execution Vulnerabilities.
  • ~ ~ ~ Typical XSS Vulnerabilities.
  • Detect WebKnight WAF.
  • Improved Payloads to bypass Security Filters/WAF’s.
  • Finger-Print the backend Technologies.

More information can be found at: and at:

Wapiti – a web-application vulnerability scanner


Wapiti allows you to audit the security of your web applications.

This tool performs “black-box” scans, i.e. it does not study the source code of the application but will scans the webpages of the deployed webapp, looking for scripts and forms where it can inject data. Once it gets this list, tool acts like a fuzzer, injecting payloads to see if a script is vulnerable.

Wapiti can detect the following vulnerabilities :

  • File disclosure (Local and remote include/require, fopen, readfile…)
  • Database Injection (PHP/JSP/ASP SQL Injections and XPath Injections)
  • XSS (Cross Site Scripting) injection (reflected and permanent)
  • Command Execution detection (eval(), system(), passtru()…)
  • CRLF Injection (HTTP Response Splitting, session fixation…)
  • XXE (XmleXternal Entity) injection
  • Use of know potentially dangerous files (thanks to the Nikto database)
  • Weak .htaccess configurations that can be bypassed
  • Presence of backup files giving sensitive information (source code disclosure)

Wapiti supports both GET and POST HTTP methods for attacks. It also supports multipart and can inject payloads in filenames (upload). Display a warning when an anomaly is found (for example 500 errors and timeouts) Makes the difference beetween permanent and reflected XSS vulnerabilities.

General features :

  • Generates vulnerability reports in various formats (HTML, XML, JSON, TXT…)
  • Can suspend and resume a scan or an attack
  • Can give you colors in the terminal to highlight vulnerabilities
  • Different levels of verbosity
  • Fast and easy way to activate/deactivate attack modules
  • Adding a payload can be as easy as adding a line to a text file

Browsing features:

  • Support HTTP and HTTPS proxies
  • Authentication via several methods : Basic, Digest, Kerberos or NTLM
  • Ability to restrain the scope of the scan (domain, folder, webpage)
  • Automatic removal of a parameter in URLs
  • Safeguards against scan endless-loops (max number of values for a parameter)
  • Possibility to set the first URLs to explore (even if not in scope)
  • Can exclude some URLs of the scan and attacks (eg: logout URL)
  • Import of cookies
  • Can activate / deactivate SSL certificates verification
  • Extract URLs from Flash SWF files
  • Try to extract URLs from javascript (very basic JS interpreter)
  • HTML5 aware (understand recent HTML tags)Wapiti is a command-line application.
    Here is an exemple of output against a vulnerable web application.
    You may find some useful informations in the README and the INSTALL files.

more information can be found at:

Top 10 Internal Vulnerabilities: February 2015

Top 10 Vulnerabilities

The Top 10 External and Top 10 Internal Vulnerabilities are dynamic lists of the most prevalent and critical security vulnerabilities in the real world. Based on the Laws of Vulnerabilities, this information is computed anonymously from over 1 billion IP audits per year. The Top 10 External Vulnerabilities are the most prevalent and critical vulnerabilities which have been identified on Internet facing systems. The Top 10 Internal Vulnerabilities show this information for systems and networks inside the firewall.

The two Top 10 lists exclude vulnerabilities that do not have patches, even if workarounds are available, because these lists are tools to help prioritize remediation.

Top 10 Internal Vulnerabilities: February 2015

Title QualysID Ext. Reference
Microsoft Internet Explorer Cumulative Security Update (MS15-009)

100220 MS15-009
Oracle Java SE Critical Patch Update – July 2014

122362 Oracle Java SE CPU July 2014
Adobe Flash Player and AIR Multiple Vulnerabilities (APSB14-24)

122827 APSB14-024
MMicrosoft .Net Framework Elevation of Privilege Vulnerability (MS14-072)

90997 MS14-072
Microsoft Windows Network Location Awareness Service Security Bypass Vulnerability (MS15-005)

91007 MS15-005
Adobe Reader and Acrobat Multiple Vulnerabilities (APSB14-20)

122663 APSB14-20
Microsoft Windows Application Compatibility Cache Elevation of Privilege Vulnerability (MS15-001)

91005 MS15-001
Microsoft Windows Components Directory Traversal Information Disclosure Vulnerability (MS15-004)

91012 MS15-004
Microsoft Windows Kerberos Elevation of Privilege Vulnerability (MS14-068)

90998 MS14-068
Microsoft Word and Office Web Apps Remote Code Execution Vulnerability (MS14-081)

110244 MS14-081

Top 10 External Vulnerabilities: February 2015

Title QualysID Ext. Reference
OpenSSL Multiple Remote Security Vulnerabilities

38602 OpenSSL Security Advisory [05 Jun 2014]
Cisco IOS Malformed IPV4 Packet Denial of Service Vulnerability

43051 No Reference
Apache HTTP Server Multiple Cross-Site Scripting Vulnerabilities

12260 RHSA-2008-0004
SSL Server Allows Anonymous Authentication Vulnerability

38142 No Reference
OpenSSH Signal Handling Vulnerability

38560 No Reference
Microsoft ASP.NET Denial of Service Vulnerability (KB2659883 and MS11-100)

90764 KB2659883
SSH Protocol Version 1 Supported

38304 No Reference
Internet Information Services (IIS) Could Allow Elevation of Privilege (MS09-020)

86837 MS09-020
SSL Server Allows Cleartext Communication Vulnerability

38143 No Reference
OpenSSL Memory Leak Vulnerability (Heartbleed Bug)

42430 OpenSSL vulnerabilities

WPScan WordPress Plugin Vulnerability Database

Visit The WPScan Vulnerability Database at:

WindowsRegistryRootkit – Kernel rootkit, that lives inside the Windows registry values data

Kernel rootkit, that lives inside the Windows registry value data.

Rootkit uses the zero day vulnerability in win32k.sys (buffer overflow in function win32k!bInitializeEUDC()) to get the execution at the OS startup.


  • NDIS-based network backdoor (+ meterpreter/bind_tcp).
  • In order to avoid unknown executable code detection it moves itself in the memory over discardable sections of some default Windows drivers.
  • Completely undetectable by public anti-rootkit tools.
  • Working on Windows 7 (SP0, SP1) x86.


This rootkit was originally presented at the ZeroNights 2012 conference during my talk.
See the slides and videos for more information:

prl_guest_to_host – Guest to host VM escape exploit for Parallels Desktop

Guest to host VM escape exploit for Parallels Desktop.
Tested on Parallels Desktop 10 for Mac.

Works on all of the x86 and x64 Windows guests under the user accounts with any privileges level.

Known issues:

 * Command output might be missing when running from low-privileged user accounts.

More information at

Discovered by:    
Dmytro Oleksiuk

UEFI_boot_script_expl – CHIPSEC module that exploits UEFI boot script table vulnerability

CHIPSEC module that exploits UEFI boot script table vulnerability.

This vulnerability was discovered by Rafal Wojtczuk and Corey Kallenberg, check 
original white paper:

More detailed exploit description:


1) Download and install CHIPSEC (

2) Download and install Capstone engine incl. Python bindings (

3) Install nasm (apt-get install nasm).

4) Copy into the chipsec/source/tool/chipsec/modules.

5) Run module:
   # cd chipsec/source/tool/chipsec
   # python --module boot_script_table 


Exploit was designed for Intel DQ77KB motherboard, running this code on any 
other hardware  may lead to unexpected problems due to the different
boot script table format and location.


* Windows support (current implementation uses rtcwake Linux shell command).

* More decent boot script table decoding and dumping (incl. vendor-specific opcodes).

* SPI protected ranges dumping and checking.

Written by:
Dmytro Oleksiuk (aka Cr4sh)

Scan website for vulnerabilities with Uniscan

Uniscan is a vulnerability scanner that can scan websites and web applications for various security issues like LFI, RFI, sql injection, xss etc. Its written in perl. Its open source and can be downloaded from sourceforge project page at

It is included in backtrack and can be found at the following directory


In the Backtrack menu its located at Vulnerability Assessment > Web Application Assessment > Web Vulnerability Scanner > uniscan.

On kali linux run it directly from terminal by issuing the command ‘uniscan’.

In this post we shall learn how to use this tool to scan websites. Usage is quite simple. Run the script to see the options and examples

Basic scanning

root@kali:~# uniscan
# Uniscan project                  #
#  #
V. 6.2

	-h 	help
	-u 	<url> example:
	-f 	<file> list of url's
	-b 	Uniscan go to background
	-q 	Enable Directory checks
	-w 	Enable File checks
	-e 	Enable robots.txt and sitemap.xml check
	-d 	Enable Dynamic checks
	-s 	Enable Static checks
	-r 	Enable Stress checks
	-i 	<dork> Bing search
	-o 	<dork> Google search
	-g 	Web fingerprint
	-j 	Server fingerprint

[1] perl ./ -u -qweds
[2] perl ./ -f sites.txt -bqweds
[3] perl ./ -i uniscan
[4] perl ./ -i ""
[5] perl ./ -o "inurl:test"
[6] perl ./ -u -r

The usage section shows examples on using it. To scan a website, use the first example from the usage section.

root@kali:~# uniscan -u -qweds

The above example scans a single url. With the f option multiple sites can be put under the scanner. The list has to be provided as a txt file.


With the option ‘j’ uniscan would fingerprint the server of the url. Server fingerprinting simply runs commands like ping, traceroute, nslookup, nmap on the server ip address and packs the results together.

root@kali:~# uniscan -u -j

Another option is ‘g’ which does web based fingerprinting. It looks up specific urls.

root@kali:~# uniscan -u -g

Searching google and bing

Apart from scanning websites, uniscan has another cool feature of performing google and bing searches and collecting the results in a simple text file. The i option can be used for searching bing and o operator for google. To search bing for all domains hosted on a given ip address issue the following command

root@kali:~# uniscan -i ""

Replace the x with the ip. The results are saved in a file called sites.txt which can be found at ‘/usr/share/uniscan’. They should ideally be saved in the home directory of the user or the working directory.

To search google using a term

root@kali:~# uniscan -o 'inurl:"section.php?id="'

However google will block too many automated search queries. So use the tool carefully.

Pentesting-Tool Exploit Pack for Windows, Linux and Mac OS X +Exploit and Security Video Tutorials

Next generation exploit framework

Cyber security risk assessment and explotation
“Think like a hacker, be professional”

Exploit Packs

Get all the exploits you need in a pack for the platform you need to test. Today.
What are the Packs?

Exploit packs are distributed via web or as a bundle ( tipically a gzip file ) and contain additional modules that plug directly into Exploit Pack. Installation is usually simple, often just expanding desired tree, all the arsenal you need. Give some ammo to your weapons by upgrading Exploit Pack with Packs.

We deliver this Packs online ( using credentials ) or via a bundle Gzip, and the donations received from it are used to keep the project going.

Cross-platform Software, works for Windows, Linux and Mac OS X

For the download and more info go to:
or visit:



Security Tutorials Playlist:

Exploit Pack Playlist:

MASSIVE COLLECTIONS: Awesome, Awesome All, Awesome-Awesome, Awesome-Awesomes, Awesome Awesomeness, Awesome-Collection, Lists, Lists Of Github Lists, List of Lists, Must-Watch-List and Wiki China Lists


A curated list of awesome lists
For more info check:


Programming languages

Front-end development

Back-end development

Computer science

Big data



Awesome All

A curated list of all the awesome lists of awesome frameworks, libraries and software
For more info check:


Please take a quick gander at the contribution guidelines first. Thanks to all contributors; you rock!



A curated list of awesome curated lists! Inspired by inspiration.
For more info check:

Awesome Awesome

A curated list of amazingly awesome curated lists of amazingly awesome libraries, resources and shiny things for various languages and frameworks.
For more info check:



Common Lisp










Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language, or closely related :D
For more info check:

Feel free to add new lists or categories! Remember, it’s not mandatory that name starts with awesome- ;)

Programming languages | Frameworks, platforms, etc | Related and useful

Programming Languages


  • Awesome C – A curated list of awesome C libraries, frameworks and other shinies.


  • Awesome Clojure – A curated list of awesome clojure libraries and software

Common Lisp

  • Awesome Common Lisp – A curated list of awesome Common Lisp libraries, software and other shinies.


  • Awesome D – A curated list of awesome D documents, frameworks, libraries and software


  • Awesome Elixir – A curated list of amazingly awesome Elixir libraries, resources and shiny things



  • Awesome Go – A curated list of awesome Go frameworks, libraries and software


  • Awesome Haskell – A curated list of awesome Haskell frameworks, libraries and software



  • Awesome JavaScript – A curated list of amazingly awesome browser-side JavaScript libraries, resources and shiny things


  • Awesome PHP – A curated list of amazingly awesome PHP libraries, resources and shiny things


  • Awesome Python – A curated list of awesome Python frameworks, libraries and software



  • Awesome Scala – A curated list of awesome Scala frameworks, libraries and software

Frameworks, platforms, etc



  • Awesome Node.js – A curated list of astonishing Node.js frameworks, libraries and resources

Ruby on Rails

  • Awesome Rails – A curated list of amazingly awesome open source rails related resources


Related and useful



  • Awesome Dev Env – A curated list of awesome tools, resources and workflow tips making an awesome development environment.


  • Awesome Shell – A curated list of awesome command-line frameworks, toolkits, guides and gizmos


  • Awesome Sysadmin – A curated list of amazingly awesome open source sysadmin resources


  • Awesome Talks – List of online talks that you would love to watch


  • Awesome Machine Learning – A curated list of awesome machine learning frameworks, libraries and software (by language).


  • Awesome Awesomes – This one!! ;) Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language :D
  • Awesome Awesomeness – A curated list of awesome awesomeness
  • Awesome Awesome – A curated list of awesome curated lists! Inspired by inspiration

Awesome Awesomeness

A curated list of amazingly awesome awesomeness. Also available on:
And Github:

Awesome Awesome

A curated list of awesome curated lists of many topics, can also found on:

Computer management

  • awesome-shell – Command-line frameworks, toolkits, guides and gizmos.
  • awesome-sysadmin – Backups, configuration management, DNS, IMAP/POP3, LDAP, monitoring, SSH, statistics, troubleshooting, virtualization, VPN and more.

Data processing

Programming languages

  • awesome-clojure – Package management, audio, HTTP, database, websocket and testing.
  • awesome-c – C frameworks, libraries, resources and other cool stuff.
  • awesome-cpp – C/C++ frameworks, libraries, and resources.
  • awesome-cobol – Web frameworks, template engine, forms, authentication & OAuth, database, e-mail, messaging, imagery, text processing, machine learning, testing, audio, video and logging.
  • awesome-common-lisp – Common Lisp frameworks, libraries, resources and other shinies.
  • awesome-d – Build tools, compilers, IDE, GUI, database clients.
  • awesome-elixir – Elixir libraries, resources and shiny things.
  • awesome-go – Go frameworks, libraries and software.
  • awesome-java – Build tool, code analysis, database, GUI, IDE, JSON, machine learning, PDF, science, testing and web crawling.
  • awesome-javascript – JavaScript libraries, resources and shiny things.
  • awesome-julia – List of Julia resources and packages.
  • awesome-perl – Benchmarks, databases, images, logging, profiling, testing, text processing and web frameworks.
  • awesome-php – Frameworks, templating, URL, e-mail, files, imagery, testing, security, documentation, geolocation, date, PDF, search and authentication.
  • awesome-python – Files, dates, text processing, NLP, imagery, audio, video, geolocation, web frameworks, OAuth, web crawling, networking, GUI, game development, testing, science and data analysis and machine learning.
  • [awesome-R] – Not yet! Do it yourself!
  • awesome-ruby – Ruby libraries, tools, frameworks and software
  • awesome-scala – Scala frameworks, libraries and software.
  • awesome-swift – Swift documentation, projects, tutorials, updates, etc


  • [awesome-biology] – Not yet! Do it yourself!
  • [awesome-chemistry] – Not yet! Do it yourself!
  • [awesome-geography] – Not yet! Do it yourself!
  • [awesome-math] – Not yet! Do it yourself!
  • [awesome-physics] – Not yet! Do it yourself!

Web browsers

  • [awesome-firefox] – Not yet! Do it yourself!


  • [awesome-github] – Not yet! Do it yourself!
  • [awesome-flickr] – Not yet! Do it yourself!
  • [awesome-twitter] – Not yet! Do it yourself!
  • awesome-wikipedia – Datasets, frameworks, libraries and other software related to Wikipedia.
  • [awesome-youtube] – Not yet! Do it yourself!

Web platforms


  • [awesome-music] – Not yet! Do it yourself!


a list of awesome repos
For more info check:

awesome lists

  • Awesome – A curated list of awesome lists
  • awesome-all – A curated list of awesome lists of awesome frameworks, libraries and software
  • awesome-awesome by @emijrp – A curated list of awesome curated lists of many topics.
  • awesome-awesome by @erichs – A curated list of awesome curated lists! Inspired by inspiration.
  • awesome-awesome by @oyvindrobertsen – A curated list of curated lists of libraries, resources and shiny things for various languages.
  • awesome-awesomeness – A curated list of awesome awesomeness
  • awesome-awesomes – Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language
  • lists – The definitive list of (awesome) lists curated on GitHub. (comment: No awesome, but more awesome)

Programming languages



The definitive list of (awesome) lists curated on GitHub.
For more info check:
List of useful, silly and awesome lists curated on GitHub. Contributions welcome!




Lists of lists

  • awesome – A curated list of awesome lists.
  • awesome-all – A curated list of awesome lists of awesome frameworks, libraries and software
  • awesome-awesome by @emijrp – A curated list of awesome curated lists of many topics.
  • awesome-awesome by @erichs – A curated list of awesome curated lists! Inspired by inspiration.
  • awesome-awesome by @oyvindrobertsen – A curated list of curated lists of libraries, resources and shiny things for various languages.
  • awesome-awesomeness – A curated list of awesome awesomeness
  • awesome-awesomes – Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language
  • awesome-collection – A list of awesome repos.
  • ListOfGithubLists – List of github lists
  • list-of-lists – A meta list of lists of useful open source projects and developer tools.
  • must-watch-list – List of must-watch lists.
  • this one
  • wiki In Chinese – A curated list of awesome lists.

Lists of lists of lists

Lists of lists of lists of lists

Lists of lists of lists of lists of lists

List of github lists

Creating a github list is so trendy nowadays, so here’s another one.
Fore more info check:

Pull requests are welcome



A meta list of lists of useful open source projects and developer tools
For more info check:


Frameworks / Libraries


Other lists of lists



A list of must-watch lists
For more info check:

Overview of all lists from this post:
Awesome All:
Awesome Awesome:
Awesome Awesome:
List Of Github Lists:
Wiki China Lists:

Awesome-Awesomeness (zeef):

List with scripts from GhostInTheLab

Penetration Testing Practice Lab – Vulnerable Apps / Systems (The Most Complete List)

A complete mindmap about all the courses and trainings from this post can be found here:

Following table gives the URLs of all the vulnerable web applications, operating system installations, old software and war games [hacking] sites. The URLs for individual applications that are part of other collection entities were not given as it is not necessary to download each of them and manually configure them if they are already available in a configured state. For technologies used in each web application, please refer to the mindmap above.

Vulnerable Web Applications:
OWASP Hackademic:
OWASP SiteGenerator:
OWASP Bricks: &
OWASP Security Shepherd:
Damn Vulnerable Web App (DVWA):
Damn Vulnerable Web Services (DVWS):
Butterfly Security Project:
Foundstone Hackme Bank:
Foundstone Hackme Books:
Foundstone Hackme Casino:
Foundstone Hackme Shipping:
Foundstone Hackme Travel:
WackoPicko: &
WebSecurity Dojo:
BodgeIt Store:
Exploit KB Vulnerable Web App: &
PHDays iBank CTF:
Drunk Admin Web Hacking Challenge:
bWAPP: & &
NOWASP / Mutillidae 2:
Project GameOver:
OWASP Vicnum Project: &
Hackademic Challenges:

Vulnerable Operating System Installations:
Damn Vulnerable Linux: &
Metasploitable: &
UltimateLAMP: &
heorot: DE-ICE, hackerdemia
DE-ICE, hackerdemia:
DE-ICE, hackerdemia:
DE-ICE, hackerdemia:
DE-ICE, hackerdemia:
De-ICE HackerPedia PenTest LiveCDs
pWnOS: & &
Holynix: &
exploit-exercises – nebula, protostar, fusion:
PenTest Laboratory:
RebootUser Vulnix:
SecGame # 1 Sauron:
Pentester Lab:
TurnKey Linux:
Elastic Server:
Virtual Hacking Lab:

Sites for Downloading Older Versions of Various Software:
Old Version:
Old Apps:
VirtualHacking Repo:

Sites by Vendors of Security Testing Software:
Acunetix acuforum:
Acunetix acublog:
Acunetix acuart:
Cenzic crackmebank:
HP freebank:
IBM altoromutual:
Mavituna testsparker:
Mavituna testsparker:
NTOSpider Test Site:

Sites for Improving Your Hacking Skills:
Exploit Exercises:
Google Gruyere:
Gh0st Lab:
Hack This Site:
Hacker Challenge:
Hacker Test:
hACME Game:
Root Me:
Security Treasure Hunt:
Smash The Stack:
TheBlackSheep and Erik:
XSS – Can You XSS This?:
XSS – ProgPHP:

CTF Sites / Archives:
CTFtime (Details of CTF Challenges):
shell-storm Repo:

Mobile Apps:
ExploitMe Mobile Android Labs:
ExploitMe Mobile iPhone Labs:
OWASP iGoat:
OWASP Goatdroid:
Damn Vulnerable iOS App (DVIA):
Damn Vulnerable Android App (DVAA):
Damn Vulnerable FirefoxOS Application (DVFA):
NcN Wargame:
Hacme Bank Android:


Debugging and Detecting problems with SH, Bash or the Shell

Spellcheck, paste the shell script with errors or problems on the spellcheck website and it automatically detects the problem.

Go to Spellcheck by visiting this site:

Or you can watch the source code on github at:

Bash Pitfalls is an collection or errors that can show up in the Bash, complete with a description of the error.
It can be found on:

JAW: Java Applet Wizard, that makes you go java Meterpreter by payload

JAW: Java Applet Wizard
JAW is written in Python and comes in 2 flavors.

Flavor 1: Java applet maker using a meterpreter executable.
To do client-side attacks using evil java applets:

Flavor 2: Java applet maker using a java meterpreter – full java attack script
By using Metasploit java meterpreter payload:

NSA Documents: Attacks on VPN, SSL, TLS, SSH and Tor