Category Archives: nviso

Hack Our Train

This year, in an effort to raise awareness about IoT security, we launched the Hack Our Train challenge. For over three weeks, a model train tirelessly chugged on its tracks inside our IoT village at Co.Station Brussels and then once more for two days at BruCON 2017. We provided it with an emergency brake system powered by IoT technologies and challenged people to hack it and stop the train! With every successful hack, the train stopped, creating a service disruption. A live-stream allowed hackers to monitor the effects of their attacks.

The Hack Our Train challenge was actually composed of two parts: a local one, situated close to the IoT village and then its online counterpart. The local challenge did not require any specific technical skills. It invited people to try and break the pin of the controller that activates the emergency brake mechanism. Check out this video of people having fun with the controller:

But, the online part is where things became really interesting! Over the course of the challenge, only a handful of people succeeded in figuring it out and remotely stopped the train… In this post, we’ll provide a walk-through of the challenge and focus on some of the vulnerabilities featured in it and, more importantly, on ways to fix them.

Hunt for the firmware

On the challenge website, we provided aspiring hackers with the following scenario: Bob, one of the IoT village’s railroad technicians, recently had to update the emergency brake panels. Unfortunately Bob left his USB flash drive laying around and Eve found it and made its content available online!

The first step is to analyze the USB’s contents. It is a zip archive containing two files: firmware.enc, which conveniently hints to the encrypted firmware and a binary file called firmware_updater. The firmware updater is used to decrypt the firmware and then upload it to the control panel via a serial connection.

If we execute it on a Linux machine, the firmware_updater asks us for a pin before decrypting the firmware. People who braved the challenge came up with all sorts of clever ways of cracking the firmware_updater binary and forcing it to decrypt the firmware.

For now, we will resist the temptation of breaking out our dissassemblers and debuggers and we will just look at the strings inside the updater. There are some really interesting parts:

strings1

strings2

If we think this out (of course, dissassembling would make this much easier), the firmware seems to be encrypted using AES. To perform the decryption ourselves, we would need the key and the initialization vector (IV). Luckily, these are hard-coded into the firmware (see image above).

So, we just need to turn those into their hexadecimal counterparts and we are set:

bash openssl enc -aes-128-cbc -d -in firmware.enc -out firmware
-iv 766563353667647639396e6e73647161 -K 686f746b3138313965663132676a7671

Vulnerability: use of hardcoded cryptographic keys.

Fix: if possible, avoid using schemes that require hardcoded keys. If using a hardcoded key is unavoidable, there are techniques that can be employed to make the key harder to recover. Ideally, decryption should be performed directly on the embedded device, which avoids the need to expose the key in the firmware updater.

One last word on the update procedure we just cracked: now that we have the keys, no one can stop us from modifying the decrypted firmware to add or remove some functionalities, encrypting it again and uploading it to the device. The emergency controller would have no means of knowing if the firmware has been tampered with.

Vulnerability: firmware not digitally signed.

Fix: Digitally sign the firmware so that the embedded device can verify its authenticity.

Inside the firmware

Phew, we have the firmware, now comes the hard part: we have to reverse engineer it and find a way of remotely trigger the emergency brake mechanism.

Using the file command on the firmware reveals it is in fact a Java archive. This is really good news: using a Java decompiler, we can easily recover the source code.

Vulnerability: code is easy to reverse engineer. Attackers have easy access to the internal workings of the application, which makes it easier for them to find exploits.

Fix: use a code obfuscation tool – there are many available online, both free and commercial. Once you have used the tool on your code, test your application to make sure that it is still functioning correctly. Remember that obfuscation is not a silver bullet but it can drastically increase the effort required for an attacker to break the system.

Before looking at the code, let’s try running the firmware. We are greeted with a status page containing a button to initiate an emergency brake, but we need a pin.

screen1screen2

A quick look inside the source code reveals that it is simply “1234”. We have managed to unlock the button. Spoiler: it doesn’t work!

Vulnerability: use of hardcoded passwords.
In our scenario, the password was of no immediate use. Still, this would be harmful if we ever had access to a real emergency brake controller.

Fix: if the password must be stored inside the application, it should at least be stored using a strong one-way hash function. Before hashing, the password should be combined with a unique, cryptographically strong salt value.

In order to understand what is going on, we can simply look at the debug messages conveniently left behind in the console. Seems like the protocol used is MQTT and for some reason, we receive an authentication failure error when we try to perform an emergency brake.

Vulnerability: leftover debug messages containing useful information.

Fix: scan your code for forgotten prints (system.outs in our case) and remove them before release, or disable them at runtime.

Look below the hood

Before going further, let’s take a step back and have a closer look at the architecture of our system. This step was of course not needed to solve the challenge but we thought it complements nicely to this walk-through!

As we just discovered by looking at the source code, communication is based on the MQTT protocol, often found among IoT applications. MQTT works on top of TCP/IP and defines two kinds of entities: Subscribers and Publishers. Publishers send messages on communication channels called Topics. Subscribers can register and read messages on specific Topics. These messages are relayed with the help of a server (also called a Broker).

circuit

This is a look below the hood of the mountain (this was our beta setup, our final circuit was much cleaner!). Two elements steal the show: an Arduino and a Raspberry Pi. The Arduino is the muscle: it controls the transistor that stops the train. The Pi is the brains: when it receives an emergency brake message, it orders the Arduino to stop the train.

Both the emergency brake controller (where the firmware runs – it is not shown in the picture) and the Raspberry Pi (shown in the picture) are connected to the internet. They communicate with the MQTT Broker to exchange MQTT messages. The Pi publishes messages concerning the train’s speed but it is also subscribed to a topic waiting for emergency brake messages. The controller displays the train’s current speed and, when the emergency brake is activated, it publishes an emergency brake message that the Broker relays to the Pi.

Of course, not anyone can send an emergency brake message to the server. In our infrastructure, authentication is based on JWT tokens. These are issued by the server relaying the MQTT messages and they are signed using the server’s private key. When  clients try to authenticate using one of those tokens, the server can verify their authenticity using its public key.

To clear all this up, we have created an overview of the MQTT communications going on in the images below:

speed

brake

Tokens, tokens everywhere…

Back the authentication problem. Digging into the source code confirms that authentication is JWT token based. Maybe there is something wrong with the token? Another file inside the JAR that immediately draws our attention is notes.txt. A quick look reveals some notes of a developer that was worried about his JWT token expiring. We can easily verify the creation date of the token here. Seems like out token is really old and as we don’t have the authentication server’s private key, we cannot create a new one.

Vulnerability: old and unused left behind files containing sensitive information.

Fix: before publishing your product, make sure to remove every non-essential ressource.

Knowing how the authentication works, it is time to turn to our favorite search engine for more intelligence. Let’s try jwt token vulnerability. The top result states “Critical vulnerabilities in JSON Web Token libraries“: perfect!

The author does a great job of explaining the vulnerability and how it can be exploited, so we leave you in his hands. For the purposes of this post, the idea is that if we create a forged token using the authentication server’s public key as a HMAC secret key, we can fool the server into verifying it using HMAC instead of RSA, which results in the server accepting our token.

Attack!

Having identified the vulnerability, it is time to perform our attack. For that, we need the server’s public certificate, which is kindly included in the JAR as well. As mentioned in the notes file, it has been converted to a format compatible with Java but the server is more likely using it in PEM format.

Luckily, converting it back is easy:

keytool -importkeystore -srckeystore hot.ks -destkeystore temp.p12
-srcstoretype jks -deststoretype pkcs12

openssl pkcs12 -in temp.p12 -out public.pem

Next, we have to create our malicious token. You can do this in the language of your choice. We used the jwt-simple node.js module.

With the malicious token crafted, we can finally perform the attack. The easiest way is to reuse the code included in the testMQTT.java file, conveniently forgotten inside the JAR. We just have to replace the token found in the code, compile the code and execute it from the terminal.

The select few who made it this far in the challenge saw the train stop on the live-stream and received the flag!

Vulnerability: using components with known vulnerabilities.

Fix: apply upgrades to components as they become available. For critical components (for example, those used for authentication), monitor security news outlets (databases, mailing lists etc.) and act upon new information to keep your project up to date.

Lessons learned

Our challenge involved a toy train but the IoT vulnerabilities demonstrated inside are the real deal. We added each one of them to the IoT challenge because we have come across them in the real world.

On a final note, we would like to congratulate those who were able to hack our train and we sincerely hope that all of you enjoyed this challenge!

Stalking a reporter – behind the scenes!

Introduction
Around mid-October we got a call from a reporter working on an article covering online privacy and social media. Rather than writing about others, the reporter wanted to have his own story. So, he asked NVISO to research him on-line, and find out as much as possible about him! Of-course, after agreeing on some “ground rules” with the journalist, we were 100% up for it!

The ground rules that were put in place:

  • We would focus on mining only publicly available information, not make him a target of an attack.
  • We were not allowed to use social engineering tricks on him or his friends and family to get additional information.
  • In other words: we could use any information already available online, without actively asking for more.

The article that was recently published by the journalist can be found online (Dutch only, sorry!): http://www.nieuwsblad.be/cnt/dmf20171107_03174488. For anyone interested in the “behind the scenes” on how we approached this – keep on reading!

Let’s hunt!

The team that stalks together…

We assembled a small group of volunteers and got to the task. We created a repository to collectively track our findings, as all bits of information would help the other researchers to move further on their own search, or validate information pieces gathered from different sources. The starting point was obvious: We had the journalists’ name, the email address he used to propose the experiment and a phone number on his signature. Plenty of information to start from!

The first step was to find his Facebook profile. We quickly found out that the reporter does not use the combination name + last name as the profile name, making it more difficult to track down the profile (assuming that he actually has a Facebook profile 😊). But as it often happens, some friends had mentioned his full name on publicly tagged Facebook pictures. We knew his face now! After that, identifying his own profile was possible by looking at metadata in the pictures, including the tagged friends. From there on we started building our file. The privacy settings for the profile were (unfortunately for us) quite restrictive… luckily for us that was not the case for all his friends!

Screen Shot 2017-11-14 at 14.57.36

Facebook showing profile picture after you’ve entered a wrong password

We found his personal email account by guessing and trying to login with the email account to Facebook. Facebook shows you your profile picture when you say that you forgot your password. That is how we could link his personal email with Facebook. We correctly guessed that he also used this email for other social media and apps, and used the same method to see of he had an account. From there onwards, figuring which other services he was using was easy. From there we could gather additional interests, routines, professional activities, social relations…

Of course, this kind of research leads to many false positives. In our case, someone with the same name happens to live close by to our reporter, and some of our data actually referred to that person. That is where crossing data from different sources comes in handy. It allows to discard some of the bits that don’t really match the puzzle.

During our investigations, we also discovered details on the ex-girlfriend of the journalist – her online activity proved to be an excellent source of information! Prolific Instagrammer, her account gave us a lot of info about travels they did together, pictures, friends… Why do we know she was his ex? They are not friends on Facebook anymore! We got no juicy stuff about the breakup, though.

With the parents name (which we found in a cached document on Google), we could find their house, pets, and social media accounts with additional clues… We could assemble a fairly decent family tree. We were also able to find his home address.

With these results we got back to our reporter. He was quite surprised by the things we found out without directly approaching him or his friends! He found particularly scary what we found out about his family and his ex-girlfriend.  He was surprised, though, not seeing his birthdate on our data list.

One step further … go phishing
After our initial investigations, we mutually agreed to take it one step further. 

So what did we do ? We created a fake Facebook profile to trick him or his friends into sharing additional information, contacting his parent or just some good, old phishing to get his credentials and access his email account. We opted for the last option.

We crafted an email based on his interests (which we already identified during the first part of the research). We sent him a link that sounded very relevant for him, so he would definitely try to check it it. And it worked, even though he knew he was going to be targeted by us in this time window. He clicked, and he was directed to a google authentication page. Google? Well, actually NVISO-owned, Google-looking. That is how we got his password.

Once we gain access to his account, we stopped the game. We called him and showed him we were in by sending a mail via his own private inbox to his work email. The challenge was completed. We left nicely, whiteout reading his emails.

Untitled

Emailing from within the inbox of the reporter to the reporter (yes, this is a dummy screenshot!)

In a meeting afterwards, we explained him how he was phished. Up till then he had no clue how he had given us his credential! But we have to confess: still, we didn’t get his birthdate.

Conclusion
Most people aren’t too surprised anymore about the wealth of information available on each of us online. What is interesting, though, is how often we believe we are fine, just because we have our privacy settings nicely set and reviewed for all our accounts (as was the case with the journalists’ Facebook profile for example). That old account you forgot you had, the friends that tagged you, the university bulletin, a legal document or a nice note in memoriam of a loved one can give most valuable information to anyone who is interested.

Entering the active reconnaissance part, phishing once again proved a very reliable method to get additional details from a target – in our case, it even gave us full access to the journalists’ mailbox.

We are all on-line. Most of our life is these days, and that is not necessarily a bad thing. But it is important to remember that, despite all privacy and security rules we want to enforce, humans are still the weakest link. Understanding how we share information online and the impact it has on us and others is key in an increasingly digitalised world – we are happy to have contributed to the article & hope to have raised some awareness with the readers!

 

Don’t be lazy with P4ssw0rd$

Three challenges to making passwords user-friendly

Following the interview of Bill Burr, author of NIST’s 2003 paper on Electronic Authentication, in which he announced that he regrets much of what he wrote, we stop and think.

Why was the standard putting users at risk? Paraphrasing History: “Tout pour le peuple; rien par le peuple”. Perfectly correct from a theoretical point of view, the standard failed to acknowledge that users are indeed people, and when asked to follow too complex rules they will find “tricks” to help themselves to remember their current nightmarish password. Of course, said tricks are fairly easy to guess by any decent hacker, let alone an educated computer.

Nothing new here, the user is often and unfairly considered as the problem. But since there is no easy way to fix the user, it is up to us, as security and IT professionals, to design and build our systems to make them more resilient to human mistakes, and maybe some laziness.

Screen Shot 2017-08-28 at 09.36.42

Difficult for you, easy for a computer : passwords haven’t been what they should.

 

Ah, those funny stories on predictable passwords

The problem with the previous standard wasn’t that it was advising people to make easy to crack passwords, but that too complex rules steered users towards the path of least resistance: very complex and very predictable passwords.

I remember working in a team where, by knowing how long one of your colleagues had been around, you could easily guess their password, applying the simple rule of Company_nn, where nn was the number of the rotation of the password.

So, what now ?
Three challenges to making passwords user friendly

The new NIST 800-63 special publication, and previous publications such as GCHQ’s NSCS guidance, turns the approach upside down: make your password policy user friendly and you’ll get better security. A simple idea: put the burden as much as possible on the verifier, not the user. With one dream: create security that works no matter what the people do. Is it all that easy ? Let’s look at three recurrent challenges we’ve encountered at our clients:

1. Make it hard to guess with blacklist check

What is this about?
Forget complexity and just make sure you don’t use a word from the dictionary, a known first or last name, or a commonly used password (based on public lists of breached passwords). Now, this is easier than done.

Why is it a challenge?
While quality password blacklists can be found online, neither the blacklist validation mechanism nor the integration with frequently updated blacklists is proposed in most systems and applications on the market. Azure AD, for example, has offered this functionality for only a year, and its scope remains limited. And then, most organizations use a local AD. Or something else that doesn’t have such a native password validation check.

So what ?
There are workarounds of course, but they’re not always robust and imply manual maintenance of a blacklist – an effort many organizations are reluctant to commit to. It will be interesting to see how the market catches up on this one. Until then, well, most system admin prefer to keep some complexity requirements on.

2. Make it easy to remember by promoting the use of passphrases

What is this about?
Lengthy passwords, such as passphrases, are much more likely to integrate human randomness: easy to remember, yet almost impossible for an automated system to make sense of when properly done. As usual, xkcd got it right.

Why is it a challenge ?
While passphrases are a simplification on paper, especially if complexity requirements are dropped, they’re also a new paradigm for most end-user. Let’s face it: 24 characters password sound scary and users are clearly reluctant to commit to this. We’ve tested this on a few friends: after some enthusiastic explanation from our part, they agreed to switch.
For the first few days, our names were accompanied with words that weren’t exactly kind. After a week, the cursing had disappeared and they got used to typing long passwords, often several times to get it right. With locked out increasingly replaced by password throttling, frustration was luckily enough not turned into user being locked out.
But only a few passwords were changed: replacing all passwords in use meant inventing tens of completely new password, based on a completely new reasoning.

So what ?
This tells us that Awareness and communication is needed to make mentality evolve. Maybe re-using some of the good Belgian material of our friends at safeonweb.be. Even like that, you may wish to focus your effort on one specific password – typically, their Windows password.
But this also tells us that users should only have to remember 4 or 5 passwords: the rest should be in a password vault. Here too, it’s about changing users habit. And again, this works fine until you want to connect from another device than the one hosting the vault. Who said Cloud? But that’s another debate.

3. If it’s still a secret, why change it?

What is this about ?
NIST has gone bold on the advice: only change password if you think (or know) it’s compromised. Don’t have them recurrently expire, this is exactly how passwords become predictable. Of course, this only works if other NIST recommendations are implemented, especially increased length and blacklist check.

What’s the challenge ?
It’s like Perfect Information of consumers in economics: in theory, we should all know everything. But look around and you’ll see it may take months or years to find out your users’ passwords were stolen – not to mention they might have been using that password all over the internet.

So what ?
The best friend of “no expiration” is “second factor”, making sure the memorized secret alone won’t let them in. Of course, with cost of these things and their inherent complexity, you’ll probably select risk-based on which layers and Apps you want to implement it – or even better, go for a common authentication portal that supports adaptive authentication.

What does this all tell us, then ?

That the world is moving to user-friendly security, at last. And the best part is: it’s doing it because old security didn’t work. But it also tells us that these things will be complex to implement, because systems are not ready, implementation will prove complex, and users have to unlearn what we’ve spent the last 20 years pushing into their brains.

This is essentially what our colleague Benoit said on TV a few weeks ago, in case you missed it, you can watch it here.

4B912252

 

NVISO at DEF CON 25

Staying up to date with the latest hot topics in Security is a requirement for any Security Consultant. Going to conferences is a great way of doing this, as it also gives you the opportunity to speak to peers and get a good view into what the security industry and the researchers are up to.

This year, we sent a small delegation to DEF CON, which is one of the most known Security Conferences in the world. We think everyone should go there at least once in their careers, so this year we sent Michiel, Cédric, Jonas and Jeroen to get their geek-on in Las Vegas!

From left to right: Cédric, Michiel, Jonas and Jeroen ready for their first DEF CON!
Ready to turn off your phones and laptops…

The conference was held at Caesar’s Palace’s conference center, right in the middle of the famous strip. There were four parallel tracks for talks and a lot of different villages and demos throughout the entire conference. We know that What happens in Vegas, Stays in Vegas, but some of these talks were just too good not to share!

Internet of Things (IoT)

There was a large focus on IoT this year, which was great news for us, as we’re actively evolving our IoT skillset. Cédric, our resident IoT wizard, has been running around from talk to talk.

A further update on the IoT track will be provided by Cédric once he is back from holidays 🙂

Mobile

The amount of talks on Android / iOS was fairly limited, but there were definitely some talks that stood out. Bashan Avi gave a talk on Android Packers. The presentation is very thorough and tells the story of how they used a few of the most popular packers to devise an algorithm for detecting and unpacking variations of the same concept. Their approach is very well explained and could be really interesting for our own APKScan service.

Screen Shot 2017-08-03 at 07.46.16

A typical flow of Android Packers (source)

On Sunday, Stephan Huber and Siegfried Rasthofer presented a talk on their evaluation of 9 popular password managers for Android. Their goal was to extract as much sensitive information as possible on a non-rooted device. Even though you would expect password managers to put some effort into securing their application, it turns out this is rarely the case. The following slide gives a good overview of their results, but be sure to check out the entire paper for more information.

Screen Shot 2017-08-03 at 07.53.18.png

The results of Stephan Huber and Siegfried Rasthofer’s research on Android Password Managers (source)

Biohacking

One of the most interesting talks for us was given by John Sotos (MD). While almost all talks focus on very technical subjects, John gave an introduction on the Cancer Moonshot Project and how creating a gene-altering virus targeted at specific DNA traits is inevitable. This is of course great from a Cancer-treatment point of view, but what if someone would alter the virus to attack different genes? Maybe an extremist vegetarian could make the entire world allergic to meat, or maybe a specific race could be made infertile… In his talk, John explains what could go wrong (and he is very creative!) and how important it is to find a defense against these kinds of viruses even before they actually exist.

Villages

Crypto Village

One of our biggest projects within NVISO Labs consists out of building an out-of-band network monitoring device. In the most recent years we’ve seen a lot of the web shift to HTTPS.

 

While this is definitely a good thing in terms of security, it does limit the possibilities of monitoring network traffic. Malware authors know this as well, and are starting to increasingly adopt TLS/HTTPS in their CnC communications (e.g. the Dridex family). In the crypto village, Lee Brotherston demonstrated various techniques to fingerprint TLS connections and even showed a working PoC. This could allow us to create fingerprints for various malware communications and detect them on the network. More information can be found on Lee’s GitHub page.

Car Hacking Village

When we were looking through the villages available at DEF CON this year, the newest car hacking village immediately caught our attention. In the room were several cars with laptops hooked to the dashboards and people trying to completely take over the controls. In the middle of the room was a brand new Dodge Viper of which the steering controls got reprogrammed to control a video game instead of the actual car. Some of our colleagues even got the chance to test drive it! Although with mixed results …

DF8gzSOV0AADxw4

Jonas learning how to drive a sports car (and not doing a great job 😜).

Packet Hacking Village

The Packet Hacking Village (PHV) is one of the biggest, if not the biggest, village in DEF CON. It’s also the place where Jonas spent a lot of his time, meticulously following talks and taking notes. Different talks could be linked to various steps of the cyber kill chain and were interesting to consider for red teaming assessments or as part of the blue team protecting against these attacks.

One of the presentations that stilled our offensive hunger was given by Gabriel Ryan and discussed wireless post-exploitation techniques. One of the attacks allows to steal AD credentials through a wireless attack using a ‘hostile portal’ that redirects a victim’s HTTP traffic to SMB on the attacker’s machine. This, and his other attacks were facilitated by his own eaphammer tool.

Our blue side was satisfied as well with a talk on Fooling the Hound, which attempts to thwart attackers making use of the BloodHound tool, aimed at visualizing the relationships within an AD environment. His deceptions include fake high-privilege credentials, which increase the shortest path towards a high-value asset. The resulting BloodHound graph showed a greatly increased number of nodes and edges, thereby complicating an attacker’s lateral movements!

Meetup with the CSCBE winners

As you may know, the winners of NVISO’s Cyber Security Challenge 2017 received tickets to DEF CON which was an excellent opportunity to have a little Vegas CSC reunion!

DGAQxY8UIAAenHH

Return to sender

All good things come to and end, and so did the DEF CON conference. We had a really great time in Las Vegas, and everyone made it home safely without losing too much money at the poker table ;-).

Screen Shot 2017-08-03 at 08.15.23

Who is watching your home surveillance systems?

This morning, I heard on the radio that dozens of Belgian families were being watched through their own home surveillance system in Belgium. Nothing new here, as we already know for years that sites exist through which you can watch camera footage of unknowing victims, and this problem is not just limited to Belgium of course.

Now, looking at this from an IT security perspective, it would be easy to say “it’s their own fault, they should have changed their default passwords!” or “it’s their own fault, why would you make your surveillance system internet accessible?”. The reality is that most users don’t see an issue with connecting their home surveillance system to the internet – especially not if it’s fully supported by the vendor! In the end, it’s reasonable for the user to expect from the vendor that the surveillance system is installed in a secure way.

shodan

A quick search on Shodan – a search engine for connected devices – shows thousands of publicly exposed surveillance systems all over the world.

A few weeks ago, one of our colleagues had a specialized firm install security cameras around the house. Our colleague had to move heaven and earth to explain that the video controller should not be directly connected to the internet but that it should be connected to the internal network which is firewalled. As you can see, most people would have no notion of this and would be happy to see the video footage everywhere they go from an app on their smartphone without any type of authentication.

Now, how to avoid your home surveillance system from being viewed by anyone in the world? Well there are several things you can do here, varying in terms of technical difficulty (non-exhaustive list).

  1. Password-protect all your connected devices, and remove anonymous access.
  2. Change the default password on all your connected devices. This will prevent that these devices can be accessed by anyone on the internet using default credentials, such as username and password both being “admin” or “demo”.
  3. Keep your camera software up to date. As with all electronic devices running software is the case, camera systems could contain bugs that allow unauthorized individuals to take control of and view your images. When bugs in cameras are identified, usually (unfortunately not always), the vendors release patches to fix these bugs.
  4. Connect wireless cameras to a secured wireless network. If you use wireless cameras, it is important to connect them to a secure (WPA2) wireless network. This will prevent anyone in the vicinity of your network to eavesdrop on and intercept the communication.

Last but not least, more and more vendors are allowing end users to connect their devices to the cloud and have them view the images through a secured online portal. Moving forward this looks to be a good solution for private homes as with this solution it is not needed to make your cameras internet accessible but in the same time you would be able to view your live feeds from anywhere. In this case, the security of the solution also depends on the security of the vendor cloud environment.

We are currently performing research on the security of home surveillance systems and will post updates on this soon, so stay tuned!

unnamed 2

Our team is researching common security errors in IoT devices as we speak

A word from our interns Aras, Gaetan and Wouter!

During the first half of 2017 we had the pleasure of working with three bright interns assisting us on various projects ranging from developing an interactive training platform to creating challenges for the Cyber Security Challenge to working on improving our own IT environment.

We asked them to let us know what they thought of their time spent here. Below is the feedback we received!

Interns_Q1_Q2_2017

Posing in front of our beloved blue bird with a great smile! 😊

Gaëtan:
During my internship at NVISO, I assisted the company into deploying and assessing new components in the IT environment. Due to NVISO’s sector of operation, a large emphasis was placed on the security of this environment both in the cloud and on the workstations used to access the services and resources. The aim of this migration was to provide a more unified set of services with increased productivity features while maintaining a strong, secure and controlled environment.

Overall it was a pleasure to work at NVISO during my internship. Working with such a dynamic team was a pleasure, and the overall ambiance and working with like-minded people was a delight.

Aras:
Personally I am proud on doing my internship at NVISO and also with his team that had respect, experience and fun.
During my internship I did two different projects:
1 – creation of the IoT village for the Cyber Security Challenge
2 – Working with open source information databases on connected devices, such as Shodan.

Thank you again guys to all great moment and your patience,

Wouter – Howest:
During my internship I worked on building the back end for an interactive training infrastructure. This infrastructure will help NVISO in improving its trainings, demonstrations and workshops. Building this infrastructure would not have been possible without the support of the NVISO team. I really enjoyed working at NVISO during my internship. The working atmosphere and colleagues are really top notch.

We would like to take this opportunity to thank you all for your commitment and enthusiasm you all brought into the workplace! Hope to see you again soon 🐀!

The entire NVISO team.

MoveBot: Battling inactivity one micro-exercise at a time

Many of our NVISO colleagues are very active during their free time. We have colleagues who go mountain-biking, rock climbing, swimming, running, … The problem is that during the day, they often sit at their desk for four hours straight, grab some lunch, and go back to their desk to sit and work at their computers. To make everyone just a little bit more active during the day, we created MoveBot.

MoveBot is a Slack bot that posts messages to our Slack channel twice a day. For example, just this morning, I got the following notification:

Screen Shot 2017-04-14 at 14.45.50

After having done the exercise, I clicked the “I did it” button, and MoveBot congratulated me:

Screen Shot 2017-04-14 at 14.47.20

Of course, a concept like this doesn’t work without some gamification, so every time someone completes an exercise, they get some points. At the end of the month, we give out a little prize to the most active members. You may think that this encourages cheating, but that’s why we had everyone sign a mock contract where they promise to try to live healthy and never ever ever lie to MoveBot ;).

We also use our MoveBot to do some team-building. For example, our set of “exercises” also includes “go get lunch for a colleague” or “during lunch, take a walk around the block with a colleague”.

Sharing is caring, so we’ve pushed the basic code behind our MoveBot to GitHub. Keep in mind that this was a quick project (and my first ever Flask/SQLAlchemy application) so the code isn’t that great, but it does what it’s supposed to do :).