Apache Wicket is an open-source, server-side, Java web application framework and used by quite a few big sites. It is discovered that the ‘encrypted url feature‘ is expected to protect from CSRF (Cross-Site Request Forgery) attacks, but it fails to provide enough protection against CSRF attacks Apache Wicket. Vulnerability Management Tool can stop these attacks.
Encrypted and stateful URLs can be defeated by leveraging CryptoMapper, the default encryption provider in Apache Wicket before 1.5.13, 6. x before 6.19.0, and 7. x before 7.0.0-M5. It is a fact that the default security settings of CryptoMapper to encrypt URLs is not strong enough to protect against all type of CSRF attacks. Along with CSRF, Apache Wicket is also prone to other attacks, such as reflected XSS, due to weak cryptographic protection. A Vulnerability Management Software is the solution for this.
Request mapper CryptoMapper typically registers itself as a root request mapper in a wicket web application. It encrypts URLs generated by another mapper. The original URL (segments and parameters) is encrypted and represented as a URL segment. Apache Wicket had this great idea of encryption so that it will stop an attacker from guessing the URL and thus stop an attacker from doing CSRF and other attacks.
Defeating Encrypted URLs in Apache Wicket:
Apache Wicket’s default implementation, ‘org.apache.wicket.util.crypt.SunJceCrypt,’ uses the PBEWithMD5AndDES method to encrypt and decrypt the data. The security of this Password-Based Cryptography is ultimately dependent on one or more secret text values or passwords. The loophole is that the implementation uses the default password ‘WiCkEt-FRAMEwork‘. This fixed key allows an attacker to easily decrypt the URLs and generate valid URLs to use for cross-site request forgery and other attacks. Many sites don’t bother about changing the default password.
How to defeat Encrypted URLs using the default password:
The attacker chooses two default passwords, ‘WiCkEt-CrYpT’ and ‘WiCkEt-FRAMEwork’, as shown in the script decrypt.py. And the password hashing is with MD5 (with salt and 17 rounds). And this hash is used as a key to decrypt encryptionURLs ‘mXHxTzUe5kU/mXH2c/HxTd3’, ‘jLBQXvh2Z88wFVtnKfsZMw/jLB0f’, ‘jLBQXvh2Z8_9tdbDCVb40AGz9WkLG1XqXeRj081Q1Jcz4Ns6k8UYfQ/jLB0f’. The attacker is able to decrypt the URLs successfully with the default password ‘WiCkEt-FRAMEwork’ as shown below.
The attacker can now use this URL, modify it accordingly, and embed it as a picture in the victim’s site (eg, some game profile), as shown below. And when the victim is logging in attacker can see this request on behalf of the user.
Source: www.smrrd.de
Some attackers are not bothered about the content inside the URL to conduct an attack; an attacker can just embed a URL like <img src=”http://www.example.com/jLBQXvh2Z88wFVtnKfsZMw/jLB0f?gold=9999&user=samuirai”> after seeing a form like below, So changing the password or choosing a stronger algorithm doesn’t protect users from CSRF attack.
Source: www.smrrd.de
Defeating Stateful URLs in Apache Wicket:
Apache Wickets stateful URLs are more difficult for attackers to defeat than encrypted URLs. The version number is for stateful pages; the first number usually increments while visiting different pages on that site. While the second number increments on multiple refreshes on a single page. This actually makes guessing of URL difficult for an attacker. But this also can be easily bypassing through a collection of URLs as given below,
Source: www.smrrd.de
As shown in the above diagram, the encryption URLs with version numbers (stateful URLs) are pushing to decryption using the decrypt.py with the default password ‘WiCkEt-FRAMEwork’ as shown below.
Thus it can lead to a cryptographic replay or playback attack, in which a valid data transmission is maliciously or fraudulently repeated or delayed.
Workaround:
Apache Wicket should be configurable to use org.apache.wicket.util.crypt.KeyInSessionSunJceCryptFactory uses the individual session random encryption key, its session, and UUID to generate it so that every visitor uses their own encryption key (different HTTP session). In the Password-Based Encryption mechanism, The “Salt” and “Iterator count” is public, but with a strong encryption key (session + UUID) like above, it just makes the Wicket’s URL encode function very hard to decode, even if you have the wicket’s source code on hands. And even strong encryption techniques implementation like AES or SHA is optimal instead of DES.
Solution:
The users using the g Apache Wicket feature are giving the recommendation of upgrading to:
– Apache Wicket 1.5.13
– Apache Wicket 6.19.0
– Apache Wicket 7.0.0-M5
It would be nice if you could share your decrypt.py script.