-->

  • TryHackMe JWT Json Web Tokens

     


     

     

    Json Web Token's are a fairly interesting case, as it isn't a vulnerability itself. Infact, it's a fairly popular, and if done right very secure method of authentication. The basic structure of a JWT is this, it goes "header.payload.secret", the secret is only known to the server, and is used to make sure that data wasn't changed along the way. Everything is then base64 encoded.  TryHackMe JWT Json Web Tokens



    so an example JWT token would look like 

    "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibm

    FtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fw

    pMeJf36POk6yJV_adQssw5c"


    Meaning that if we are able to control the secret, we can effectively control the data. To be able to do this we have to understand how the secret is calculated. This requires knowing the structure of the header, a typical JWT header looks like this {"typ":"JWT","alg":"RS256"}. We're interested in the alg field. RS256 uses a private RSA key that's only available to the server, so that's not vulnerable. However, We can change that field to HS256, This is calculated using the server's public key, which in certain circumstances we may have access too. instashell


    Manual JWT Exploitation

    We start off with a basic application




    With a JWT, and a JWT verifier. Sending it garbage results in a failure, so let's try decoding the JWT.






    Decoding the JWT gives us our header, payload, and a bunch of garbage which is the secret. instashell github
     





    Unfortunately it seems the algorithm is RS256, which doesn't have any vulnerabilities. Fortunately for us though, this server leaves its public key lying around, which means we can change the algorithm and sign a new secret! The first step is to change the algorithm in the header to HS256, and then re encode it in base64.  hacking truth

     

    Our new JWT is eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0

    IiwiaWF0IjoxNTg1MzIzNzg0LCJleHAiOjE1ODUzMjM5MDQsImRhdGEiOnsiaGVsb

    G8iOiJ3b3JsZCJ9fQ.FXj9F1jIXlhMyoQAo5-XPOiZeP4Ltw5XXZGqgX49tKkYUOeirOXUDgWL4bqP9nRXIODqOByqS_9O11nQ

    N5bC_LTpfBWG2WZXg0tKIDAbKTxVkrytXBmOkP1qRK_Apv-CQs-mouuS1we8SHYShW_r4DEj0qAF3dsWVVzbRWNMH4Oc_odHNogv00dVlABcxMy

    XFpNJbeRS6-GCS-A4SFM32gMv_mkfkXrQPdejKDU_sKZrD5VVAmDlu0BainIvD28l8uV3OCc37shtPW

    0TKoIwUXmGsFYouKqk-h0dz4aTBLKJk7L64XdrA7ts1oOtzk8KqV6gnqXDXUNkzDX3qd9JKA


    The next step is to convert the public key to hex so openssl will use it.





    (Explanation: a is the file with the public key, xxd -p turns the contents of a file to hex, and tr is there to get rid of any newlines)

    The next step is to use openssl to sign that as a valid HS256 key.




    Everything is going just fine so far!. The final step is to decode that hex to binary data, and reencode it in base64, luckily python makes this really easy for us.




    That's our final secret, now we just put that where the secret should go, and the server should accept it.

    So our final JWT would beeyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.<payload>.<new secret>




    Automatic JWT exploitation


    Due to the fact that JWT tokens often expire, there's no real way to guarantee that finding the public key is possible, and that there is no way to keep the data portion of the JWT consistent, there aren't tools avaliable that automatically exploit JWT vulnerabilities. JWT vulns have to be exploited on a case by case basis.

    Now that doesn't mean you can't write a script that does everything automatically for a specific website that you know is vulnerable, it's just that by the time you succeed in doing that, you could have already exploited the vulnerability.


    Challenge!


    The challenge is effectively the exact same application shown in the Manual exploitation section. If you succeed in exploiting it, you will get the flag!

    The public key can be found at /public.pem.

    Generated JWT tokens will also expire after a certain amount of time, so if you don't get it the first try, try doing it faster!

    Note: some recommended reading here :-  Click Here



    Intro


    In addition to the previous vulnerability, certain JWT libraries have another devastating vulnerability. There is actually three possible algorithms, two of them RS256 and HS256 which we have already studied. There is a third algorithm, known as None. According to the official JWT RFC the None algorithm is used when you still want to use JWT, however there is other security in place to stop people from spoofing data.


    RFC :- Click Here


     



    Unfortunately certain JWT libraries clearly didn't read the RFC, allowing a vulnerability where an attacker can switch to the None algorithm, in the same way one switches to RS256 to HS255, and have the token be completely valid without even needing to calculate a secret.


    #1 Remember to read the RFC when your developing a library.


    Manually exploitating the JWT None vuln

    We start off with a simple login application.




    Logging in gives us a user screen, as well as a JWT token.




    Let's examine that token in the wonderful site jwt.io





    (Very nice site btw, definitely recommend for all your jwt needs)

    Now let's try changing the alg field to none, get rid of the signature, and change the role to admin. That leaves us with this final jwt token. eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdXRoIjoxNTg1MzQ1ODg0MjA0LCJhZ2

    VudCI6Ik1vemlsbGEvNS4wIChYMTE7IExpbnV4IHg4Nl82NDsgcnY6NjguMCkgR2V

    ja28vMjAxMDAxMDEgRmlyZWZveC82OC4wIiwicm9sZSI6ImFkbWluIiwiaWF0Ijox

    NT

    g1MzQ1ODg0fQ.

    The interesting this is we still need is a second . to denote that a signature would be there, even though we don't put anything after it. Let's try popping that token in where the cookie is supposed to be.the linux choice shellphish




    Automatic Exploitation


    There is no tool that can check the library, get the token, and make sure this is vulnerable. Therefore, you're gonna have to do this manually. The header for each JWT none vuln though is the same, which can help you out. Here's the header

    eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0

    Which decodes to {"type": "JWT", "alg": "none"}


    #1 What is the flag?


    JWT once again


    Recall that JWT HS256 is calculated using a secret.The exact format of the calculation is

    HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

    Therefore, it stands to reason that, since we have the full jwt token, and the header and payload, the secret can be brute forced to obtain the full JWT token. If the secret can be brute forced then the attacker could sign his own JWT tokens.


    Bruteforcing JWT tokens.


    To brute force these secrets we'll be using a tool called jwt-cracker. The syntax of jwt-cracker isjwt-cracker <token> [alphabet] [max-length] where alphabet and max-length are optional parameters.


     

    Explanation of Paramaters:


    Token: The HS256 JWT token


    Alphabet: The alphabet that the cracker will use to check passwords(default: "abcdefghijklmnopqrstuvwxyz")
     

     

    max-length
       

    The max expected length of the secret(12 by default)

    Using an example token from jwt.io lets see how long it takes to crack.




    In 4 seconds, we've tried 300000 passwords and cracked the secret!




    [Bonus Section]: Challenge


    Given the following token
    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibm

    FtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.it4Lj1WEPkrhRo9a2-XHMGtYburgHbdS5s7Iuc1YKOE

     

    What is the secret?

    Ans :- Please mention in comment below






    Disclaimer



    This was written for educational purpose and pentest only.
    The author will not be responsible for any damage ..!
    The author of this tool is not responsible for any misuse of the information.
    You will not misuse the information to gain unauthorized access.
    This information shall only be used to expand knowledge and not for causing  malicious or damaging attacks. Performing any hacks without written permission is illegal ..!


    All video’s and tutorials are for informational and educational purposes only. We believe that ethical hacking, information security and cyber security should be familiar subjects to anyone using digital information and computers. We believe that it is impossible to defend yourself from hackers without knowing how hacking is done. The tutorials and videos provided on www.hackingtruth.in is only for those who are interested to learn about Ethical Hacking, Security, Penetration Testing and malware analysis. Hacking tutorials is against misuse of the information and we strongly suggest against it. Please regard the word hacking as ethical hacking or penetration testing every time this word is used.


    All tutorials and videos have been made using our own routers, servers, websites and other resources, they do not contain any illegal activity. We do not promote, encourage, support or excite any illegal activity or hacking without written permission in general. We want to raise security awareness and inform our readers on how to prevent themselves from being a victim of hackers. If you plan to use the information for illegal purposes, please leave this website now. We cannot be held responsible for any misuse of the given information.



    - Hacking Truth by Kumar Atul Jaiswal



    I hope you liked this post, then you should not forget to share this post at all.
    Thank you so much :-)



  • 0 comments:

    Post a Comment

    For Any Tech Updates, Hacking News, Internet, Computer, Technology and related to IT Field Articles Follow Our Blog.