 Hi everyone, welcome to a talk hacking the supply chain about the ripple 20 vulnerabilities that ought hundreds of millions of critical devices Little bit about us JSOF. So JSOF is a software security consultancy. We do a lot of security research penetration testing We help companies with their secure development processes as well as some training My name is Shlomi Oberman. I'm a co-founder at JSOF together with me today We'll be speaking Moshe Kahl a security researcher at JSOF and the finder of the ripple 20 vulnerabilities and Arielle Sean a security researcher at JSOF that was also heavily involved in the research We'll be talking about ripple 20 in general today Expending what it is and how it evolved then we'll be going into detail about one of the vulnerabilities the vulnerability We find the most interesting out of the ripple 20 vulnerabilities Short spoiler here. It's one CVE, but we'll actually be talking about several vulnerabilities hiding behind this one CVE And then we'll be going in-depth into exploitation on a specific vulnerable device With a specific configuration So what is ripple 20 ripple 20 is a series of 19-0-day vulnerabilities in a TCP IP stack called Trek TCP IP We say 19-0-day vulnerabilities, but it sort of depends how you count. There are quite a few More discrete bugs in these 19 vulnerabilities and two of the vulnerabilities were reported anonymously at the same time as we reported So depends how you count these vulnerabilities were amplified by the supply chain to affect hundreds of millions of devices in all kinds of verticals Medical a lot of critical devices industrial control enterprise and a bunch of others We'll explain how this came to happen Out of the ripple 20 vulnerabilities for the vulnerabilities are critical remote code execution vulnerabilities and An additional eight vulnerabilities or eight CVEs are medium to high severity vulnerabilities Some of which could also potentially lead to remote code execution pending further research if anyone wants to go into that The vulnerabilities affect hundreds of difference of medium devices from brand names you all know We currently have over 100 different vendors with suspected affected devices meaning The different vendors are looking into these devices to see if whether they're affected or not these includes fortune 500 global 500 companies such as those You see on the slide as well as one person specialty shops and Quite a large range and diverse range of vendors You can see the ripple 20 vulnerabilities in medical devices when you go to the hospital in your home in your company When you turn on the light when you turn on the water Transportation devices are affected by ripple 20 pretty much everywhere you go. You'll see IOT devices in general as well as specifically devices affected by the ripple 20 the vulnerabilities Our current assumption based on what we know the suspected devices as well as the confirmed devices Meaning the different vendors confirmed the devices are affected We assume every medium to large Organization the US has at least one vulnerable device, of course Some networks have many more devices such as data centers or utility companies But even any other kind of organization might have a affected printer a Hospital might have affected IV pumps, etc How did this come to happen? So this happened because of the supply chain And security in the supply chain not in the sense that somebody put a backdoor into a component Built in another country but in the sense that a piece of code a library Had a vulnerability like any software has vulnerability and this piece of code was sold to an operating system It was then sold Onwards to a system on module and the system on module embedded the operating system with our vulnerable library and from this point Nobody even knows they're using this piece of code this piece of track DCP IP stack This system on module is then used in different devices such as IV pumps and the whole Chain becomes vulnerable. Just imagine what happens if one of the companies along the way goes bankrupt or ceases operation Just how difficult it is to track down the vulnerable devices and how complex it is to fix and patch and so you have a Network of devices a network of different vendors each selling to each other to create final products Built like Lego from different pieces and different parts and then in one part at the very beginning of the supply chain Sort of strategically located at the beginning of the supply chain gets affected by a vulnerability Different devices along the supply chain get affected. This is what happened with ripple 20 and this is why it affects so many devices So why did we choose to do this research on practice IP and why we think it's important for the security industry as a whole well For starters this this aspect of the supply chain of vulnerabilities Existing in the supply chain not as backdoors, but just as regular vulnerabilities and traveling rippling From device to device in this ripple effect. This is something that is mostly unexplored. It's been discussed. We've seen some examples But ripple 20 is very a prime example of what happens When a vulnerability is located this deep in the supply chain and exists for so many years so there's one vulnerability multiple products huge impact and And this is quite the beginning of a discussion of what should be done to to fix these types of vulnerabilities Another interesting thing is for us. It was of course a good attack surface and going forward There's the potential for zombie vulnerabilities the zombie vulnerabilities These type of it's complicated vulnerabilities. We don't know if they're one days We don't know if they're zero days quite a few of the vendors. We believe won't be patching Either they'll they don't know they have trek the devices can be patched companies went bankrupt And so you have these walking dead vulnerabilities that are supposed to be patched They've already been Reported, but they still exist in the wild. So this is quite an interesting phenomena both for us as well as from the industry Trek specifically Was chosen because it's an extremely successful tcp IP stack Used widely in the embedded Device world in the IOT world and has been available for over 20 years So during those 20 years or 20 something years it's spread throughout the supply chain From device to device from vendor to vendor and reached its current Current scope current impact One thing that's very interesting about track tcp IP made our Life quite challenging and made the lives of network operators challenging is that the track stack is extremely configurable So every instance of track is slightly different. It depends when the vendor stopped Supportive track what version of track they're using it also depends how they compile track Come Specific configuration options specific features they bought or did not bought How they're using what memory manager they're using etc. And so Every version of the trek looks Trek stack looks different and the vulnerabilities change So some vulnerabilities affect different devices differently. Some devices are affected by some of the vulnerabilities some devices are affected by More extreme versions of the vulnerabilities whether others are affected by lesser versions. So Very complex very complex to understand and of course at the very very beginning of a long supply chain So track doesn't incorporate any other components Which is not not something that we can say about any of the other devices affected which all incorporate different components including trick The research itself because track is so configurable. We had to take a few data points We use six different devices. We spent Different time a different amount of time on each device In order to understand what we're dealing with in order to find variations of the vulnerabilities In order to understand whether certain vendors made changes of their own to the stack or to the compilation And so we use six different devices with differing architectures in order to Understand what's going on where this stack is how the stack is used the research Took approximately nine months with changing differing intensities throughout this time started September 19th We report the vulnerabilities June 20th June 2020 of course And then we discovered some things after the fact as well For example while trying to bypass our company firewall in order to see if the vulnerabilities route over the internet We discovered that because track DCP IP stack allows for encapsulation You could also encapsulate these vulnerabilities attempting to bypass firewalls So we were able to bypass our firewalls and at least some of these vulnerabilities will write route over the internet As with any research Involved in IOT especially with so many different devices. We saw some pretty strange architectures pretty strange firmware Firmware's and firmware structures the device will be talking about today has one of these Unique architectures. We can't talk about everything in the scope of 45 minutes. Of course, these are very complex detailed Things the exploitation of all the vulnerabilities is something that we won't be able to go into in depth We did release two white papers with full details as well as pseudo code And specific references to the devices and the memory Configurations that we exploited feel free to look them up on our site if you want to go into further technical detail A little bit about the vulnerability or the CV that we'll be talking about today So CV 2020 11901 is a critical vulnerability in the track DNS resolver component So client side DNS vulnerability once successfully exploited it allows remote code execution As we've demonstrated and as you'll see today The reason we think it's so interesting and the reason we chose to talk about it besides being remote code execution Is the fact that DNS traverses net boundaries so? Device within your network will issue a DNS request which will potentially travel over the internet allowing sophisticated high-end attackers To perform an attack from outside the network into the network itself Which is different from most vulnerabilities. We've seen TCP IP stacks behind the scenes For vulnerabilities one what we call an artifacts. That's a bug that made it easier for us to exploit And these vulnerabilities vary Over time so along the years Trek changed these the stack and the vulnerabilities changed So we see different versions of the vulnerabilities in different devices depending on when they stopped using Trek They also change between vendor configuration one of the interesting things that we realized during this research and As well as during the disclosure process we realized that the supply chain Complexities are a real problem for information security. They're real problem for the vendors they're real problem for the network operators and they create a challenge for the whole industry and We realize this is bound to happen again, right? We didn't research the whole TCP IP stacks. There are other TCP IP stacks there are other pieces of code libraries that exist in the supply chains that have been lurking around for years and This should also be the beginning of a conversation about what the vendors and what the network operators can do to both Reduce the impact of Vulnerables like this when they happen using things like exploit mitigations as well as how We perform such complex disclosures and how we make sure there are as vendors how the vendors make sure that their Suppliers are performing secure development pen testing their code Etc. So this is sort of a wake-up call to some of the vendors and some of the network operators That this will happen probably again and again and this can be prevented or at least the impact can be reduced You've been using the right techniques Now I'm going to hand over the microphone to Moshe call. We'll be talking about the different vulnerabilities Where they are in the code and what they look like Thanks, Lomi. Hi, I'm Moshe. I'm security researcher at JSO And I will talk about the vulnerabilities that comprise CVE 2020 11901 also known as the DNS bugs So first we need to refresh our memory about the DNS protocol. So DNS is a core internet protocol Designed to map between domain names and IP addresses. It's a query response protocol Client server architecture. So the client resolves the name by issuing a query to a DNS server So, for example, if you browse to www.example.com your browser issues a DNS query of type A to one of the configured DNS Servers and the servers look up to the name and returns a response In this case of type A the value of the response is an IPv4 address So a little bit about the record types So DNS servers can return multiple answers in the same DNS response and answer is specific As a resource record. Each resource record is associated with a name. We'll talk about the type and class fields shortly The TTL field specifies the number of seconds This record is valid. The value of the record is specified in the Rdata field Whose lengths is specified in the RD lengths field So both questions and answers have a type in the DNS protocol Some of the common types include type A, which specifies an IPv address for the query domain Type C name which defines an alias, a canonical name for the query domain This provides a level of indirection and type Mx which defines the domain name of a mail server For the query domain. So if, for example, you send an email for gmail.com your mail client issues a DNS query For gmail.com it gets back a domain name of a mail server for gmail.com And because this is a name and not an IP address this name need to be resolved further into an IP address So the resolver Issues a DNS query of type A in this case in order to resolve the domain name of a mail server In practice most DNS servers simply handing the IP address along with the name But none the less DNS functionality need to be supported by the DNS resolvers so Little bit about the domain names encoding the binary format So domain names are encoded as a sequence of labels. So www is a label, example is a label Each label is preceded by a length byte Specifying the number of characters this label occupies and the domain name is terminated by a zero length byte And according to the RFC, there is a maximum label length is 63. This will come up later So what the designers of the DNS protocol noticed is that there is a lot of repetition in the inside the DNS packet itself So in effort to reduce the size of the DNS messages the employer simple compressions In this scheme compression is achieved by replacing a sequence of labels with a pointer to prior occurrence of the same sequence So here you can see a sample DNS response packet You can see gmail.com is specified as an offset hex C from the start of the packet And it so happens that gmail.com need to be specified the multiple times inside the packet So instead of specifying gmail.com literally in the packet again We simply use the the compression features we point to the previous occurrence of gmail.com So if we want to to write SMTP.gmail.com We need to write only the first label Literally SMTP in this case and the next two labels are specified using the compression offset So in the compression schemes compression pointers are encoded in two bytes The first bytes begin with one one as the most significant bits and the other 14 bits Specify an offset from the start of the header So as from we said the vulnerability is residing the DNS Resolver of track TCP AP and we find them in the DNS parsing logic in the stack Specifically in a function called tfdns callback here You can see a snippet of pseudo code from this function specifically the Parsing logic handling mx resource records. So what we can see here is that The function computes the length of the mx hostname based on that length a buffer on the heap is allocated and then the Mx hostname is copied as ASCII into the just allocated the buffer So what we can see from this snippet is that the tfdns label to ASCII the function that is possible for the copy Is not aware of the length of the buffer being allocated What it does is simply copies bytes from the encoded name until an albite is reached So this means that if for some reason expand label lengths returns a length value, which is too small We will have an heap based buffer overflow vulnerability. So this motivates us to look further into expand label lengths and examine its operation So you can see a pseudo code of expand label lengths What this function basically doing is sums up all the length bytes While honoring compression. So in more detail it reads the current label length Then checks to see if there is compression or not if there is no compression, which is the common case It adds the current label lengths plus one to the total length variable Which is later returned from this function and advanced the input add And if there is compression, it reads the compression offset It computes a new label pointer based on that offset And then it checks to see that the new label pointer points before the initial label pointer So this means we can only jump backwards from where we were And the process continues from this new label pointer So as you can see there is no bound checks on the packet buffer here So this led us to the first vulnerability, a read-out of bounds vulnerability This could result in a denial of service if for example while iterating over the length byte We read from an animal map page But more interestingly We can cause an information leakage vulnerability So tfdns label to ask it the function that does the copies and has no bound checks either This means that data from the heap could be interpreted as an MxOS name This MxOS name is later resolved by the client in an attempt to get an IP address So this means that we can leak data from the heap inside the MxOS name itself in the query This vulnerability affects track version at least 4.7 and it was fixed in later versions as we will see We don't know the exact version of the fix but nonetheless the vulnerability still affects devices in the wild Due to the complex supply chain effect and nature of the better devices so some don't receive updates So this is nice and all but we are looking for an RCE So let's go back to the function that computes the length and examine its operator further So there are more issues with expand label length So per the RFC there is a limitation on the maximum Domain name length the limitation is 255 characters and this limitation is not enforced in expand label lengths Further it does not validate the characters of the domain name They should be all alphanomeric and hyphen, but it doesn't validate it so we can embed bytes within their name itself and last but not least the total length variable is told as an unsigned short 16 bits width and Recall that the total length is the variable that is returned from the expand label length So what what we try to do is we try to get our RCE by overflowing the total length variable So what we need in order to pull this thing off is to construct a name whose length is a larger than 64k So we ask ourselves is it really possible. This is not trivial This is possible over UDP So can we overflow the the total length variable within a single DNS response bucket The answer is yes, and we use the DNS compression feature to achieve this The idea was to nest compression pointers within themselves So recall that expand label lengths does not validate the bytes of the of the domain name itself This means we can embed any bytes we want and in this case We we chose to embed compression pointers you see in the example shortly Keep in mind during the examples that we have two challenges to overcome Further is a limitation on the DNS response packet size the maximum size allowed over UDP by the network stack is 1460 bytes and keep in mind that we can only jump backwards from a current label pointer So we will need to overcome this challenge also So here you can see on the slide the basic construction we used This is a name arranged in a matrix like form each row in this matrix has length 16 the blue cells Represent compression pointers and the pink cells represent branch bytes. We talk about those shortly So let's assume we're starting expanding the name from this offset offset hex in the first row We can actually achieve this in practice by using another compression pointers that we will end us exactly in that spot But for now take it as a given So if we start expanding from this offset, this byte is interpreted as a length byte In this case, there is no compression. So the function skips zero F plus one bytes and move to the next row and As well as it adding 16 to the total length variable the process continues notice that we stay in the same column because the because of the matrix special matrix shape Until we reach a branch bite and the principles of the branch bite is simply to lead us to the next compression pointer In this case, the branch bite is zero E. So we land in this compression pointer We we know that this is a compression pointer because the high nibble is C. So what the function does is a Reads the compression offset the the compression offset in this case is zero E It then checks to see that we point backward from our initial position. So our initial position was hex F So hex E is less than XF. So we continue expanding the name from here and the person constantly news We reach a branch bite. We reach another a compression pointer and you can see that With this compression trick the total length variable nearly double itself So if we continue until we reach a null bite in this For example, we reach a total length value of 1500 Byte which is pretty neat if you consider that the name itself only occupies 128 bit bites So, of course, this doesn't Overflow the total length variable Yet, but in order to overflow it we use the maximum label lengths allowed 63 X 3 F instead of X F Shown in the example. So using exactly this construction. We reach a name Of length 64 K Greater than 64 K. That's overflowing the the total length variable itself And remember that if expand label lengths return a value, which is too small We have pen he pays buffer overflow, which is a good RCA candidate and Also know that this vulnerability can be triggered in response to every query type supported by the network stack by using C name Resource records, which must be passed regardless of the original query type So this vulnerability affects the latest track version at the time of disclosure and thus considered Dangerous from our point of view. So at this point We decide to purchase another the device that runs track in this case another UPS device And we want to to know if the vulnerabilities affects him or not And what we found is that track fixes the retail to bound vulnerability, but they fix it badly So you can see that the Audi lengths Value from the resource record itself is checks against the remaining size of the packet And now after the fix expand label lengths accepts a third argument label end pointer, which is computes Which is computed based on the Audi lengths value and what expand label lengths does when it reaches this end pointer It simply stops processing without any error and returns the current total length So this is perfect for man attackers spend standpoint because Audi lengths is attacker controlled So if for example, we specify an Audi lengths value, which is too small than the actual value We will have an 8 base buffer overflow So here you can see a resource record and instead of specifying an Audi lengths value of 20 we will specify 7 So the label end pointer will points here expand label lengths returns 5 in this case But tfdns label to ask you will copy the entire mx hostname thus overflowing our buffer So this is the second the hip base buffer overflow vulnerability we found and We also found during the mx parsing logic a memory leak. We found that we can leak an other infrastructure So you can see an other infrastructure is allocated and in these two error flows the other info is not free So this means we can leak another infrastructure by specifying Audi lengths value Which is strictly less than two like one or by closing expand label lengths to return as zero lengths For example by using a bed compression pointer so the size of the leak is hex 3c and this artifacts come in handy when exploiting give vulnerabilities and in fact we use the exact same memory leak in our exploit as You will see later So to summarize we saw three vulnerabilities that comprise cv 2011-01 and An artifact so the first vulnerability the read out of bounds affects other versions of the Network suck and was fixed in later versions the integer overflow vulnerabilities as far as we've seen affects both old and versions of the Tracty cpip stack and the bad ardy lengths vulnerability is a Result of a bad fix for the read out of bank vulnerability and thus affects only your version of the stuff The artifact is present in both old and new versions of the stuff And the main takeaway from this part is that a device can be affected by one or more vulnerabilities depending on the exact version of Track day using and this fragmentation makes the life of the IT security person and more Challenging to know whether the devices are affected or not so Now when I end over the mic to a real show he would talk about exploitation Thanks, Moshe. Hi. I'm a real. I'm also a security researcher at JSOF and today. I'm going to talk about exploiting the vulnerability the CVE on a Schneider electric UPS device so UPS device Is basically a big battery UPS stands for uninterruptible power supply And you connect devices to it instead of directly to the wall to the outlet To protect them from power artages or power fluctuations of any sort So we're going to exploit on a UPS made by Schneider electric specifically on the network card This network card houses a turbo turbo 186 processor. It's an x86 space processor all code runs in 16-bit real mode and Meaning also there are no modern mitigations at all. So no depth. No SLR This processor is x86 space. It's not strictly xx86 As seen in this process has a weird segmentation scheme instead of shifting the segment register by four bits Like on x86 it does by 8 bits and we'll see this feature come into play later During this research we add essentially no debugging capabilities So no JTAG no GDP nothing of the sort So we relied mainly on static analysis and reverse engineering using only limited crash dumps as Assistance these crash dumps as visible feature a basic stack trace and summer gisters with nothing much So just to recap the vulnerability our primitive is a heap overflow through DNS response parsing And this is a rather new track implementation So we can only overflow with alphanumeric characters and hyphens and periods And we're going to use the bad Ardilect vulnerability variant That was I talked about earlier So when exploiting heap overflows generally there are two methods either through metadata corruption. So Overflowing a free lease pointers block sizes Stuff of the sort or by overflowing application specific data structures allocated on the heap Generally metadata is considered a more generic exploitation method as it doesn't rely on extensive shaping and this is the exploit exploitation method we used In the earlier CVE on the Digi connect device That we we have a right white paper about this and you can find on our website And we wondered if you we can use the same technique on this device as well So the trick heap as implemented on the Schneider electric QPS It's slightly different. We have a free list that looks like this It has a size field next pointer to the next free list block some free data Usually containing garbage if it's a free freed block and another post size field So this heap features a tight fit preference It will always allocate the smallest free block available for the allocation size requested It also features free block coalescing. So there are never two adjacent free list blocks and It has all sorts of verifications and asserts that we didn't have in the previous heap implementation on the Digi device So for example on every heap operation the entire free list is checked one of the checks is that the First size field and the last size field really do match Allocated blocks, however, are only checked when freed. So this is a bit easier and Corrupting The heap in a way that will not cause a premature crash due to these checks on heap operations Using only alphanumeric characters is rather hard. So we chose to go in a different way by overflowing data structures this time So we know we can overflow through all DNS response types However, we chose to overflow through Mx requests as specifically because when the device boots up it will send out three Mx requests So that is a good exploitation primitive and Also three requests is very good for us for the heap exploit since interactivity is always advantageous it allows us a bit more flexibility in shaping our heap exactly the way we want and We don't really mind that this happens only on device boot as we probably would have to crash the device anyway I said we had limited debug debugging capabilities during this research So not much insight into the heap and how it is shaped So we would like to get the heap into a state that is as deterministic as possible So crashing is good in this manner and crashing the UPS network card has a very low penalty as it doesn't affect the actual UPS operation in any way It doesn't affect the power supply and the network card will automatically boot right up after a few seconds So the penalty is very low So overflowing data structures We chose to overflow a structure called TSDNs cache entry this structure holds information about the DNS request response pair It has all sorts of interesting fields. For example, the DNSE adder info PTR field that holds a list of other info structs These trucks hold Information about a certain DNS response So for example, if you resolve the name this structure has a field that will hold a pointer to the name that was resolved Other than that, it has other pointers and interesting fields such as the It's a doubly linked list as you can see so it has an X in previous entry pointers And these are always interesting from an exploiter point of view And this structure is referenced often in DNS response parsing, which is the logic we can easily trigger So this was a natural candidate for us. So assuming we can overflow this structure. What can we do with it? This is a pseudocode snippet from the parsing logic and It specifically shows how C name records are parsed So we can see that first thing a pointer is taken from the DNS cache entry Into a stack variable then the C name is Allocated on the heap and the data is copied. This is of course data we control as we provide the DNS response and subsequently The pointer to the new C name allocated on the heap is placed into the What the stack variable points to again this pointer was taken from the DNSC? Cache entry so if we overflow the cache entry we can control to where this heap pointer to our C name is written to memory This is a controlled pointer, right essentially We can write a four byte pointer to data we control on the heap in x86 6 in bit This is a two bytes offset and two bytes segment We can write this to any alphanumeric address as our overflow is alphanumeric This is a relatively strong exploitation primitive writing data into places You're not supposed to write into is always good when you try to exploit So this is the primitive we chose to continue with Our overflow is a simple heap overflow meaning it is from the end of our buffer with no offset into the next What what lies in the heap next so we would like? Naturally the cache entry to be placed after the MX name buffer Because of the heap structure in this specific trick implementation, and we have all sorts of limitations for example The cache entry is allocated on request creation However, the MX name buffer is allocated on DNS response parsing So chronologically it is allocated later and we want it on the heap to be allocated before so we can overflow into the cache entry also where you because free blocks are checked very often in this heap implementation for corruption We cannot write free data. We must overwrite only allocated data It will be best if we can overflow directly into the structure without corrupting any heap data in the way So we need to shape the heap in some way to get this to happen and a specific whole pattern is Preferable as we would like to overcome the chronological problem. We can do this because of type fit preference So if we create for example whole to as seen in this diagram and that is the size of the DNS cache entry structure And before it we have another hole the size of the MX name buffer. We're going to allocate We can overflow from the MX name buffer into the cache entry We do need to separate them with some allocated separator To prevent the two free blocks from being coalesced together and ruining our shape So we need some allocation primitives to create this we need an allocation to create holes and an allocation to create the separator So to create the holes we can use a temporary temporary allocation primitive And this is relatively easy to achieve as every DNS answer Has all sorts of names in it or we can cause it to have names in it So either MX or PDR or C names They all have name fields and these names cause allocation on the heap So the allocation is the size of the name we provide and its data is of course self and American controlled This allocation will also cause a small other infrastructure to be allocated as well. We need to take this into account when shaping This allocation is freed when DNS parsing fails or when the record TTL expires So this allocation is perfect for creating free regions of arbitrary size, which is what we need However, we need to separate our free regions and we can do this using the ad-reinfo memory leak The memory leak artifact Moshe talked about earlier and just to recap shortly And we can see that an ad-reinfo structure is allocated and only then The record validity is checked and if it's not valid We will exit through an error flow and that will not free the allocation So we basically have a memory leak of a known size and we can use this as a separator between our two free buffers So we managed to shape the heap Into the specific shape we want and this allows us to reliably overflow the DNS cache entry every time So assuming we can do this and we just show what we can what can we do with the CNAME pointer override primitive? What can we overwrite? So this pointer right has all sorts of limitations. It's written to an address we overflowed into the cache entry So naturally only alphanumeric addresses are allowed. However, this is a string overflow vulnerability after all we're overflowing with the name so we do have a trailing null byte and x86 little endian architecture this trailing null byte can be the most significant byte of the segment Allowing us a bit more flexibility in the addresses we can reach However nothing in this specific firmware is placed in strictly alphanumeric memory address So no code no heap no stack no globals Nothing interesting. We can overwrite Luckily due to the a weird segmentation of this turbo 186 processor we can use a little trick and easily combine two alphanumeric bytes to reach a non-alphanumeric byte or a non-alphanumeric segment And this will look something like this for example We choose a segment to be null byte 4b which is allowed It will then be shifted by 8 bytes and an alphanumeric offset will be added to it resulting in Linear address containing a non-alphanumeric byte Which corresponds directly to a non-alphanumeric segment. So using this technique due to the weird segmentation feature We can reach the heap utility code section which has all sorts of functions such as free and malloc Which we can overflow again. This is a 16 bit real mode So we don't have depth or ASLR allowing us to overwrite code with our primitive So when overwriting a code in x86 one of the interesting destinations to overwrite with the pointer is a far call opcode as a far call has an absolute address Encoded directly in it So if we can overwrite this destination address with our pointer we can Cause the execution flow to move into our c-name buffer So we can patch the far call using our primitive and execute our controlled payload So we do this exactly with fact we patch a far call in the free airflow Which is called when metadata corruption is detected naturally we do corrupt the heap when overflowing So this airflow will take place when our allocated blocks are freed So let's shortly recap what we did here first We shape the heap in order to get the mix name buffer to be directly before the DNS cache entry with a separator in between That's not shown here We then overflow to write the DNSE adder info PTR to point into a far call in the free function We then process a c-name record the parsing logic will process a c-name record containing some evil alphanumeric payload Which will be allocated on the heap and the pointer to this payload will be placed into the address we put in The DNSE adder info PTR Overwriting of our code destination directing it to our evil payload which can be for example some alphanumeric shellcode Triggering this payload is Rather easy the free airflow will be triggered when the mx name record we overflowed from is free and The c-name buffer specifically what we overflowed with contains two-stage alphanumeric shellcode Which will decode itself And allow us to run essentially arbitrary payloads Achieving arbitrary payload execution Specifically our payload just turns off power to all UPS outlets Turning off any critical device that was supposed to stay on and we will now see a short demo of this payload execution Thanks for listening and tuning into our presentation. We'll be glad if you join us in the Q&A