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.