Microservices == Microhell

Microservices, a word that has been buzzing around a lot, every one is writting, speaking and developing under the microservices mindset, but it is never that simple, just splitting a service into small pieces and having them interacting over the wire can cause a great mess.

Not having a good planning on how the service will interact, can cause an auto DDoS, because all the services are too chattie and then overload the network, so essentially, you performed an DDoS attack just by trying to run your system, congratulations.

So, what to do?
Now that the naive solution (http) is discarted, how can you interact in a system where everything is logically separeted? Many solutions have evolved throught out the years, one of the best solutions, specially if you need one way communication, is using a queue service, where messages can be posted and they can be received from the other end of the queue to be proccessed.

RPCs (Remote Procedure Calls), this method of executing actions is sometimes slow, depending on the level of concistency been used, two-phase commit is very costly but is very effective.

During the 80's and 90's, a paper was show, called SAGAS, which described long running transaccions on databases, and how to utilize them to make long queries work efficently, now it had evolved into Distributed SAGAS, a pattern where each microservice is a task, and a sequence of tasks is transaccional, so when an update occurs, every service that needs to be updated will receive the info. Also I really like the idea of a "pipeline" for this kind of situations, for example, maybe a reservation site allows you to book a flight, pay your hotel and rent a car on the same website, at the same time, so then, based on your task priorities, the SAGAS can be reorganized to make the most important task first, for instance, booking a fligth, because without a fligth, no trip can be made, so is cheaper to wait for the fligth booking service to answer, than to book a hotel and then cancel it.

Conclusion
I really like the last approach, having a way to think about the problem is great, and having the freedom to implement it as you wish is also a good idea, but it can be really bad, because not just one, any one can do what they pleased to do with your service, and our job is to prevent that from happening.

Azure Sphere

Great news came last month, Microsoft launches it's first non-NT based OS, it is an Linux based OS for MCUs (microcontrollers), the great thing here, they claim to have a solution for the security problem on IoT, they claim to have the most secure OS for MCUs, we all remember that dark day when the "full" internet was down, because a botnet took down one of the main DNS service providers in the USA, it was a hard punch to the IoT movement but also was an oportunity to really make a deep dive into the security issues of IoT.

What they claim
Microsoft published a great post providing a great overview on the product, but lets just review it.

The certified MCUs are, as they state, secure from the silicon, that means that security is the first thougth when building one of this MCUs, but how efficient and cost-value effective are them? well, we don't know, the first one is about to lauch but no price has been said.

Azure Sphere OS: it is a OS that is built for security and agility, thats what they have said, but I haven't found any security test results on the web.

Azure Sphere Security Services: this are cloud services built to provide an upper layer of security to the MCUs and also a layer to push updates of the firmware and user software that will run on the MCU.

My concerns
Well, we know that they love to charge for everything, and also if the services are bound to Azure, then maybe that could be a barrier that is hard to tackle, because not everyone likes Azure, every one have their issues with any cloud provider.


My conclusions
I really like to see this kind of things, companies making new technology to tackle some big problems, and also Catie McCaffrey is envolved on the development of this platform, and the research papers are free and open to read, so I think they have some of the best minds into this, but still, they claim a lot and they haven't shown it running, expectations are high for them.

Never hard code Connection strings

A common practice during development is to just hard code every connection string that is been used on the project, but why is this a bad, and I mean a really bad practice?

Let's see what outputs the C# compiler for hard-coded strings:

As we can see, the line marked as IL_0001 is where the sintrg is been loaded to a variable, it is just written there, with out any consideration, imagine if someone gets access to your binaries, then they can just decompile them and read any sensitive string that was just hard-coded inside the program.

How to store them.

Many aproches can be used, maybe using encrypted files to store those keys, but also that can be cracked, or maybe using environment variables that store the encrypted strings, but again, it can be cracked. So, we cannot trust anybody, we need to be completly away from any kind of machine to be completly safe, but we can trust one institution, and when running on a cloud platform this is important, all cloud providers have their safe way to store this things Azure has Key Vault, Amazon has Systems Manager Parameter Store and Google has 

ObjectAccessControls, all of them have their own capabilities and ways to charge you for those services.

Now, you maybe asking, why would I trust any of this companies to save my important stuff? You don´t have to, but they are certified by some external authorities, so at least you have a way to berify their security.

Additionaly you must be carefull when pushing a commit to an open repository, it is way to easy to find connection strings on Github, I personally use an extension on my IDE that can be configured to produce compiler errors if a connection string is hard-coded, I only have it configured to produce warnings, because compiler errors are a bit more frustrating. It also handles other things of the dev/ops pipeline, but the connection string checker is the feature I use the most.

Elevation of privilege

Elevation of privilege or privilege escalation is a group of attacks, where the attacker gets can perform an action that he originally didn't had permission to do by exploting a bug, a design flaw or a oversight configuration [Wikipedia].

"So, if I 'accidentally' opened a file that was on the folder of an administrator, then I had performed that kind of attack?" Actually, yes, if you were supposed to don't have access to that file.

Now, lets talk about Windows, it is not a surprise that Windows is one of the most attacked OS, so a lot of vurnerabilities had been found and patched but there is also that weird config under the system that is made to keep you safe but comes unsafe by default. One of those configurations is the one that allows any system to install with all privileges, even adding new users and making them part of the administrator group, so as you can imagine, full access for that user on the system.

A great repository to test your settings is the one from PowerShellMafia, the repository is PowerSploit, please note, this scripts are meant for testing, any other use maybe considered illegal. Also, it is important to note that at least Windows Defender blocks all this scripts as trojans, in fact, they are trojans but in good hands, any weapon can be used for good.

To check this attack been used you can watch the video from the YouTube channel Security World, he makes a really good explanation about the attack, and what I find interesting about this particular aproach is that it is creating a MSI installer that creates a new user with admin privileges, and then your imagination can fly, you can open anything, activate remote desktop, anything. Now with admin access (or root for the linux people), the posibilities are endless.


Futher readings
Windows Privilege Escalation Fundamentals - Great tutorial on how to check your own machine.
Linux Privilege Escalation Scripts - Because Linux is not safe from this attacks.
Mac OS X Issue - And not even Apple.

Evitar filtración de información en Facebook

El caso de Facebook con Cambridge Analytica ha sido muy sonado en redes sociales y medios de comunicación en general. Se sabe que aproximadamente 270 mil usuarios de Facebook le dieron acceso consiente a la aplicación que se utilizó para minar datos de los próximos votantes de EUA, pero también se sabe que no solo se hicieron perfiles de esos usuarios, se hicieron perfiles de 87 mil millones de usuarios, esto por una característica de la API de Facebook, que permitía obtener la información de los amigos del usuario que aceptara los términos de la aplicación, por lo que ahora no solo se tenía la información de aquellos que conscientemente aceptaron, si no de todos los que no sabían de la existencia de esta característica.

Ahora, en cuanto supe de porque había sido el filtrado de tanta información me di a la tarea de desactivar esa característica para mi usuario. Aquí dejo una guía paso a paso.

Primero nos vamos a la pagina de configuración de Facebook.

Después, en la barra de la izquierda seleccionamos "Aplicaciones y sitios web".

Ahora, en el panel hasta abajo de la pagina, tenemos cuatro opciones, en el recuadro de la esquina inferior derecha está la característica que buscamos desactivar... o estaba, porque como podemos ver ya no existe y está marcada como obsoleta.

 

Después de un poco de investigación, podemos ver en este reporte que Facebook deprecó múltiples campos en bastantes endpoint para evitar lo que ya les sucedió con Cambridge Analytica, así que nos podemos sentir un poco mas "tranquilos" de que al menos, ahora nuestros amigos no van a poder filtrar nuestra información.

Upgrade your dependencies!

I recently revisited and old repository on my public GitHub, and I was impressed on how good is the platform, as soon as I was on the repository, I was checking I was received by a big yellow banner alerting me on a dependency vulnerability.

One of my JS dependencies is vulnerable! but when I checked the vulnerable dependency, I was surprised by how the vulnerability is really hitting me.

It is a dependency of one of my dependencies, and then I just started wondering, how may other packages or systems can be affected by things like this! It is not just a dependency, it is a dependency I trusted because I trusted on Chart.js.

Now, ASP.NET Core is one framework I use a lot, and .NET Core is the runtime on which it runs, since it is now open source, I decided to take a look at their announcement repository, just to know if they have something where they tell everyone about a known security issue. To my surprise, they do have a tag of security, and they are continuously updating it, on the .NET repository as well in the ASP.NET repository.




So, now lets take a look at one of those issues, Elevation of Privilege is a common attack on windows systems, so having those kind of problems on a server in a cloud platform seems like a bad idea, lets take a look at the most recent Issue. And to my surprise, it is very well documented, it has all the necessary info about which software is affected and how to be safe, which versions of the runtime or packages are already patched so you can update to those ones.

Conclusion
As maintainers of our own services, we should be aware of this kind of things, not just your OS should be always up-to-date, but your runtime and dependencies, even if they are not direct dependencies, every one of us should be aware of what kind of problems can come from not having those type of cautions.

PS. I'm now watching both announcement repositories and I'll eventually get into my repository to correct and update everything, even though it is not a running system, it should be updated just in case someone eventually wants to use it.

Public Wi-Fi networks

I love visiting different places to eat, like restaurants or small business that serve great food, and beer. As part of my weekly visit to one of those places, I found that their Wi-Fi router was vulnerable to one of the most common and easy attacks, getting into the administrative panel and do what ever you want, because the password was the default!

The process
First, I got the Wi-Fi password, which was cleverly written on a whiteboard on the wall in front of me. After login in, I just checked which was my default gateway and proceed to enter the address in my browser. And I got this page:



Then I did what any person with minimum search skills could do, just searched for the default login password and username for that specific modem, which was cleverly publish on this website.

I entered those default username and password and boom! I was in, just got access to the full administrative panel of a place where they have a computer for accepting payments, where Rappi or Uber eats can place orders, and also where they use a terminal to make charges to credit and debit cards.

After that I immediately told my waiter that I needed to talk to the manager, then he showed up and I explained to him what I did, and how easy it is to find those kind of things, he completely understood the problem and fixed it by the next day with some help, and he offered me a beer for the finding, so everyone was happy at the end of the day.

Conclusion
This wasn't my first experience with a problem like this, and I also tried to reach some managers from other places with this problem, some of them seems to not be so aware of the problem it is, but this was my first experience where I was able to help someone. As one of my colleagues states in one of his blog posts, the default is usually unsafe, and even when the administrative panel of this particular router was shouting in a red color that the passwords were the default once you logged in to the device, it  never forced me to change the password once I was in, I think that this kind of things can be better done by enforcing security, but also the people must be aware of what it means to have a router in their homes, when the company staff installs the router, I think they should tell a bit about those kind of settings and the danger of leaving it as is.