Skip to main content

Posts

Useful Burp Suite Extensions

  JSON Web Tokens - Easily recode the token and modify the request. Burp Bounty - Authorize - check Broken Access Control AuthMatrix - Auth Priv Esc Checks Broken Link Hijacking - Active Scan ++ J2EEScan Hackvertor - used for encodings of various types Param Miner -
Recent posts

Insecure Deserialization Cheatsheet

 Any class that implements the interface java.io.Serializable can be serialized and deserialized. If you have source code access, take note of any code that uses the readObject() method, which is used to read and deserialize data from an InputStream. The native methods for PHP serialization are serialize() and unserialize(). If you have source code access, you should start by looking for unserialize(). Basic Serialization - look for cookies with base64 encoded or some kind of searialzed you can update the admin;b:0 to admin;B:1 --> which makes us admin PHP - Exploiting Data Types - Look for cookies and any other serialized values - Update the user value or the username to any user - if required update the access token, serialize it and try to access unauthorized data Example Update the data from O:4:"User":2:{s:8:"username";s:6:"wiener";s:12:"access_token";s:32:"msai659yp7cfu0magd7vm3siq9ls2cld";} to O:4:"User":2:{s:

XML External Entities - XXE Cheatsheet

 XML External Entity (XXE) attacks are a type of security vulnerability that exploit weaknesses in the processing of XML data. These attacks occur when XML input containing a reference to an external entity is processed by a weakly configured XML parser, allowing an attacker to access the file system, carry out server-side request forgery (SSRF), or even execute remote code. XXE vulnerabilities arise due to dangerous features in the XML specification, which are often enabled in standard parsers. Attackers can leverage these features to perform actions like viewing sensitive files, interacting with back-end systems, or escalating the attack to compromise servers. Preventing XXE requires secure coding practices, such as disabling external entities and using fewer complex data formats. XXE Detection Request Body contains ' <?xml version="1.0" encoding="UTF-8"? >' Content Type header is 'text/xml' Basic XXE - add it in the request parameters <

Create a Docker Container in the Host network

  #Start a new container - which has the same ip as Host Container docker run -it --network host kalilinux/kali-rolling #Start a container docker start Container_ID #Attach a container docker attach Container_ID ctrl+p & ctrl+q to detach from a container without killing it #Start a container in Detached mode docker run -d --network host kalilinux/kali-rolling #Start a container in bridge network #Default is bridge network docker run -dit --name test kalilinux/kali-rolling /bin/bash Bridge network = new Docker network - separate network Host = Docker Host network #Create a bridge network docker network create --driver=bridge my_bridge_network --subnet=10.10.10.0/24 --gateway=10.10.10.1 #Run the container in Bridge network docker run -it --name my_container --network my_bridge_network --ip 10.10.10.2 ubuntu:latest

Recommended TLS Ciphers

Recommended TLS Ciphers list which mitigates most of the TLS/SSL vulnerabilities.  TLSv1.3: - 0x13,0x01 TLS13_AES_128_GCM_SHA256 - 0x13,0x02 TLS13_AES_256_GCM_SHA384 - 0x13,0x03 TLS13_CHACHA20_POLY1305_SHA256 TLSv1.2: - 0xC0,0x2B ECDHE-ECDSA-AES128-GCM-SHA256 - 0xC0,0x2F ECDHE-RSA-AES128-GCM-SHA256 - 0xC0,0x2C ECDHE-ECDSA-AES256-GCM-SHA384 - 0xC0,0x30 ECDHE-RSA-AES256-GCM-SHA384 - 0xCC,0xA9 ECDHE-ECDSA-CHACHA20-POLY1305 - 0xCC,0xA8 ECDHE-RSA-CHACHA20-POLY1305 - 0x00,0x9E DHE-RSA-AES128-GCM-SHA256 - 0x00,0x9F DHE-RSA-AES256-GCM-SHA384

Attacking JSON Web Tokens - JWT Pentesting

  sign an unsigned token, the process is as follows.  unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  signature_encoded = encodeBase64(HMAC-SHA256("secret", unsignedToken))  jwt_token = encodeBase64(header) + "." + encodeBase64(payload) + "." + signature_encoded JWT is not vulnerable to CSRF (except when JWT is put in a cookie) Session theft through an XSS attack is possible when JWT is used Improper token storage (HTML5 storage/cookie) Sometimes the key is weak and can be brute-forced Faulty token expiration JWT can be used as Bearer token in a custom authorization header JWT is being used for stateless applications. JWT usage results in no server-side storage and database-based session management. All info is put inside a signed JWT token. - Only relying on the secret key - Logging out or invalidating specific users is not possible due to the above stateless approach. The same signing key is used for everyone. #HMAC S