The HMAC Trap: Security or Illusion?

Okay, welcome to Passwords Con again. We're glad everybody is here. Just some reminders. Um, as we've announced before, we'd like to thank our sponsors, uh, Prismacloud and Vanta, our diamond sponsors, also our gold sponsors, Adobe and Simgrip. it's along with their uh support and also the support of everybody including yourselves and all the volunteers and everyone that makes uh this conference possible and thus passwords con possible as well. So cell phones if you have a cell phone on you please put it on silent so that uh everybody can enjoy without any disruption. um photos. Uh please don't take the besides Las Vegas photo policy is not to take photographs of anybody without their consent whether they're a speaker

or whether they're an attendee or whether they're inside or outside or whatever the story is. I believe the speaker said it's fine to take photos if you want to of her or her content. Um but anybody else in the room please don't take any pictures that includes anyone else without their consent. HMAC uh yeah we use it everywhere. I think many of us think that we are quite good at how we've secured it. So looking forward to this talk especially the HMAC trap security or illusion. So we'd like to invite Isney to handle this part for us. >> Thank you. Hello everyone. Um so today we're going to be talking about HMAC. Um is something like you said is

everywhere. we use it quite often even though we sometimes don't realize that that's the thing. Um so let's go ahead and just get right into it. So my name is Marloan Clearary but I also go as it's better to remember that way. Um um currently I'm a penetration tester. I love to find out how to break into things, how to fix things. Um, and I also, um, like to share that knowledge in a blog that I host on hexbads.com. And this content will also be up there. So, if you guys want to take pictures is fine. Um, but other than that, it will be uh available later uh, tonight. So, I love the beach. I'm from Puerto Rico, so

that is my go-to. Love sushi and yeah, pandas. So, that's my spirit animal. So, that's a little bit about myself. So today, what we're going to be talking about is a little bit about what HMAC is. I will have some demos. Um, they're actually pre-recorded videos because I didn't want to test the demo gods on this today. So, we're just going to go ahead and have the pre-recording parts and then we're going to go over a little bit of best pract uh best practices, what things you guys can do whether you're a developer or um in any realm on the cyber security field, what things you should be looking out when it comes down to HMAC. And then towards the end,

we'll have some takeaways and questions that you guys may want to ask me. So out of every single topic that I can possibly have, why HMAC? So like the quote says there, security is not a product, it's a process. So before I became a penetration tester, I was a system security engineer. And my job was to go through the designing phases of a system and trying to figure out what is the best way to make them cyber security resilient and secure. Now I go to work one day and my client says you need to sit in this me in this call and see what is going on with HMAC. And at that point I did not know what it was. I'm being

quite honest about it. And um so I sat down and it came down to three things at the end of that meeting. Can we do we have to implement it? Can we accept the risk and not have it? Or if we do have it, how long is it going to take for us to have it implemented? Now what it became just a research of a high level overview of the threat landscape with or without it. It became like a challenge for me. So I needed to understand, okay, if I how hard is it for somebody to implement the HMAC, right? Is it going to be just a few lines of code? Is it going to

break something else? So I needed to take it upon myself and figure that out. So before I did all of that, I needed to find out what HMAC was. So we know what MAC is. So the message authentication code is a short string of bits used to verify the integrity and authenticity of a message right. So a message is generated with a share key between the server and the client and that message alongside with the share key creates the MAC value. Right? So unlike hashes, the MAC has a better resistance when it comes down to tampering um because it requires a secret key in order for it to work. Um it also ensures the integrity

unlike the digital signatures. You will always know who send that message based on that. Now we know what MAC is but what is HMAC right? So the HMAC also attached the hashing function which I'll show you guys here in a minute. So we have here the sender, right? It's going to have the same share key between them and the receiver. We have the message and the combination of the share key and the message creates the MAC value. Once that message is sent over to the receiver, if they if they do match, that means that the data has not been altered. So the receiver end will go ahead and use that same key and that message and make sure that the value

that he received is the same. If it doesn't match, then that means that the data has been altered. And well, there's a problem. You either have two things that will happen. either the data packet will just drop or you have to go ahead and reinitiate the transformation of that data set again. So [sighs] HMAC comes along. So HBback is just adding the hash base into the cryptographic function for Mac. So this will just have any cryptographic hash that you want to implement into it and then it will just go ahead and generate a code and send it over um alongside with the message. So why is it important? The HMAC just ensures the confidentiality, right? It's

ensuring that all the sensitive information that is going to be accessible only for authorized systems. It also maintains the integrity. So all the data that has been sent is not being modified by nefarious people. And then it guarantees the availability that once it is actually what is intended and it goes where it needs to be uh that you're going to get that message. So in this case HMAC how does it work? So we have Alice here because she's the the person of this year and she wants to send a message to the Mahhatatter right. So she has her message and she has a key that she shares with the Matt Hatter. Now once she's done with the message,

she's going to go ahead and attach the HMAT value into the message is going to send that over. Once that um message is received by the M header, if the secret key um is going to compute the HMAP value that came alongside with the message. Once that is done, um, if it is good and has not been altered, everybody's happy, everybody can see their message. If they don't, then that means that there's some type of tempering going on. There's a mismatch between the values, probably some um logging and and troubleshooting might have to happen, but you know, we never know. So, um, that is one of the main things that we need to be very

careful about it. So things like the TLS will also use HMAC when it comes down to the authentication and the mismatching um and the rejection of connections if they don't match. So once I have all that information send it over and and in my brain I needed to figure out okay how do I make this work? So I created a simple client and server uh Python environment in my home lab right and then there's four things that are very critical when it comes down to implementing HMAC. Uh one of them you need to import the HMAC library you also have to make sure that once you do that you select the hashing algorithm to import. So the hash lib in this

particular scenario is just imported in MD5, not the secure, but that's what we're going to start with. And then we're going to go ahead and call for the secret key. Not also the greatest secret key, but it just get the point across. And after that, what is going to happen is I'm going to go ahead and generate a message. that message is going to go ahead and associate the secret key and put it into um a hashy method for the MD5 and it's going to send that over. This particular pieces of information is really important because it has to match between client and server. It cannot be different otherwise the message is not going to go you're going to have a fail.

So let's go ahead and take a look at how that looks like. So in this particular scenario on the left side you guys are going to see my server is going to going to have a listening port on 1 2 3 4 5 waiting for a connection from my local um host. So I'm just going to go ahead and start typing um hello besides Las Vegas 2025. And from my client I'm going to go ahead and send that to my server. Now this is going to show us that the message has been received. There is my HMAC value right over there and then it was verified. So both computations between the HMAC and the server and the

client is the same. So I had no issues there. Great. So next I was okay. So, how do I go about trying to figure out what happens if somebody gets my message and the HMAC value? So, we're just going to go ahead and see if we can crack it. So, we go to hashcat and assign it the MD5 mode because that's what I had. Um, and then there it is. So, now I have my HMAP value, I have my messages, and I have the secret key. So this was a major milestone for me because I'm like okay so what else can I do with it right? So the next step is like let me just go ahead and go a

little bit further and just go ahead and try shot 256 just for the heck of it because why not. So go ahead and send that message hello again to my server. I got the shot 256 there it was verified. All is good. And then I'm just going to go ahead and go to hashcat and see if I'm going to be able to get away with that again. So in this case, it took a little longer, but I still was able to find the secret key within Rocku. Um, in there.

So now that I know how it looks when it does work, I needed to figure out what happens if I am able to intercept the data packet. So that's when we started to look into data packet manipulation. So for this particular scenario, I use a burp suite um B app called nope. Um, and I had to create infinangle with the with the client server in order to get the HTTP request um, crafted so this demo could work. Um, so I'll show you guys what that looks like. So here I already have no proxy already installed. So the first thing that we need to do in order to get this to work is turn off the

proxy setting from Burpswuite. So once we do that, we go into the nope proxy

and once we're there, we're going to go into the server configuration settings. So here we're looking into our server um information. So we're going to use the 8080. We're looking for our local port and 1 2 3 4 5 as our listener. We're going to start our intercept also. And once we do that, we're just going to go over to my client and server environment, and I'm going to see what happens when I turn that on. So, I'm going to go ahead and type a message. And you can see that the connection has been established from my local host into the server, but nothing came through, right? So I'm going to go ahead and go

into the burp suite and I can see that my message is there and the hmat value is also there. So I want to say so what happens if I just modify a little bit before sending the packet over to the server. So I added some stuff in the message like hello are you there? And I go ahead and forward that message over. Now based on all the information that we have discussed so far, it should fail, right? Because the match the message and the HMAP value should not be the same. And that's what happened. We have a integrity check fail right there. Meaning that whatever I send the HMAT value of that message should not be

that. Therefore, it didn't work out. So I went ahead and tried to send another message and just like hello somebody there. Same thing here. Connection is established. I go back to Burpuite and this time I'm just going to go ahead and send that over. Um it was better for me to see if it's actually working. Um so integrity verified everything is good. The HMAP values is the same. No issues there. So what happens if I try to go ahead and modify the HMAT value instead of the message? So, I went ahead established the connection again and then I'm going to just change a few of the characters of the HMA value and I'm going to send that over

and in this particular scenario it also failed. So the server is doing everything in in their end to make sure that whatever the message is the hmap value is also the same. If it's not it's just going to go ahead and discard it. So now that we know that I wanted to see how does this look in Wireshark, right? So, go ahead and and have my little server and client going on. And I'm just going to go ahead and just craft a message.

It was verified. Everything was good. I go to wire chart looking for that data packet. And I'll just go ahead and follow the TCP dump for that. I'm going to zoom in because I, you know, I wear glasses, I can see. And once I have that, I'm going to craft that into a hash.txt file. And I'm gonna take all of that into hashg and see if I can um crack it and get the key.

So after long time thinking and there is Mikey.

So now that we have covered a little bit of how the client and server communication kind of interacted um this from this point on we're just going to see a little bit of examples of different attacks and methods that people uses when it comes down to HMAC. Um, all of the values that you're going to see here for the for the algorithm is going to be chapter 56. Um, and the word list that I'll be using is a crafted one. So, I'm not going to use rocku we'll be here forever. So, uh, very just simple proof of concepts when it come down to this. So, we have the information. We know that the keys are the most valuable pieces of

information when it comes to HMAC. Uh so once I do that, can I do more? So in this case, let's say that we have been able to get information from somebody um that is trying to login into a server, right? So we have all that information. We have an admin user. we have their HMAC and we know what the algorithm is. So we're just going to go ahead and try to do a dictionary track to brute force and see if we can get the key. Now once we have that key then everything is anything can go right. Um let's see if that goes any faster.

All right. So, I was able to find that that user was using secret one 123. And now that I have the actual key, I'm just going to go ahead and do a message. So, anything that goes from this point on, when it comes down to the messages, I can introduce a malicious payload in there. It doesn't matter. The server is going to take it as true because I have the one important piece of that and that's going to be the key.

So in this case, I'm just going to go ahead and send a message called like I found you. And I'm just going to go ahead and see if that is going to come back as a true and then it was received successfully.

All right. So next we have what do we do um if we modify the timestamps. So in this particular scenario we have an HMAP value that is protected by timestamps which everybody should use when it comes down to implementing HMAC. Anyways, um the server is going to check for the check um for the timestamps of value when I send my messages over and if there is any type of discrepancy a type of replay attack is happening the actual HMAP value and the message is going to change throughout a period of time. So at that point the payload itself is going to be too old and the server is going to be you know what I don't know

what you're trying to do. This is not working. It already expired. So here I'm just verifying that the hmat value is true. Oh no, there you go. So I know that the hmat value is true and that's right. So then I try it again and it went to a false. So that means that the time stamp itself within the HMA value on the server has already changed,

which is what we see right here as a result.

So again, it is invalid. It's too old. I don't recognize it. The server is going to go ahead and try it again. And that's the best way to counteract what it we're talking about, replay attacks. So now that we know what replay attacks work, how about timing attacks? So the timing attack is a little bit of a flaw when it comes down to it. So if you have a string comparison with an equal equal on the actual HMAC implementation, the attacker can actually measure how long would it take to get the right hmap value. And so in this case um I know that the false comparison because I changed something in the Mac is approximately

320 milliseconds. Right? So what if I just take a few of the characters out of the HMAT value and see what I get for timing. So I still have a comparison of time. So what if I just remove everything and just try the first character here for the hmat value. So now it's 5 seconds. So within the timing attack we have a way that the attackers can indicate okay I am getting close to knowing what the hmat value it is for this and they just keep like hammering towards everything until they get the right amount and the right characters in here. So the closer they are to get it right the less amount of time will be on that

counter.

Next we have the logic bugs. So this is something that has been seen in the wild before. It's just a matter of understanding how to implement the logic when it comes down to the server and the presence of the HMAC in here. So in here, I'm just going to go ahead and paste a different message that it was originated before with a different HMAT value that is probably not what hello world should be. And once I do that, everything is going to come back to true. So if the attacker send whatever garbage they want to send, whatever malicious payload is in there, the server doesn't know how to respond to that. So everything is going to be

true even if the HMAC value is not accurate or if the message itself is not accurate. So that will eventually get you your actual um server compromise at that point. So we also have HMAC presence on Java web tokens. And in this one, in this particular scenario, we have a user that goes by admin one low privilege person just somebody, right? And then we have here what their Java web token looks like. Once we go over that, we can just do an um an analysis of it and we break it down. Okay, so we have uh hatching algorithm for shot 256 there. Um we know what type of token it is. We know the username and the role and it signature.

So, in order for all of the Java web tokens to work in a secure manner, you should have the signature requirement flag implemented there because if you don't, I'll show you guys what. But, um, so we have an admin one, the user, and a secret key. So, we know what all of those things look like because I was able to do a Bruce for attack. Um, because my secret key is not the best.

Now, in order for us to make sure that the Java web tokens are secure, we need to make sure that the header is showing up. The algorithm none is not there. You always should have the signature requirement in there because otherwise the server will skip the verification and it will accept any token that sends through with without the key.

All right, so we're down to the best practices. So everything around HMAC revolves around the keys. So the stronger the keys, the better you are. We should not be using P user passwords when it comes down to creating keys. Is going to be probably easy um to crack. So we want to make sure that we avoid that. Um once the key is compromised, then everything will work and until that key is changed. So unless you change it uh you will be compromised for the duration of that key on that server. I would recommend um establishing a key management plan. Find out what length the key should be. Implement key rotation so that way you're not stuck with the same key for

eternity or six months depending on who you work with. Um establish audits and revocation. So, if there's something within the audit locks that you guys see that is kind of like iffy about it, then go ahead and revoke that key. Try to figure out the steps to issue a new one. Next, we need to make sure that all of those keys have a strong algorithm. CHA 256 is okay, RSA, SHA 3, um, all of those things will actually be able to help you guys secure those keys. Um, never hardcode the keys in the configuration files. That's just just not good practice. Um, and apply lease privilege. Not everybody needs to have access to all the keys. Um, so make sure

that those are also part of your key management plan for securing the code. Make sure that you include the timestamps and the nonsense. uh the nons um that will help the server identify if there's any type of replay attack trying to happen and everything was just gonna get dropped by it. So that's a good thing to to do. Um validate timestamps rejected and reuse any um expired messages just get them thrown out. that will also alleviate the issues with the timing and attack replays and also secure comparison functions. So in this case um you should have for if you're writing stuff in Python you should have an HMAC compare digest. So it's just going to make sure

that it's going to compare what the server is getting and what the client is sending. That way you don't have to have through any go through any of the issues that you might encounter if you don't have that. For the Java web tokens, uh like I said, make sure that you have nice um and strong keys. Also, algorithm validation. Just make sure that that flag is also included that you don't have the alg none in there. and also key rotation. Make sure that you rotate those Java web tokens keys when you're signing them off. And for takeaway, so HMAC is still a way to protect from unauthorized access and message tampering and forgery. Um, but

it's going to be as strong as you implement those. So if you use strong algorithms, if you have the random generation of keys and if you can go ahead and update the secret key and keep it safe, then you should not have any issues with HMAC at all. Um, HMAC is not broken. It's just misused, mismanaged sometimes. Um, so just I don't want you guys to think that just because you have a strong algorithm, everything's just there. um you need to make sure that you have the proper way to manage and safeguard those keys because those keys are technically the key to the kingdom when it come down to the server. And I think that is it. So I'm open for

questions if anybody has one. Yeah, >> it's coming. It's coming.

Um to what extent and in what context do uh timing attacks on HMAT comparisons occur in the real world? Uh in particular over the network is would be relevant for my work but uh in general >> in particular with what? I'm sorry couldn't hear you. >> Uh in particular over the network would be particularly relevant. In this particular scenario, the timing replay I already had access. So I'm just assuming a breach. So the likelihood of that happen is not as high as you would think on the regular like on the network. >> I don't necessarily think it's particularly likely, but I'd like to know I'd like to know their opinions. Yeah, that is something that I still

need to delve into and research more. But yeah, >> okay, let's take uh this one. Start with you. >> Thank you. Um thank you for this talk. Um I had a question about time stamp uh the inclusion of the time stamp in the HMAX. So, first of all, are there any best practices for the actual mechanics of doing that like concatenating it to the payloader um or whatnot? And then the second question was or I guess second part of that question is do you have a recommended like maximum clock drift um after which you're you would like no longer accept um uh an expired time stamp I guess. So for for the for the projects I was working on um we

added the time stamp for 30 to 40 seconds. And that is going to depend on your system cuz in in my case it was something that I cannot have too long or too short because that will create a delay on whatever was going to happen. going to talk about it but um that is going to depend on your system and your architecture. So in my case it was 30 to 40 that was based on the mission that it had back then but it can be shorter. It can be probably 5 seconds.

Uh I was wondering did you actually uh implement a timing attack? Um or was it just sort of like theoretically I mean you know the timing was shorter for the shorter one. Um I just tried to I'm just curious because I've tried implementing timing attacks before and it's extremely difficult for me and I just was wondering if you had any tips um that so in this particular case um it was an assumed bridge and it was like super simple. It was just a matter of understanding how the timing rotation it is. And you are right, it's going to take longer because there's many sequences and according to the longer of the algorithm, the the more inputs you

will have to have. So no, I do want to uh but no, for this example, it's just a matter of showing you guys what the difference will be between a correct input and a and an incorrect one. Yeah, I I I want to meet somebody who's actually successfully implemented timing attacks because I've even tried introducing artificially long timing delays and it still doesn't work. I'm like, why is this not working? I don't. So, I'd love to find somebody who could do it. >> But another thing that we and I know we all hear about all the buzzing about quantum computing. So that is something that it will affect all of this hashing algorithms and all of this

implementation. So something that you guys need to also take into consideration on one this old boom happened about quantum and and all the things that are going behind it. Then we might need to find better implementations when it come down to securing our hashes and maybe time time based attack will actually be a little shorter. [snorts] >> Okay, we still got time for some more questions. Also, I mean, we can have it as a discussion as well. So, if you would like to answer a question that's been asked or if you have an example that fits in, you can do that as well. >> Yeah. And just as part of the story, I don't know if they implemented it or not

because I moved on from that project. So, who knows? I did recommend it to implement it though. >> Okay, let's go back here.

Hello, I'm back. Um, >> welcome back. >> Thank you. Um, so in some of the frameworks that I've worked in, I've seen mention of uh password-based key derivation functions. Do you have like any recommendations on whether or how to use those in deriving your shared secrets? >> [sighs] >> So, I don't I don't like the password derivation piece of things. I understand why people do it. It makes sense. Um, but as far as the implementation of it for secret keys to HMAC, is it a good key? So, those are the questions that you have to see. How long is it? How good of a key is it? And can you use it? Definitely don't use secret

one, two, three. like that's just a given. But um with all the changes about password um length and all the things that we have to do now is like 20 characters long or all of that. So there might be some type of leeway that you can use them, but I just don't recommend that. >> Cool. Any any further questions? I was thinking about the best practices that you're mentioning um over there. Was anyone in this morning's talk that could that uh could just remind everyone what uh there was an issue. No one here was in this morning's talk. Okay. I was hoping somebody could bring it up. Okay. Um, it was about the secret keys and about how you keep and about

how uh everyone loves putting their code on GitHub and sending all of these secret keys. And um if you get a chance, watch it as well because it ties in well with this talk because it shows just how bad the exposure is of uh secret keys and the keys used for the derivation of HMAC keys that people are just leaving lying around facing the internet and uh yeah anybody can just gain access. Obviously it then takes the hard work out of doing all all of this because your keys are now just lying around um and it's easy like that. So uh yeah so that ties in well you know keeps the thread going about how that best

practice comes into your HMAC security as well. No more questions if there's none then we'd like to thank uh >> thank you