Space Missions and Cybersecurity: Attack Surfaces, SLE Protocol Vulnerabilities, and Exploitation

Are we on? Yeah. Hi everyone. Let me just calibrate uh a little bit. How many of you are working for space industry? Okay, that's known. Then it's going to be quite interesting for you. I hope um as I guess as you know um recently space missions have been increasingly um have been increasingly um attacked by the adversaries. Um most of the discussion however revolves around space segment. Um and it is our argument that it is the ground segment that is more likely to be targeted by the adversaries instead. And that is because of the um that that's because of the uh attack surface it imposes. So uh in this presentation I will briefly compare the space segment

with the ground segment uh from the um from the attack surface point of view. I will then uh give you some short introduction to the SLE protocol and its security um it security aspects and vulnerabilities and then I will show you a couple of demos how um how we can how we can abuse those uh security issues and then also I will uh finish with some mitigation uh techniques. So um every space mission can be loosely divided into uh two segments. It it is a space segment and then it is the the ground segment which also includes the user segment the the end users. Usually space segment is very complex. It consists of um let's say a

space asset which has many interconnected elements on board of the uh of the spacecraft. However, if you think about it, it is just like one uh it's it's it's it is just like one entry. um it has just one entry point because it is just like a one element in the system. So uh because of that it presents a very small attack surface. There's only one in and one out. And on top of that, the communication with the spacecraft can be quite challenging. And it's not because of the technical aspects of it, but rather because of the envir environmental aspects like uh the distance from uh between the ground station and the spacecraft, the the

visibility, the orbit and so on. On the other hand, the ground segment is um is of much less complexity, but there are many uh interconnected components with um which communicate to each other either by sending the input to or receiving the uh output from uh other components. And um on top of that there are um many potential many potential uh entry points which because of which uh it presents much larger much larger attack surface. Additionally there is no sophisticated um equipment required to uh hack into the ground station because this is just a standard infrastructure. And uh the last point is that there's a lot of software that is on the ground segment. Uh many applications however

are customuilts which presents um many additional avenues for um for new vulnerabilities because it's not a standard software which many people have used before and tested it. So um on this image you can uh see a very at a very high level breakdown of a space mission. From right to left you have a space segment which is which consists of a space asset uh or multiple assets um in this case it would be a spacecraft and on the left hand side you can see um the whole ground station uh sorry ground segment. So as you can see there are much uh there are many more components uh into the ground segment. Um there is a ground station

which communicates to the spacecraft. There is a mission control which talks to the ground station and it is used by uh some users connecting to the mission control system either from internal network or uh through the internet via VPN or jump host or whatever uh that organization might have. So the the point I'm trying to make is that uh it's going to be much easier to hack into this thing uh and try to hug into the spacecraft through it um rather than build it yourself. So now about the SLE um SLE is a standard is a protocol that is uh developed by CCSDS standardization body and SLE is um basically lets the users to send the telecoms to the

spacecraft and receive telemetry from the spacecraft. It is based on the TCP IP. uh it supports transport encoding and authentication and it can have two roles. SL provider and SL user. Now SL provider is a ground station from a from a high level role perspective and SL user is uh something that is communicating with the ground station which usually is a mission control system. So in a nutshell uh SL defines uh SL defines a protocol for transferring um uh PDUs using the TCP IP for data transfer and ASN1 notation for uh data encoding. So in the system you can see that it is uh just for context it is the link between the mission control system

and the ground station. Now here you can see all the organizations um and companies that are responsible for SLE uh and CCSDS standardization body in general. You can see most of the major players there. If you look at the documentation, uh you'll also see that there is um there's quite a few member agencies responsible for the standard. And later down if you see um if you look at the actual the PDF, there is uh three times as many um other private and public uh corporations involved in the standard either development or uh or they use it. SL is also present in most of the um specialized equipment that is running on the ground station like in this case the

cortex saffron cortex ground station equipment. And here just also for a reference um NASA nearer space network list as one of their interfaces uh and capabilities which uh basically means that almost everyone is using SLE internally on on on the communication between between the MCS and the ground [Music] station. Now for our for the purpose of our research we focus on something that is called FCLU. It is forward communication link transmission unit and is basically the thing that lets you to send space telecoms to the spacecraft between the MCS and the ground station. Um it defines a bunch of um a decent list of uh operations at the protocol state at the pro protocol level. However, for us, we are focusing

only on the following ones, which is the bind, unbind, start, uh stop and transfer data. And later you will see why. Um so if you look at the documentation, there is basically no privacy. Also, the the data integrity is lacking. There is a sequence numbered uh sequence numbering to attempt to prevent uh operation injection at the protocol level and potentially is in the control of the spacecraft but there is a very easy way to bypass it and also is very there is a authentication mechanism but because there is no encryption is very prone to replay attack and um capturing the credentials and then re reusing them. So our testing environment is uh is extremely simple. Uh this is assumed

bridge attack scenario. So we are assuming that the adversaries are in the network and uh it consists of three elements. Uh SLE provider which plays the role of a ground station and runs on a typical DBN machine. For that we use uh for the SLE side we use the ISA implementation European Space Agency implementation of uh SLE. On the user side, we are using um the the role of the um of the SL user is is is played uh by the mission control system and for that we use the uh Python SL implementation which just happens to be uh implement implementation done by the by vision space which is my our company and this is just to demonstrate

that it doesn't matter which implementation you use as long as this implementation is following the standard your mission is going to be vulnerable. able and then of course we have a Kali uh VM in the middle trying to mess things up. So um from the technique overview point um because there is no encryption we thought that the best idea to demonstrate the attack uh to come up with possible attack scenarios is going to be to use many the middle attack. So uh at the high level we do the AR spoofing. We capture the uh the the data at the uh TCP frame level. We decode the ISP1 frames which I will explain later uh what they are but they

basically carry the CLT data which is the thing that goes to the spacecraft at the end and then we update those frames and push it forward to the ground station. Um I I guess most of you know how the R spoofing works. So we basically poison our tables between the two nodes which is machine control system and the ground station. We put the packets in the NFQ filter uh for the processing and um and the processing is actually where the fun starts. So once we capture the frame um they contain the um SLP PDUs which are in the ISP1 format. Uh we extract them. Um ISP1 is using AS1 encoding. Um so we decode the

standard type length and uh and value fields. There are a few custom fields um and context specific structures and sequences. So, um it's going to take a little bit more time to figure out what they are, but because of SLE comes with a relatively nice uh and complete documentation, uh it's going to be it's not going to be that difficult. And as I mentioned before, uh we focus on the CLT only. So once we uh once we capture the data we have to map it once we extract those values we have to map it to the FCLU data spec uh data type specification and so here is an example uh this is uh one of the frames uh that

contains the CL bind um data. What you see is uh is is a roadbed uh stream. It consists of the ISP1 header and then main structure and then everything else is a seal tube bind specific fields. One of them being the a bind invoke encryptations. It is not encrypted. So um anyone on the on the wire can actually decode it. Okay. So um finally now it's going to be demo time. Before I show you some uh demonstrations how to exploit this protocol, I'm going to give you a demo of how the standard communication between the ground station and the mission control system looks like um just so that you understand the baseline. So first we're going to

establish the connection using this fieldine. Uh then we're going to initialize uh some some of the services at the ground station. Um then we're going to transfer some data. We're going to stop the service at the ground station and then we're going to unbind uh from the ground station. So let me see if that plays. So here on the is is a recording. So on the on the bottom side there is um SLE provider which is a ground station and on the top side there is a SL user which is which which is a mission control system. So I

have so I have prepared a small routine where we start the SLE provider and then we start the SLE user. Let me pause it for a second. Where we just uh connect uh do the bind then we start the invocation where we set up the ground station then we send some data we unbind and then we disconnect. So that's basically what how the communication looks like at the high level between the mission control system and the ground station.

So there are a few things we can do about it and we have prepared a few I have prepared a couple of demos where I can show you how we can actually abuse this mechanism. Since there is no encryption we can capture the credentials and we can um we can generate a little bit of denial of service. This is going to be uh in particular annoying for the users because if we start changing the credentials on the wire, the users won't be able to uh authenticate to the ground station. And the reason why it's extremely annoying for the users is that because at the protocol level, there is no feedback from the ground station going back to

the mission control system. So the connection is going to be just dropped which means that the users will try to connect but they will fail and they will never know why. Um they will have to run investigation on the ground station to then understand why uh why they are failing the connection. So what we do here we just capture the frame we mangle with the authentication byes uh we put whatever we want and then we forward those frames to the ground station. preventing the authentication. So the setup is pretty much the same except that on the left hand side we have our uh we have our um exploit that is running on the Cali

machine. So first we're going to start the exploit and then we're going to uh proceed with our routine uh as before. So once the exploit is up, we start the um ground station. Then we start our mission control system. We try to bind and then we see that we didn't get any feedback. However, the request the next request in is is failing because of the weird state that the mission control system is in and the only information is on the ground station that the user has failed the communic the authentication otherwise the connection is dropped and there is no feedback. So the users have no idea what is happening. So since we have access to the

credentials uh we can of course also capture them and display or or save for later use. So that's what this um demo is going to be about.

So we start our exploit and again we proceed with the same routine except this time um the whole operation is um invisible for the users. They proceed with the authentication as per nominal. They send some data and then this disconnect. Um but you can see that on the left hand side we actually were able to capture the uh the credentials and in one of the later demo you will see how we can actually abuse that and reuse the credentials to take over the SLE session. So it is very tempting to start tempering with the data. Um if you know how what spacecraft is expecting from you, you can capture the frames and then instead of uh playing with the oper

operations at the protocol level, you can start playing with the spacecraft itself. So for that you just have to grab the frames which contain uh the data transfer PDUs and replace the content with your own. So in a similar setup to the previous one except that on the top uh side there is our exploit. We are going to be sitting on the wire looking for or filtering for those uh for the for that by string which is bytes from 0 to 9. And then we're going to replace them by a by string of our choice. Like in every example we just use um bite 41 which is ask representation of letter A and then on the left hand side at the

bottom you have our SLE provider which is ground station and then on the right side there is machine control system. So the exploit also tells you a little bit uh what you are doing. So once it's up um we can proceed with the exploitation. So we start the ground station and then we start um the mission control system routine. So we connect we send some data. You can see that we have sent byes from 0 to 9. On the left hand side you can see that we have captured those byes. This is the last byes of the frame and then um also at the bottom you see that the spacecraft actually has

received. Okay I was trying to play it again. You can actually see that instead of byes from 0 to 9, uh we have received the bytes um 10 bytes of 41. I cannot really pause the video. I don't know why it's why it's not pausing, but I just want you to show I just I I just want you uh to see it again.

Okay. So this is the moment when we send it and you can see on the left side you have 41 41 41 and so on. So this is what was received at the ground station and effectively it's going to be forwarded to the spacecraft by the ground station. So if we put all those elements together, we can actually try to take over the whole SL session. So what what it means is that we first are going to prevent the users from authenticating so that they cannot connect and establish the session. We are grabbing the credentials and reusing them for our um own session that we are going to establish to the SL provider. And once

we don't once we have done that we can actually start communicating with the specific directly as if we were legitimate mission control system. So on the left hand side you see there is um exploitation part and on the right hand side there is um again the same setup with the mission control system and the ground station.

So we start our

exploit. We start the ground station. Then we start the mission control system. We capture the credentials. The user is unable to proceed with the uh communication because there is an exception at the ground station. And we'll just reuse the same credentials and establish our own session to the ground station from our Kali machine. And we can proceed with our routine of uh setting the bind setting the ground station equipment sending the data to the ground station and effectively to spacecraft and then we can proceed with unbind and and uh stop and unbind as if we were the legitimate machine control system.

So that's it for the demos. Um what you just saw is just one of the examples how you can abuse the protocol uh in order to take control of a spacecraft. As I said in our research we focus only telecommanding d telecommanding part because we wanted to demonstrate that you can actually take over the control. But there's also telemetry coming down from spacecraft to the ground station which can also be uh of use for adversaries. So it really depends how much of impact you want to have uh for a mission. Um this is done in a very stealth way. So we can be in the network. If you can be in the network for long enough, you can use that to

figure out how the spacecraft communication works, how to communicate with it, how to command different elements at the spacecraft and then you can use SL to uh to send your own to the commands. Um this knowledge might require some of the spacecraft operations knowledge. However, um everything that you have seen on those slides is uh can be gathered using oint. So all that information you saw is a public knowledge. You just have to be stubborn enough to look around and um you know have enough time to use it, right? But but it's out there. It really is. So um CCSDS uh came up recently with SDLS which is uh space data link security protocol. However, it is done

only on the uh or it is implemented only on the link between the space between the ground station uh and the spacecraft. It's not used yet. So as of now most of the communication is still unencrypted for most of the missions especially the ones which are running right now. Um however they come up uh with this. So um that said the the link between the mission control system and the ground station is still insecure because there is this assumption that is internally in the network and no one has access to it which obviously as we know it's uh it's a false assumption and our idea was that um instead of trying to work around and

hide behind the firewall we should implement um CCSDs PKI concepts which already they have uh they have developed that at the standard level in order to enable the TSL like features uh at the at the ISP1 um encoding layer that would prevent that would basically encrypt the whole communication on the ground state on the between the MCS and the ground station. So the future work is that currently we are trying to agree with European Space Agency to get access to one of their uh actual ground stations which we know that they are running cortex devices in order to see whether we can actually reproduce it at the at the real hardware. So we are we

are already discussing this with them. Um this research has recently been picked up by NASA and they have contacted one of the US companies. um and they are pushing for changes to the standard to the CCSDS standard for which we have been invited to uh participate and uh and help them sort out this um this security issue and then um we are also going to uh add some new functionalities to the to the exploit we have de developed and at some point most likely we're going to open source it once uh those issues have been resolved probably at the CCSDS As I said, um all what you have seen is a public public knowledge. Uh here is a full list

of uh references you can have a look at which is also in the publication um which you can find here on this link so you can capture it and have a look later. Here is also some further research we have done on the space related systems both on the ground and on the spacecraft onboard software. Um you probably won't if if you are interested I can give you the links later or maybe once you have access to the presentations and that was the last slide. Thank you very much. Are there any questions? So the question is what's the reason why SL is not encrypted which leads to all those attacks? Um the the main reason is

probably legacy. the standard came out quite uh quite quite some time ago where people were not really thinking about the encryption and there is also at least in space industry I have the feeling that there is that notion that if it's internally in the network uh it's not going to be accessible by people from outside so as you know that's not the true usually what happens is you get access to the system to to a system through the public facing website and then you get access to the internal network. Once you have access to internal network, you can start uh doing what we have done. But that's not uh that that's really not how people

in space industry see it. They hide behind the firewall. They set up VPN and they think that's okay. I should probably not generalize, but we all have seen what happened to Viasat when the when the when the war started uh in Ukraine, right? So it was because of the um because of the legacy systems because of lack of encryption. The onboard software was um was um uploaded to spacecraft through the uh plain FTP protocol. And the only the only um the only security measure they had was a VPN which adversaries breach in no time. basically figure out figuring out what the credentials are. So obviously that's that was a mistake but that's still it is still happening. So the ground

station so the other aspect is the ground station to the satellite communication. So now you're free space. So you're open to anybody any no man in the middle middle or even the device and uh backend traps people can get in. That's one. Secondly, we are talking about you know postquantum cryptography in these days and time. So and you are just operating on barebone no encryption. So is this like the standard that uh space agencies use worldwide? I cannot speak about the military solutions but if you think about it you have a spacecraft which was launched 10 years ago or 15 or maybe 20 years ago there is no security measures in those systems. So even if you have even if you

try to encrypt communication uh at the ground segment the spacecraft will not understand because you would have to well it depends really on the spacecraft because there might be some possibility to patch the onboard software but I I've seen many um many missions which was basically impossible to patch onboard software already let let alone add additional um requirements for uh encryption. and for processing of that encryption because there is not enough power at the spacecraft. So this is one of the reasons this happens is because these are really legacy systems. Um what about the newer satellites that are being launched? So as a as a one of the slides as I showed before um CCSDS came up with the

space data linking security protocol which is on the link between the space the ground station and the spacecraft. So that is going to be secured. However, the link between the mission control system and the ground segment is not secured. Which means that if you start injecting telecoms uh on the link between the mission control system and the ground segment, your commands are going to be encrypted and will go to spacecraft anyway for the execution. So you are conducting an attack before the commands are encrypted. And these uh new u standards being uh suggested are they going to be postquantum secure also? No no no they are not. Thank you. So I have a question. This was one we

were kind of discussing last night. We know that uh a lot of the space systems use very legacy code. Uh NASA's still using stuff from the Apollo program. Um obviously we weren't worried about security then and a lot of these systems are 10 20 30 40 years old. Um in addition we also have a similar concept within the medical device industry to where say that we can't update MRIs. They're still running Windows 98 because that's the software that they're based on. How do we go about securing legacy systems in a modern world, whether it's with the space agencies, medical systems, other critical infrastructure with dams that we really can't update? Um, they don't have enough power on that

end. We never designed it in the first place to deal with that. How what's your thoughts on protecting our modern our systems that are legacy that we can't update against modern threats? Yeah, that's a that's a good question. So I have some thoughts about it because obviously you cannot make sure that all your systems are secured but what I have seen in the industry what is happening as I said before people are hiding behind the firewall and be behind the VPN and they call it end to end security and sometimes they even call it um zero trust. So the issue is that you should obviously you you will not be able to make every single element of a space

mission secure but you should break it down into pieces and try to make secure those elements which you can one of those elements is you should try to make it secure you should try to make secure the mission control systems because these are the most critical systems and is it's they are they are systems which are not really legacy because they are developed on a day-to-day basis and every mission has a new system. However, they are so critical because they are the only systems that are used by the people and as we know people are the the weakest link in the any information system. So you have to make sure that these are secured right.

So you have to take the mission, break it into pieces and grab the elements which you can make secure and then you have to secure those. There will be things running on Windows 85. There will be things running on something which is not even Windows or before Windows. Of course you cannot make secure but you can make secure all the communication and bits and pieces around. And the the reason why this is better than hiding beh be behind the firewall or uh VPN is because once the adversaries like in case of Viasad they breach the VPN um securities then they will be able to uh tear your mission apart basically and um and that's because all those elements

are not secured. So I think that's that's the that's the the best approach.

Uh sir from students point of view like sir said that in critical infrastructures we have many protocols which are insecure by design. If you talk about ICS we have Modbus. If we talk about drone so we have Mavink which are proven to be uh where such attacks have happened. So we are learning using different simulators like IC simulator we have if you want to learn about modbus security and for drone we have other softwares. So anything about if you want to start into satellite hacking and uh about this um sorry I didn't get the question. So, so anything we uh if from a student's point of view if I want to learn or simulate these things at my end for

learning point of view so what I can I do like sorry I still didn't get the question I don't understand yes so basically he's trying to ask like is there any simulator to start to start practicing these uh exploits any labor environment for this for from for students or newcomers

Oh, how how are we going to do this in practice? Yes. For practice. Yes. Well, this was the practice. What you have seen was actually what what you what you this is not this is not academic. This is exactly the software which we uh use it for testing. It is the software that is used at the ground station at the mission control. So that's exactly what you saw. That's exactly how you would do. So the thing is that as I said before this is assumed bridge uh testing scenario. So the adversaries the assumption is that you are an adversary and you are in the network already. Let's say you bypass the firewall. You maybe hacked one of

the front-facing website. You are in the network and so then what you do you have access to the software which you have seen. the software might be a little bit different depending on the organization. Um but as I said this is implementation independent because the software has to follow the standard the communication standard and so every implementation is going to behave in the same way and therefore if you are doing the man in the middle attack you can it's software agnostic you can just do exactly the same at any uh machine control system to ground station link that uses SL okay thank you hey morning so I do know one question that you have uh shown the

example of different headers by in decoding a request so there were a bunch of headers so I would like to ask you that how do an application or or the protocol I yeah that's right so how do we identify that which headers is ending when or which is starting the next header so [Music] um excuse Some of it is in the documentation. Mhm. And then um ISP1 is based on ASN1 notation encoding. So we just follow uh the same u well definfined structure of tag field and value right tag length value TLV. Okay. So do they have a certain length character length or something? Sorry I didn't get that. Do they have certain character length or a certain

header like the first header is uh ISP1 header. So is that any certain particular character length for that? Yeah. Yeah. Yeah. Okay. So as I said it's like it's it's a typical TLV. So you have a tag which defines the the element the beginning of the element. Then you have the length of that element and then you have the the actual value. So there are some elements which are not typical TLV but they are described in the standard which are as a custom sequences and custom um context related structures but they are described with a fixed uh tag which you can easily identify and then you just you you just apply the length and then you grab the value from

those uh from that by string. Okay, thank you.

Yeah. Hi. Uh I was it's kind of a dumb question but I think I wanted to ask if recently Apple launched satellite communication with the phones right. So is it any kind of similar protocol or communication that it is using or is it is it possible to uh intercept those kind of messages and then manipulate them? You mean at the at the ground to spacecraft or at the ground segment? Uh no the iPhones the iPhone 14 series and later they can in the emergency situation where there is no network communication they can contact with satellites and then send emergency calls and messages. So is that in any kind of way similar to what you have shown here?

I think I don't understand the question. Um um like can you maybe rephrase it because like uh iPhones in the recent days can connect to satellites and send messages as Apple claims. I have not tested it and I don't have much knowledge about it but uh it is using some kind of technology to connect to satellites and send emergency uh calls and messages to services of police and uh am ambulance etc. So I'm curious about the protocol that it is using and if it is able if anyone is able to manipulate it. Yeah. Um honestly I'm not sure how this is done. Um I I I'm I'm not aware how the infrastructure of that communication is

is developed or is uh put in place. So there is even though that you are communicating with your phone to a system it is it is quite likely that is going to be encrypted at your at the communication between between your phone and the system but then internally in the network is not going to be encrypted and that's probably it might be is very likely because of the legacy uh legacy issues because all that communication the systems the the protocol is not secure and if they are using this protocol the encryption internally in the network will definitely not be um sorry the the the communication in the network will definitely not be encrypted. So the communication between

your phone and the ground and the ground system might be secure but then it's going to be unencrypted and then it's going to be sent in in a plane format to the ground station and then it's going to be uplink to the spacecraft. the opting to the spacecraft might be secure. It depends on the implementation. But if it's uh if it's done using SL on the ground station uh site is not going to be encrypted. Thank

you. No more questions. Okay. Okay. Um, thank you very much again. I hope you enjoyed it.