← All talks

Dealing with Undocumented Network Services: Discovering Vulnerabilities in Mikrotik Routers

BSides Budabest · 202527:4171 viewsPublished 2026-02Watch on YouTube ↗
Speakers
Tags
About this talk
Ali Abed Al Hadi reverse-engineers the undocumented Winbox network service in Mikrotik routers through traffic analysis and black-box testing. He discovers a user enumeration vulnerability, develops an Nmap service probe for Winbox identification, and shares his journey from curiosity to CVE disclosure and upstream contributions to Nmap.
Show original YouTube description
Ali Abed Al Hadi: Dealing with undocumented network services This presentation was held at #BSidesBUD2025 IT security conference on 21st May 2025. https://bsidesbud.com All rights reserved. #undocumented #backdoors #services
Show transcript [en]

Okay. So, so welcome back after the lunch break into the afternoon session. Now, we'll we'll start in just a few seconds with Alli here who's all set and he's raring to go. So, I'll hand you over to Alli. Uh thank you very much. Uh uh okay. So, hello everyone. Uh I am Ali. Uh I would like to talk about uh dealing with undocumented uh network uh services and after this this will be the general umbrella. uh under this I will talk about uh a vulnerability that I have discovered in microic routers and also I will talk about uh a service probe that I have developed for NMAP which is for the windbox uh network service and uh the windbox is a network

service in uh in in the microic router and also I will talk at the end uh about the uh the the router OS uh NSE script that I have also uh developed for the UNM map. Now before I start uh I would like to thank uh my two best friends Khaled Sapha and Muhammad Zishan for uh supporting me uh in my whole journey. And also I would like to thank some uh some of my instructors are uh are attending also here. So I would like to thank them for uh for supporting in in this uh journey. Okay. So uh let's start. Uh so who am I? Uh I'm studying a masters in cyber security at Elte. uh I have a

CVE as I mentioned uh before and I also developed three modules for the uh end map. Now let's start with general uh definitions uh before uh I start uh with the the timeline of my vulnerability. So uh in the microick router uh there is the running operating system is called the router OS and inside this router OS there is a network service that's called Windbox. uh Windbox uh this service is used to uh administer or to manage uh the router and it typically uh runs on port 8291 and also um it uh uh there is a specific uh application that's called Windbox client. uh this application can be used to uh to uh to manage uh the router and

also uh I would like to mention that uh this uh network service uh supports two modes of uh of authentication legacy and non-leacy uh authentication. So now I think this is enough for the as a general overview. Let's talk a bit about the uh timeline. So I would like to mention the timeline of my achievements from the seed to the fruit and uh and also I would like to uh so why I would like to to talk about the timeline uh hopefully the students that are like me uh so they can get some motivation that they can do some uh like what I did and and also they can do better and I hope also uh professionals can get some

motivation from uh this hopefully. So let's start with the first uh with the first uh uh uh uh slide in my time timeline. So in July 2024 I actually I was curious uh I had a microick router and I was curious how Windbox client is able to communicate with the router. So for this actually I have captured some uh some uh I did some traffic analysis of the communication between Winbox client and the router and uh I analyzed them and I was able to uh to craft uh the payload and so I was able to communicate manually with the router and after that actually uh I left this I didn't know that I did some something new or

something special and after a certain time actually uh I came back after a few months uh for this and it came to my mind that uh to try and map if it can identify this uh network service which is as we as we talked about it's called winbox and I uh I noticed I noticed that nm mapap cannot identify this uh service so what did Uh uh I I posted on the GitHub uh issues about this. I posted that I can uh I can uh I know how to communicate with the uh with this kind of network service. So I'm wondering why map is not able to identify this network service. Actually I thought from the

beginning map is able to identify all all kinds of network services. So someone in the GitHub actually uh uh uh commented on my post on the issues that yeah Anmab cannot uh u cannot identify this kind of service. So it will be good if you uh if you contribute with this. So this was a motivation for me actually to go ahead and send to the creator of the map Mr. Gordon Leon about this and I got a positive feedback from him about this thing and uh actually I didn't expect actually that I will get a reply uh from him but he replied after half an hour actually after I sent my email and this was the main motivation for me to

go on and start with developing the service probe. I finished the service probe. Uh this is uh this is the comment that I posted on the unmap issues. So I finished the service probe and before one day doing the pull request uh to the end mapaps uh GitHub uh I discovered the vulnerability in the in the router and so I decided to delay the pull request of the uh of the of the uh of the service probe because I was because I was uh worried that this service probe might leak some information about the vulnerability. So uh so I delayed it and I contacted the vendor which is Microte about this vulnerability and I got a

confirmation after that from them uh that uh the vulnerability exists and uh the uh service probe uh does is not directly related to the vulnerability and I can post it on uh NMAP's GitHub. So I completed and I did a pull request for my uh service probe on the NM maps GitHub. After that I applied for the CVE and uh in November 2024 uh I got a message from Microte actually that the fix is ready and after that I got the CVE accepted in February 2025 and I published the CVE uh also in this time and in March in March 2025 I uh I did uh uh the the the uh the the modules that I have contributed to the

end map uh were got merged. Uh I want to at the end of the timeline I want to mention uh something important that uh what I have done uh would have never existed if I didn't have if if I was not committed and curious and uh motivated uh to do this work. Uh so uh now uh so now let's start talking about the microtic uh windbox service probe. Uh so uh before uh before we start I would like to mention that all of my work uh is uh in a blackbox uh fashion and there is no any documentation about uh the this uh network service and all of the information that I will mention I

gained from I either from uh common sense or by following the trial and error uh methodology. So now uh let's talk about uh the service probe. So uh what are the main two parts of the service probe? Uh the the service probe consists of uh two parts. The first part is the request payload and the second part is the response payload. So let's start with the request payload. What is the request payload? The request payload is the magic word that we have to send to the router in order to uh trigger the router to send us a response or in other words it's hello it's how to say hello in the language that the router understands. So

if we see here in the first image like we sent uh the uh one two three in bytes and so the router sent back uh this me message uh a response whereas when we sent 111 the router was wondering what's this and we didn't get any uh any response from the router. So uh now uh this is uh this was an introduction about the request payload. So let's mention now how I was able to craft the request uh payload. So uh after as I mentioned before after take and after taking many uh packet captures of the communication between the Windbox client and the router I analyzed uh the request payload that were being sent by

Windbox client uh to the router and this this is the final uh payload request payload that I have uh crafted uh I would like to mention uh one point here uh so as we mentioned that this uh network service covers uh the legacy and non-leacy authentication modes so but uh for my talk I will just mention about the non-leacy because they are almost they almost have the same way of uh behavior so it's enough uh for here to let's let's just focus on the non legacy payload payload. So uh now let's talk a bit about this payload. So this payload uh if you see that the first two bytes uh are considered the headers of the

payload and the other byes are the data of the payload. So uh let's let's see now what do this uh what do these uh pay uh the headers what do what do they mean? So uh before uh the the the data the the the length of the data after the header is 34 bytes and the length of the header is two bytes. So now let's see what do uh the headers uh what does what do the headers mean? So the first bite is the the 22 byte. Uh uh yeah. So if we try to convert the 22 to decimal. So uh we will get 34. So 16 * 2 + 2 it's 34. So 34 uh represents the size of the

data of the payload. And uh now what about 06? The second bite in the uh in the payload. it represents uh the authentication mode. So 06 is for the non-leacy authentication mode and 05 is for the leg legacy authentication mode. So uh so now what's the per person uh what's the purpose or what's the meaning of this payload that I have uh crafted. So it has two purposes. The first one is it sends uh it asks the router what kind of authentication do you uh do you uh support. This is the first thing and the second thing it sends a username but here of course you cannot see any username because this is the uh this is

the payload that I crafted. This it has an empty username. It does not send any username. So basically it tells the router uh first do you uh do you support non-leacy authentication mode and uh after that it tells the router please keep uh the username as empty and so after that uh the router will uh respond back if it responds back with the response with the that starts with 06 we will talk about the response in the next slides uh it means that uh the router supports this and windbox the client goes on and sends in the second uh the second payload uh the password but I will not cover uh the sec uh the second

payload which is about the password now let's uh go back to the request uh payload and focus on it so now let's try the request payload that I have crafted let's so uh now if you see in the first uh picture I tried to connect to the router with netcat without sending anything. I didn't get any answer. Whereas in the second uh in the second photo as you see I sent the payload that I have crafted and uh and you see that the we have I have triggered the router and the router sent back a response and now it means that we succeeded in uh like this is the first step uh to communicate with the router. we are we

succeeded to to trigger a response from the router using this uh specific payload. So now let's talk about the response payload. So now why the response payload is important? So now suppose that we send we sent the uh the payload uh the request payload uh and we got an answer but how can we know that the answer that we got is related to wind books? maybe some other services sent back other response. So how can we guarantee that the the the uh the uh the the response from the router is uh related to windbox. So uh how can we know? So the answer for this uh we should know the patterns of the response from the

router. As you see here now the the client got uh got a response from the router and the client is checking is this first bite 03 is the second bite 02. So if if all if it matches the uh the uh if it matches the pattern of this uh network service. So the client uh will uh knows now that this is uh this is a winbox. This is a microic router running Windbox network service. Uh now let's see some uh samples of the uh uh samples of the responses from the router. So as you see here uh these are some of the responses of the uh router. So uh let's see what are the patterns in uh

this uh in this uh uh response payload. I will give you some few minutes I want to drink. So maybe if you can spot some uh patterns on it.

So I think you probably guessed the two patterns. Okay. So let's see what are they. So uh so the first one is 21 and 06. Now as as a side note like the exclamation the hex representation of the exclamation mark is 21. So as you see like here in all of the responses uh 21 is always uh 21106 is always uh presented. Now the second I think you didn't guess this uh all the the the data after every uh after the header which is the first two uh byes they are 32 bits and they are random bytes in all the situations. Uh I think you guessed the third one. The uh the the last payload is always

either 0 0 or 01. And this is I think uh we cannot guess this quickly. So uh by looking at it. So uh the response size is always 35 bytes. So these are the patterns of the response. So now this is the complete uh windbox uh service probe that I have developed. Uh you can see that the first uh this represents the uh request payload and this represents the patterns or the match of the uh of the payload and this part all of it uh is related to the uh non-leacy part. So uh now let's talk about the vulnerability that I have uh discovered in the microtic routers. I would like to to mention one thing that actually uh

the I wouldn't have reached to the I wouldn't have noticed the vulnerability if I didn't uh so the service prop helped me to uh to notice the vulnerability in the uh router uh in the microtic router. So what does the vulnerability represent? It's it represents a discrepancy in size and the response size. So uh so uh when we always when we send a u a valid username so the the router will send back uh uh the uh response uh response payload that starts with 31 hex uh when it's invalid it will send back uh 21 hex. So let's see these are two different kinds of responses that I was I was I got uh when I was

doing my uh my research and I was wondering what do uh what do these represent and it came to my mind that this this might be related to uh related to this kind of vulnerability that the router leaks. So which uh usernames are valid and which uh other usernames are not valid. And I would like to mention uh uh one uh in hex is 31 and as we said before the exclamation mark is 21 in hex. So let's see let's uh see uh let's uh see a proof of concept of this. This is the router that I have access to and uh as you see that the two valid usernames in this router is admin and

the prop. So keep in your mind please now about the prop and let's let's uh try uh this. So this is so I sent uh this uh in the first picture the this payload uh this is the user prop and if you see here it triggered the response it starts with one so it means now prop is a valid username whereas here I sent a username as any and so uh the response uh starts with an exclamation mark so it means that this is invalid. I want to mention one thing like one of the uh mechanisms that if you remember that the request payload uh was before 22 whereas now it's 26. Why? Because uh this is how a

windbox protocol works. So it uh so it incre So we have here prop is four characters. So it increment and it increments the length of the username to the uh to the uh to the 22. So here prop is four. 4 + 2 is 26. So yeah, this is uh this is how it uh works. And now uh yeah, now there is one issue. Uh so we mentioned that now the router uh sends back two different kinds of uh responses. But now for the for our service probe, we want to uh to we want to try like to get a unified response from the router. So we have to find a trick for this. So we don't so we don't

want a response. Sometimes it starts with 31 and sometimes starts with 21. This is okay. We can make two matches for the service probe. But but it's better why not if we can do one match and it will be unified for all versions of the non-leacy. So what was the the trick here? So if you remember that we said that in the uh request payload the the first uh request payload that I have crafted it sends an empty username and this if you and uh this empty username always triggers a response with an invalid uh with an invalid response. Why? Because we can never create a username inside the router with an empty username. So yeah, this this was the

trick for uh for getting a unified uh response from all versions of the uh non-leacy uh authentication mode. So now uh the first uh the the second so so far we I have covered the vulnerability that I uh uh discovered in the microte routers also uh also I have mentioned the about the service probe. Now uh I have also um contributed uh to the end map uh an NSE script that can detect the exact version of the router. So uh the service probe actually can just detect whether this uh service is uh windbox or not but it cannot know the version of the router. So now how can we know what what's the payload that we should use to

uh get the exact version of the payload. So now uh how did I get this payload? While I was searching in shenan I used this uh query. So port 8291 and uh and null bite as a uh string. Uh so why I chose null bite? uh because I want uh to see all the reported payloads on this port and uh and I chose Z null bite specifically because I think it's the the most common uh used uh bite in the payload. So I got I got some uh interesting uh payload as you see here. This is this is really interesting payload for me. Why? because it contains a word that uh as index. This is the first thing and the second

thing it reflects the same uh thing that we mentioned before. So this the the first bite if we convert it to decimal it represents the size of the data after the first two bytes. So I got that this might be related to uh the two wind books also because it represents the same it works in the same way. So uh this what I did also I got this uh as a string uh and I put it and I also got uh them to verify that they are uh uh existed and also I checked some other uh platforms which is FUFA and I saw this uh this payload is also there. Now let's test this payload. So now uh this is the

payload that we that we got from shodden like it ends uh this is uh I tried to send it to the router but I didn't get any answer whereas after uh I thought that I will have to edit these two two bytes to to flip them to uh to switch them to uh null bite. Uh I tried this and unfortunately I got an answer from the router and this is the version of the router 6.47. 47.10 and uh yeah this is the uh this is uh the router OS NS NSE script so you can read about it more here. uh this is uh I also the third module of the end map I didn't mention about it's just the

exploit for the CVE that I have uh that I have discovered and these are the references and I want to mention that uh what uh using the same techniques that I did in shenan I was able to get uh some uh payload for now this is now it's for a Microsoft service I will I will Uh I will post this on the LM maps GitHub uh soon. So if you are interested keep keep an eye on my uh GitHub. Uh what I will do also I will do a pull request for the meta for a metas-loit module for the vulnerability that I have uh discovered and also I I will update the service probe the winbook service probe because

after the fix they did some they changed the way of the uh of the identification of the of the windbox network service. So yeah, this is all and thank you very much.