The 'SUASecLab' Virtual Laboratory
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 62 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/59750 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FrOSCon 202211 / 62
4
9
12
13
17
18
20
25
28
33
34
39
40
42
44
45
48
54
55
58
60
62
00:00
FreewareOpen sourceHypermediaScalable Coherent InterfaceBuildingWeb serviceInternet der DingeAdventure gameMultiplication signBitComputer fontSoftware developerPoint (geometry)Source codeWeb serviceComputer scienceOrder (biology)Computing platformMereologyCodeSystem administratorHeat transferUniverse (mathematics)Student's t-testMicrocontrollerInformation securitySheaf (mathematics)Mobile WebComputer animation
03:38
FreewareOpen sourceEncryptionBlock (periodic table)Asynchronous Transfer ModeEmailMessage passingInformation privacyPhysical lawFlagInternetworkingVirtual realityTelecommunicationIdentifiabilityKey (cryptography)TelecommunicationPhysical systemGroup actionInformationServer (computing)Lattice (order)Information privacyTouchscreenMultiplication signLimit (category theory)Computer configurationSlide ruleDatabaseVideoconferencingPresentation of a groupEmailStudent's t-testComputing platformMappingRight angleMessage passingRemote procedure callMicrocontrollerINTEGRALIntegrated development environmentPoint (geometry)SoftwareWeb serviceMereologyReal numberProjective planeVideo gameAvatar (2009 film)Level (video gaming)Game theoryUniverse (mathematics)Similarity (geometry)Uniform resource locatorString (computer science)Domain nameOpen sourceLink (knot theory)BitMehrplatzsystemDescriptive statisticsVirtual machineOperating systemData storage deviceLecture/Conference
11:10
TelecommunicationGroup actionGroup actionMultiplicationAreaLevel (video gaming)Event horizonMereologyTable (information)BitLattice (order)MicrocontrollerTouch typingAdventure gameMehrplatzsystemSheaf (mathematics)SpacetimeOrder (biology)WebsiteComputer animation
13:42
Student's t-testVirtual realityVirtual machineUniformer RaumMessage passingLattice (order)Revision controlServer (computing)Client (computing)Physical systemWeb serviceComputer programmingAdventure gameTask (computing)Computer fileAreaImplementationTranslation (relic)Group actionSocket-SchnittstelleNeuroinformatikLink (knot theory)VirtualizationSoftware bugAdditionConfiguration spaceWeb applicationNetwork socketTime zoneFormal languageEmulatorTable (information)TheoryRadiusScaling (geometry)MicrocontrollerTelecommunicationRemote procedure callMachine codeDecision theoryWeb browserMultiplication signMehrplatzsystemProjective planeComputer hardwareWebcamCommunications protocolSoftwareFlow separationDefault (computer science)Web 2.0BitComputer simulationInstance (computer science)Software developerLecture/Conference
22:34
Virtual realityComputer wormWorld Wide Web ConsortiumGroup actionSlide ruleJava appletFaculty (division)Virtual machineProgramming languageVideoconferencingStudent's t-testWeb 2.0Computer programmingMaterialization (paranormal)Physical systemComputer animationLecture/Conference
23:38
Line (geometry)Maxima and minimaVirtual realityVideoconferencingMicrocontrollerTouchscreenComputer programmingVideo game consoleRight angleOrder (biology)Computer animation
24:50
Hill differential equationVirtual realityBoom (sailing)Gastropod shellReal-time operating systemGame controllerComputer hardwareVirtual machineLecture/ConferenceComputer animation
25:42
WebcamWeb serviceFront and back endsLattice (order)Virtual realityData structureMereologyServer (computing)MultiplicationFreewareOpen sourceSimulationArchitectureRevision controlBitCodeLine (geometry)Web browserOrder (biology)SoftwareStreaming mediaClient (computing)Computer architectureMicrocontrollerWeb serviceProjective planeAdventure gameWebcamGame controllerNetwork socketEmulatorFigurate numberStudent's t-testTouch typingMereologyServer (computing)Service (economics)System administratorGroup actionComputer fileCASE <Informatik>MehrplatzsystemInformation privacyImplementationPresentation of a groupRemote procedure callINTEGRALComputer configurationFront and back endsDebuggerDigital photographyBootingVirtual machineComputer programmingData centerOpen sourceTable (information)NeuroinformatikLecture/Conference
33:13
ArchitectureOpen sourceFreewareData structureCodeWeb serviceRadio-frequency identificationDependent and independent variablesString (computer science)Cartesian coordinate systemEmailError messageDatabaseMessage passingScripting languageSoftware developerInformationInterface (computing)Web serviceCodeOpen setSystem administratorCorrespondence (mathematics)Parameter (computer programming)Service (economics)CASE <Informatik>Connectivity (graph theory)Rule of inferenceRoutingComputer fileBitFront and back endsFunctional (mathematics)Slide ruleMultiplication signResultantImplementationInformationOrder (biology)Scripting languageConnected spaceMereologyDifferent (Kate Ryan album)MappingDatabaseError messageUniform resource locatorClient (computing)Message passingDependent and independent variablesLoop (music)Link (knot theory)TelecommunicationObject (grammar)Data structureSoftware developerOcean currentComputer animation
40:44
Scripting languageSoftware developerWeb serviceInformationDatabaseInterface (computing)FreewareOpen sourceTerm (mathematics)Data managementTexture mappingBoom (sailing)Client (computing)Revision controlToken ringData structureSimilarity (geometry)outputData typeContent (media)Dependent and independent variablesError messageoutputVector spaceCodeDenial-of-service attackMessage passingContent (media)RoutingSoftwareRevision controlInformationDifferent (Kate Ryan album)Software bugTexture mappingConnected spaceWeb serviceIP addressToken ringLengthWeb browserSet (mathematics)User interfaceMappingData managementClient (computing)Validity (statistics)Axiom of choiceBitSource codeSystem administratorFront and back endsDatabasePoint (geometry)Adventure gameInstance (computer science)AuthenticationInformation securityCASE <Informatik>Default (computer science)Slide ruleCore dumpPasswordAvatar (2009 film)Flow separationScripting languageFunctional (mathematics)NumberTask (computing)Data storage deviceGroup actionService (economics)Cartesian coordinate systemComputer animation
48:14
FreewareOpen sourceDialectInheritance (object-oriented programming)Extension (kinesiology)Web serviceFunction (mathematics)Group actionVirtual realityIcosahedronRoutingFormal verificationStudent's t-testData miningTesselationWebsiteMappingAdventure gameScripting languageAreaText editorPresentation of a groupPoint (geometry)Computer configurationLevel (video gaming)Mathematical analysisWeb serviceGame theoryEmailHeat transferCASE <Informatik>Revision controlFunctional (mathematics)Link (knot theory)Event horizonServer (computing)BitLimit (category theory)Repository (publishing)Extension (kinesiology)System administratorTable (information)Physical systemGroup actionService (economics)NumberBefehlsprozessorWeb applicationVirtual machineMathematicsMiddlewareAuthenticationToken ringUniverse (mathematics)Computer animation
56:39
JSONXMLUML
Transcript: English(auto-generated)
00:06
Okay, then I would start. So thank you for your attendance. My name is Tobias Tiefke. I'm studying computer science at Schmerkalten University at Applied Sciences and I'm about to finish my bachelor's by this semester
00:22
and then I will start with my master's and Professor Ralf Stoudemeyer can't be here today. He is a professor at Schmerkalten University of Applied Sciences for IT security, especially IT security on constrained devices like microcontrollers and at our university we have a course on mobile security
00:48
and for this course we have some microcontrollers the students should program and these microcontrollers are located in a laboratory and during the corona pandemic there was no access possible to the laboratory for students
01:03
so in order to make it possible that students can actually take part in this course we had to find a solution on how students can work with these microcontrollers remotely and in order to make this possible we decided to create a virtual laboratory
01:23
which resembles the physical laboratory we have at our university but everything should be available online and also all the time for students without any restrictions and for that we decided on building a virtual laboratory for the university
01:42
which is called the Suezek Lab Virtual Laboratory and I would also like to present that laboratory to you now. So just as a quick outline first I will talk about the main problems we faced and what led to the development of the laboratory then I will talk shortly about Work Adventure
02:02
which we are using as underlying platform for our laboratory so we basically take Work Adventure and extend it and in section 2 I will talk about Work Adventure itself and then in section 3 I will talk about what we did in order to build our own laboratory
02:22
however we had two major issues when we implemented that laboratory first of all we actually had to use a part of Work Adventure which is proprietary
02:40
and of course we don't want any proprietary bits in our laboratory therefore we decided on re-implementing the administration service and in section 4 I will talk about how we did that and in section 5 I will talk about some security issues we found in Work Adventure when building our laboratory and there I will talk about how we found these issues
03:06
and also about how these issues can be mitigated and in the end I will talk a bit about the transferability of our work so that for example if you are interested in building your own laboratory that you have some starting points
03:21
and we also publish all our source codes so that you can just take it from GitHub and build your own laboratory on top of ours or use our code or parts of them so first of all the main problem we had are that these IoT devices
03:42
we have solar tier remotes which are microcontrollers running the Contiki operating system they were developed as part of a research project on confidentiality and integrity in constrained environments but basically that's not the point
04:02
basically you could use any microcontroller for all laboratories or you could also think about using Arduino or similar platforms and as already said our university has a course in which these remotes should be programmed in C
04:24
and as we weren't able to hand out these devices to students we had to find a solution on how students can work with them from home during the time of the corona pandemic so therefore we decided on building a virtual platform however we also wanted a couple of other features
04:42
so for example BigBlueButton is a pretty known platform for online lecturers however BigBlueButton also has some limitations so for those people who don't know BigBlueButton it's basically some online conferencing software
05:00
which was especially designed for lecturers so for example the presenter can upload some slides in PDF format and then the participants can download these slides or the slides are being shown in the browser and that saves a lot of network traffic because the slides only have to be downloaded once and you don't have to share your screen all the time
05:24
however what we found as limitation in BigBlueButton was that even though it resembles a lot like a lecture it basically isn't a lecture because in a lecture you also talk to your seat neighbors and maybe make some jokes or talk about the topic of the lecture
05:43
and that's not possible in BigBlueButton so we wanted to have some kind of option where you are able to talk with your seat neighbors and also without the professor or instructor noticing it and the third problem we also had is privacy
06:01
so for those who had to deal with conferencing systems during the corona pandemic know that there are many many tools you could use but when it comes to open source software or software which is privacy friendly
06:22
then you'll soon notice that many of the conferencing systems which are available are basically harvesting user data or maybe even selling it so we wanted to have a privacy oriented system
06:40
and we only wanted to store as little information as necessary to operate the service so when designing this presentation I was pretty unsure what I should put on the slide and what you can actually see here is not the problem but our solution to it so basically when setting up a user
07:03
for a system in which he should be able to work then the problem we would have is that we have a lot of students and generating accounts for every student wouldn't really make sense
07:20
because each account would have the same rights and therefore we decided on creating one account for each user group so basically all students which are working in the laboratory log in using the same account so basically what you need to store in the database are these couple of keys which are being displayed here
07:43
so the underscore ID basically comes from the NoSQL database we're using the identifier in WorkAdventure is a UUID which we have to store of course and it's also used for generating the invitation link the name key is a bit confusing
08:03
because what's actually being stored there is something like a description of the account so that's not the name but you will have in WorkAdventure itself when you log in you will have the option to select your own name regardless of what is stored in the database so for example for the student account
08:20
the name just is being set to student so that we know that that is the student account the email is also only used as identifier so we just use UUID at the domain where our laboratory runs and some other things like the visit card URL or messages you could send to users
08:42
are basically just things we don't use and the text that's basically just an array of strings which is being used to determine access rights to the maps of our world so now let me shortly introduce you to WorkAdventure which we use as underlying platform for our laboratory
09:02
so for those who maybe took part in the last meetings of the CCC maybe know WorkAdventure because it was used there but for those who didn't take part there I'll shortly introduce you into WorkAdventure now so basically WorkAdventure is a conferencing system
09:24
in the style of a 2D game so basically each user has an avatar which you can move over the map and whenever you move around that map which really resembles a real world you can use several features in there
09:42
so the main feature of course is communicating and basically WorkAdventure features group communication which works just in the same way as in real life so multiple people move their characters close to each other
10:00
then a communication channel is being established between them and they can talk directly to each other and when you decide to leave the group then you also won't participate in that talk anymore and what really is important to mention here is that the communication usually happens decentrally
10:26
so when multiple users stand nearby decentral communication channels are being established between them so that the server on which WorkAdventure is running doesn't get any information about the meeting
10:44
so sometimes it may feel that a decentral meeting can be set up then the server has to interact with that but usually the meetings are decentral so after the meeting ended no one can actually say that a meeting took place
11:02
and another really important feature are so-called actions so if I go one slide back you can see that there are multiple actions not multiple actions but multiple areas in the map and on areas you can put actions
11:22
so actions are basically things which happen after you confirm them so here it says press space or touch here to enter the Jitsi meeting room I know it's not really real but what actually happens here is that once you click on that message or hit the space button
11:42
then you would take part in the Jitsi meeting which was defined as part of this map area and once multiple users are on the same area and open the Jitsi room they can also have a bigger conference
12:00
and what really is important to mention here is that opening Jitsi rooms is just one action so it's also possible to use other actions like embedding websites and iframes and basically that's what we are mainly using for our laboratory so basically Work Adventure has a scripting API
12:25
and also some kinds of event handling so in Work Adventure when you go to a part of a map or an area this can be detected and using the scripting API you can subscribe to events which are being generated
12:43
when you for example walk on a specific area and then you can respond to that event so for example here we have a group workplace and whenever someone comes close to these tables
13:00
then it's being shown which microcontroller is available on the table and also which sensors are connected and here it would also be possible to hit space and then you can work directly with that microcontroller and how this exactly works
13:21
I will present it in the next section but so far I just would like to ask you if everything is clear now or are there any questions so far? Okay, fine, so then I will just talk a little bit about
13:40
what we did in order to build our own laboratory so of course I already talked about BigBlueButton and we decided to integrate BigBlueButton into our Work Adventure system here I have to say that in the latest version of Work Adventure BigBlueButton is also integrated
14:01
but when we started development about a year ago BigBlueButton wasn't available in Work Adventure and also the current implementation does not really feature what we would like to have because in Work Adventure when you use their default implementation of BigBlueButton
14:20
you can join the room but then you are being disconnected from any group communications so basically the whole area where BigBlueButton is defined is not available for group meetings and of course that is not what we wanted to have
14:40
so basically for setting up BigBlueButton we define the lecture room as an area and then we listen using the scripting API we listen whenever the user is walking onto that area and then we just show a message to the user
15:00
if he wants to join the lecture and if the user confirms then we send a request to a service we implemented which basically checks whether the user is allowed to use the service and if that's true then we generate the link to the BigBlueButton room
15:25
and send it back to the user and then the user's client can open an iframe containing BigBlueButton and while the user then joins the conference he is still able to communicate with other users in the lecture room
15:43
so basically what we have here is some kind of a lecture which nearly resembles a real world one because you can talk with your sleep neighbours when it comes to working on virtual machines the task to realise that was a bit harder
16:01
because we had a server on which we created virtual machines however the question is how to access a virtual machine from the web and that turned out to be not as straightforward as we first thought
16:21
but we found a solution to it and that basically works the following way I don't know if you are all familiar with the VNC protocol but for those who don't know it VNC is basically a protocol which makes it possible to remotely control a computer and what we had on our server was a hypervisor
16:48
we used a quick emulator with KVM and luckily that hypervisor already features a VNC server for all the virtual machines which can be enabled easily
17:03
and then what you basically get is a TCP port on which you can connect with the VNC client and usually these VNC clients are native applications but as Work Adventure is a web application we also want it to be the client of web application
17:23
so we looked for VNC web clients and there is one, it's called noVNC it's basically a VNC client written in JavaScript so in theory using noVNC we could connect to that virtual machine
17:42
however the problem still is that using JavaScript you cannot connect to the TCP socket which is opened by a quick emulator so you need some kind of translation which makes it possible for the JavaScript client to communicate with that port
18:01
and for that there is a program called WebSocketify which basically translates a TCP socket to a web socket and luckily JavaScript can access web sockets so noVNC basically also features a second program called WebSocketify and WebSocketify does all the translation between web sockets and TCP sockets
18:25
and then you can actually pretty easily access the virtual machine however the problem we quickly faced is that the original implementation of WebSocketify doesn't really scale well
18:41
so first of all WebSocketify as a main implementation is written in Python and secondly it only can translate one TCP port to a web socket so if we have a virtual PC pool with 30 virtual machines
19:04
we would have to have 30 instances of WebSocketify running which we didn't want but luckily there are some ports of WebSocketify to faster languages and we found a port which WebSocketify was ported to Go
19:25
the port contains some bugs but we were able to fix them really quickly and we also made a small addition on that so that basically WebSocketify can read all the TCP ports and web sockets translations from a configuration file
19:42
and then basically it opens channels for each port that should be translated and using that we were able to have a really quick translation between TCP and web sockets and it turned out that using that way accessing the virtual machine
20:04
basically feels like if you would work with the computer directly however so far we only had a virtual machine in which you can run programs so here what you can see is the Quantiki simulator which simulates microcontrollers running the Quantiki system
20:25
so basically you can do some pretty basic steps in programming microcontrollers but when it comes to larger projects of course it is necessary to work on real hardware
20:41
and here we made the decision to set up computers in our laboratory and connect the remotes to them and the remotes are basically just another name of the microcontrollers we have so these alertier remotes are being connected to the hypervisor of the virtual machines
21:02
and then being passed directly using USB passthrough to the virtual machine and we also did the same with the webcam which films the microcontroller all the time so that for example when you do some exercises like blinking LEDs or something like that
21:20
you can directly see that from home What was still missing was the feature to communicate in groups actually you could use the group communication feature of Work Adventure but the problem is that the radius for the group communication is not so big that you could use it for communicating at these desks
21:44
and furthermore if someone would just walk near the table and someone is sitting there they would be both put in a group and probably not everyone walking by wants to join the group
22:01
so we decided to declare the zones near the tables as silent zones where the group communication is disabled and instead put all users working on a remote into a separate Jitsi room and basically what happens is that we have developed a really small software
22:21
called Multi-User Virtual Machine Assigner which ensures that all people who are working on a virtual machine are also in a Jitsi room and can talk with each other and here you can also see the same effect on a real remote
22:42
in the slide before here you can see another room which is a general purpose PC pool we also developed and using that PC pool you can learn a lot of programming languages we set up many program languages in that virtual machine
23:03
for the general purpose PC pool so for example you can learn Java programming or also web programming using PHP but there are also tutorials on operating systems and so on so here a lot of lecturers from our faculty gave us some material
23:23
we could put into the virtual machines and then the students can work with the materials on their own so here you can also see the same with a remote and here I also have a small video which I would like to show to you
23:44
so basically I'll show in this video how you work with a remote so first you walk to the place and then you well that was maybe a little bit quick but first you walk to the place and then a pop-up is being shown
24:00
in which you can see what remote or what microcontrollers are available and also which sensors are connected to them and then of course also noVNC opens and then you can just put noVNC in full screen and there you can directly work with the remote
24:21
so first of all we're letting show the remote in the console and then we enter some make commands in order to compile a really small program which basically lets some LED blink and now we upload the program to the remote and now you should soon see a blinking LED in the top right corner of the remote
24:46
yeah so now it blinks and basically what you can see here is that you're directly able to interact with the remote and you can program it in real time and basically there are some other commands available
25:04
like accessing the shell of the remote and so on so basically just all features which are available using the toolchain and as already said in the introduction
25:23
it's basically possible to connect any USB device to the virtual machine so if you have other controllers or hardware you would like to program you could also use the solution and just pass the USB device to the virtual machine
25:42
here I also brought you a little photo which shows how the remotes were basically placed in our laboratory so we have a table and on the table basically six remotes are placed for the six group work places we have
26:00
and basically for each remote there's also a webcam that captures the video stream of the remotes as you maybe saw earlier in the screenshot of the laboratory we have more than six places
26:21
but we decided to make six places on which groups can work on remotes and on the other places single user can work with the emulator so the students who just want to get a little bit in touch with how everything works they can for example use the emulator and the students who work on bigger projects
26:42
they can use the physical remotes so just to show you how everything works together I have created that figure which basically shows the main parts of our laboratory
27:01
so of course there is Work Adventure which has a front end which is basically the client you run in your browser and then the back end which are services we offer on our server and Work Adventure on its own also already embeds Jitsi which you can use since a couple of months
27:22
I think also BigBlueButton but here we decided to use our own implementation so basically we have two options on how to integrate BigBlueButton and in order to make it possible to work with the remotes we also integrated noVNC into the Work Adventure front end
27:44
and in order to being able to communicate with the virtual machine itself we use the VNC server of this virtual machine provided by the hypervisor and translates the TCP socket to a WebSocket using WebSocket file
28:01
and for multi-user workplaces we have developed a multi-user virtual machine assigner which embeds noVNC and Jitsi-meet and that way it ensures that the people who work on a multi-user workplace can also communicate with each other
28:23
for being able to create BigBlueButton rooms we also have to call the BigBlueButton API from the Work Adventure back end but basically there are only some API calls I think in our implementation the whole creation of the BigBlueButton room is maybe about 50 lines of code
28:45
so it's actually pretty straightforward and the BigBlueButton API is also documented very well but still we had one large problem and that is that some features Work Adventure offers are only available in the paid version
29:02
so there's an open source version which contains the most important parts of Work Adventure but there's also a paid version which you can use for features like access restriction to the map because if you don't use any access restriction basically everyone who has a browser can visit the laboratory
29:22
and do stuff there and we didn't want that but we also didn't want to pay for proprietary software and of course in order to preserve the user's privacy we also wanted to have all the data in our data center so we definitely didn't want to integrate the administration service
29:43
from Work Adventure itself so we decided to re-implement it and on that I would like to talk now but so far I would also like to ask you if there are any questions so far yes? Oh, I think you need a microphone
30:02
oh yes, that's also okay yeah, so the question was how do we deal with microcontroller failures
30:23
for example if the microcontroller stops working or has to be reset so that's a really good question and that was a problem we faced and for some problems we don't have kind of a real solution but usually resetting them is in our case
30:44
likely possible using a command we can issue over USB so we can do it from the virtual machine and if the microcontroller becomes stuck it may not be available via USB
31:02
but we found out that it luckily resets when rebooting the hypervisor so what we actually have is that we have one desktop computer for each remote and if a remote fails then we just reboot the hypervisor and then after the reboot the remote is available again
31:21
so it's maybe not a perfect solution but one which works and also works without anyone having to go to our physical laboratory and reset it manually okay, so I hope this answers your question
32:05
the microcontroller itself when being connected to the hypervisor basically we have installed the toolchain which we use for programming on the hypervisor too and for our microcontroller there is a toolchain which makes it possible to communicate directly with the controller
32:26
so in case anything fails there we can always issue commands via USB and if that fails then we can just reboot the hypervisor so I hope this answers your question
32:40
okay, so for the details we can also talk about that after the presentation okay, so I don't know if there are any other questions otherwise I would continue with the reimplementation of the proprietary admin services so basically when showing you the architecture of the laboratory
33:05
I was a bit simplifying on how WorkAdventure works so WorkAdventure has the front end of course which is the client running in your browser but the back end actually isn't one service but there are many services which interact with each other
33:21
so when connecting to WorkAdventure you basically connect to the pusher service and the pusher service can either answer a request on its own or forward the request to another service which can be the back service which is part of the back end
33:40
but actually the pusher also acts like a back end so it's not very clear to say what actually is the big difference the documentation says that the pusher handles all incoming connection and forwards them
34:01
but when you take a closer look at the code then what I have to say is that it rather looks like the code evolved by the time and you can't really make a very clear distinction but maybe there are also people having other opinions on set
34:22
so if someone wants to share that I'm also very happy but the main distinction basically we have to make is that the pusher and back service can work with or without the administration service so if you don't use the proprietary administration service or our implementation
34:48
then the pusher and back can notice that and just give you an error when a function which actually would require a working admin service
35:02
then you would just get an error I can show it to you in one slide so how did we actually found out how the communication to the admin service works? So as pusher and back have to talk to the admin you also can find the structure of the API endpoints in the code
35:24
because of course pusher and back have to know where the admin service resides and also how to interact with it so the API endpoint structure was already defined in the code more or less
35:41
since a couple of weeks it's also documented using open API so building your own administration service is a little bit more easier now it wasn't documented when we started our development but you could actually see pretty fast that the communication with the admin service
36:05
only happens using HTTP requests which are being sent to the administration service and then the administration service responses with a JSON encoded object so here I also brought a small code snippet from the getURLRoomsFromSameWorld function
36:27
so basically that function is being used when an administrator tries to broadcast a global message to all users over all maps of the world and what you can see here is that if no admin API URL is defined
36:45
which actually just means that no admin service is available then you get back an error and in case you have an admin API then a request is being sent to it using Axios
37:02
and if you get results then the data of the request is being returned to the client in this case the client is the backend but the backend then acts basically as
37:22
well the backend then works a bit different how to say it's the easiest way the backend when I'm receiving the answer from the administration service evaluates it
37:41
and then handles according to the result or it deals with the error it got because no admin API is present and in the files I mentioned you can find all the other admin API endpoints
38:01
so when defining our admin services we just provide these API rules routes and our administration service then has to interpret the data
38:20
which was sent by the backend and can then act according to it so in that case the getAllMaps function basically hands over a parameter from the current room's URL but actually even if this parameter is handed over I didn't really figure out how that data is used
38:45
and from what I assume is that basically this parameter is not even used at least our administration services works without that parameter for over half a year now so what we do is fetching all maps from the database
39:04
and generating all links of the world using it for each loop and then we just return a JSON encoded array of all rooms we have and basically then the function in the backend just returns this data
39:25
back to the back or pusher service which ever calls the API so our administration service basically works that way we set up a PHP script for each request
39:46
so each request has a corresponding PHP script which is being called when the back or pusher component calls the corresponding API endpoint in order to implement our administration service we had to look up how the fetch data is being used
40:06
because no documentation was available but even though it worked very well to figure out how everything works and now there's even documentation available so if you would like to build an administration service
40:23
now you could use the open API definition and for example use Spagger for generating the API endpoints even though we don't want to store any user information
40:40
we at least have to store the information about the account and there we use a NoSQL database but of course we try or we also only store just a little bit of information so we don't have to store any information which could be used to figure out
41:03
which person is used as a service and WorkAdventure also only stores IP addresses and so on temporarily so as soon as the user leaves the laboratory basically the information about him is gone
41:21
well then we still had the problem that if you have a database and you want to get data from it that's one thing but the question also is how do you put data into the database and of course you could use it using the command line but this would be a pretty tedious task
41:42
if you have a larger number of users or user groups so we decided to build a small web interface for that so that it is easily possible to input and modify data and that was also the reason why we use PHP for answering HTTP requests
42:05
then from backend pusher because in PHP we were able to just define all the database functions we need and then we can reuse database functions we use for our web interface we can reuse it for the scripts answering the HTTP requests
42:23
so that we just save some kind of work here and yes that's just a little screenshot of our administration web interface so basically in the administration panel you can change the settings
42:42
of all the rooms or maps we have and you can also do some kind of user management like for example which user is allowed to access which maps and concerning textures you can also add textures using the administration service
43:02
so if you have like an own avatar which you would like to use you can just edit using the administration panel and then use it in work adventure so yes that was the last slide on how we re-implemented the administration panel so if there are any questions left you can ask them now or later
43:23
so I don't know if there are any questions regarding that this doesn't seem to be the case and I will probably talk about security related issues we found so basically since many services of work adventure communicate using HTTP requests
43:44
we just tested a little bit out what happens for example if you send crafted HTTP requests to services and for that we used an HTTP client my choice was curl but of course you could also use other clients
44:03
and so basically an attack vector we found was that using crafted requests you can basically interact with many access points because there is little access protection and we also found out that default administration token
44:24
which is being present in the community version can be misused for acquiring debug information which maybe should be available for admins but definitely not for everyone so we crafted some HTTP requests and with them we were able for example
44:45
to show a warning that the room is almost full and we also received different kinds of debug messages and we even found one denial of service error which happened during processing a crafted API request
45:04
here are the solutions to them of course do not use any default values and even if you set up work adventure software on that own don't use the default value which is present in the source code
45:23
if you find something like that you should change it but better change the code so that something like default or admin passwords are hard coded in code because sooner or later someone is going to figure that out and misusing it
45:43
yeah so concerning access restrictions of course it has to be checked if a user is allowed to use the API route so a little bit of authentication there is a good solution and also validates the input of the user
46:02
so we had for the denial of service error we had a problem that it was detected that the user is not an admin and even the input was validated there but the error which was then thrown wasn't handled correctly
46:22
and this error basically caused the failure of the application itself so it should also be mentioned that errors should be handled properly and in some other API requests we also found that input validation is missing
46:41
and with some specific input you can also cause some errors so just let me show the code how to receive the debug information all the issues I presented basically use some crafted HTTP requests
47:08
so I won't show every request on separate slides because they all work very similar but you were able to receive debug information and work adventure
47:21
by calling the dump route on pusher and then handing over the default token default administration token and in every community instance then work adventure replied with debug information about the users I cut it out there but you can see in the content length
47:42
that a lot of information was sent back to the client sending the request and in that content which was sent back you could for example find all the IP addresses of the connected users
48:00
of course we reported that bug and it's also been fixed for quite a while now but there were many HTTP routes which you could pretty easily abuse and I also am unsure whether all routes are secured now
48:27
I hope so but when I found this it was some kind of month ago and I hope that they introduced the verification of users everywhere
48:48
and not only at the points which I found out and reported because a fellow student of mine did the same analysis a couple of weeks later
49:01
and he found some routes which were not secured but were secured when I did this so I hope that current versions are well hardened but I also saw that there were some commits concerning that
49:22
so I hope that everything is fixed and they have learned from that issue Here in this screenshot you can basically see this full room warning which I mentioned earlier so basically when a number of users has been connected to Work Adventure
49:42
and the server has the feeling that maybe the CPU is running or is running on its limits then you can say that no more people should be allowed to enter the laboratory and then you can show this warning
50:03
but the problem here is that when I tested this route everyone was able to show that warning by just calling the route so basically this shouldn't work for everyone
50:22
and of course we also reported that issue and it has also been fixed now So I don't know if there are any questions regarding this analysis if not I would continue with the transferability and of course you also have the option to ask questions
50:41
in the end of the presentation So basically our solution inherits all features from Work Adventure So it's also fully cooperated with Work Adventure and what we did is extending these features by using the scripting API
51:05
So basically all the features we added now happen in separate services so we can develop them independently from Work Adventure So whenever a new version is being released we can pretty easily upgrade
51:23
because we don't have to do any changes in Work Adventure so we more or less go with the vanilla Work Adventure from Upstream and just put everything we added into scripts which are being loaded along the map
51:41
and this functionality of course we added the functionality to work on virtual machines and group and also we added BigBlueButton and in the end we also re-implemented the proprietary admin service
52:01
but still there are, as you can basically include any web application you can add a lot of extensions to Work Adventure if you want so just feel free to add your own extensions and if you're interested in how that is being done you can have a look at our GitHub repository
52:23
so just go to github.com through our seclab and you can find out about all the services we added and I can also tell you now that the services we added I only talked about some of them so you can find out about more services on GitHub and we also wrote a small article about the laboratory
52:43
which you can find under the following link and in case you have any questions you can just contact me or Professor Stoudemeyer via email so that's basically the presentation and I would also like to thank my fellow students
53:03
who helped me with this talk for example for taking the pictures I showed to you earlier and there were also some fellow students who developed some other features for our laboratories for example there's a relaxation area in which you can play games like Pac-Man
53:20
and some students also developed their own games which we include so I would also thank them for their contributions and yeah so if you have any questions now please let me know and I will try to answer them yeah okay so for the maps
53:46
there's basically a map editor so Burke Adventure uses a tiled map editor which is used by a couple of 2D games and just creating a map by saying there's a table there's some lobby and so on
54:03
so that basically goes pretty quick because it's basically what you see is what you get editor it becomes a little bit more difficult when adding own services then you have to write a script and basically what we do is that
54:21
the JavaScript we add subscribes to events happening on the map and when you for example detect that the user enters a specific area then we respond to that and usually what we do is that we include a website which contains the requested service
54:40
and for that we have usually to create a link for example to handle overjot tokens which we use for authentication and what we basically do is that we create an XHR request to the service
55:03
basically it's more or less a middleware which does all the authentication and if the user can be authenticated then a link is being sent back to Burke Adventure which is then being included as iframe okay so are there any more questions
55:23
yes okay so Schmalcalden University of Applied Sciences is a pretty small university so usually we have a maximum of about 50 users
55:45
and so for us the system works really fast but of course if you have larger numbers of users then the system will eventually become slower
56:08
yeah so if there are no more questions then I would like to thank you for your attendance and interest in the talk and if you have any more questions which you would like to ask me just ask me now or somewhere after the presentation
56:23
I'm here for still a couple of hours so just ask me and I will give my best to answer your questions thank you
Recommendations
Series of 6 media