A maintainer of the underlying runtime for Docker and Kubernetes) reported a vulnerability.
https://seclists.org/oss-sec/2019/q1/119
Here is a PoC codebase for the above. Well written too.
https://github.com/Frichetten/CVE-2019-5736-PoC
Hashcat can now crack any eight chatacter Windows password in two hours.
https://www.theregister.co.uk/2019/02/14/password_length/
Interested in Bug Bounties? Think they are all taken? Facebook CSRF finding nets $25,000.
https://ysamm.com/?p=185
And that's the news.
Ullaakut on Reddit posted this toolset: Gorsair, a tool to remotely access the exposed Docker API of vulnerable Docker containers. Works, too.
https://github.com/Ullaakut/Gorsair
Someone already pwned TLS 1.3, for crying out loud.
https://eprint.iacr.org/2018/1173
Cool attack on CORS configuration in mobile devices
https://research.digitalinterruption.com/2019/01/31/multiple-vulnerabilities-found-in-mobile-device-management-software/
RCE in Libreoffice. Not so free NOW areya?
https://insert-script.blogspot.com/2019/02/libreoffice-cve-2018-16858-remote-code.html
And that's the news. Stay warm.
Here's a thread by Michael Stanek about how bad 7-zip's encryption algorithm is. I use this all the time and had no idea.
https://threadreaderapp.com/thread/1087848040583626753.html
An exploit POC that Mark Haase wrote for the new SCP vulnerability.
https://gist.github.com/mehaase/63e45c17bdbbd59e8e68d02ec58f4ca2
Hadoop is the new target for a lot of malware. Please stop leaving your clusters vulnerable.
https://www.theregister.co.uk/2019/01/24/hadoop_malware_attack/
Chrome is turning off the API that UBlock Origin uses. Makes sense - Chrome is free, Google is an ad company. Whatcha gonna do?
https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/
While you're here, the Central Ohio Infosec Summit has their annual Call For Papers open. Submit!
https://www.infosecsummit.com/eSites/2019cbusinfosec/Homepage
And that's the news.
SplashData has their 100 worst passwords out again this year. Remember, at least, prevent these passwords in your signin flow.
https://www.prweb.com/releases/bad_password_habits_die_hard_shows_splashdata_s_8th_annual_worst_passwords_list/prweb15987071.htm
Really good breakdown of finding hidden files and directories and using them for information gathering on web applications.
https://medium.com/@_bl4de/hidden-directories-and-files-as-a-source-of-sensitive-information-about-web-application-84e5c534e5ad
Microsoft has come out with Windows Sandbox - might be a good platform for analyzing malware, but the jury is still out.
https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/Windows-Sandbox/ba-p/301849
Gah, bug in Ghostscript. Lots of vectors in the ImageMagik/PostScript space these days, watch yourselves.
https://www.rapid7.com/db/modules/exploit/multi/fileformat/ghostscript_failed_restore
And this is why I write up folks that have third party hosted JavaScript.
https://shkspr.mobi/blog/2018/11/major-sites-running-unauthenticated-javascript-on-their-payment-pages/
That's the news folks. Stay safe, and have a good holiday.
The OWASP Top 10 was updated last year, and there are a couple of new items. One of them is Insecure Binary Deserialization. Many of us use serialization in our applications, weather we know it or not, and through it sounds obscure it is a significant vulnerability. I talked about the bug on the Application Security Podcast earlier this year. In 2017, Paypal was hit by a serialization bug in their JBoss middleware because of an unpatched system. Several .NET projects were found to use the insecure BinarySerializer class in 2016 as well. It's a very real problem.
Let's take a quick tour of serialization, look at the ways it can be attacked, and what you should do about it, here as part of the C# Advent.
What the heck is serialization anyway?
Serialization is just saving the state of an object to a storable format. Encoding and character sets aside, it is usually the conversion of an object in a system to text, so that it can be written to disk in one way or another. Consider the ASP.NET Session object. To the developer, it is just a Collection of items, but once stored and sent, it becomes part of the ViewState hidden field.
Back in the day, if we canted to move an object over the wire we had to use a binary transfer protocol, like DCOM or CORBA. They stunk - they were hard to use and suffered from vendor lock-in. XML, and later JSON, were eventually made the standard for data serialization, but it still didn't give us a way to move good old objects around.
Serialization of objects had been around for a while (that's what CORBA does under the covers) but it wasn't really part of the languages we were using back in the 90s, but frameworks like the JDK and .NET changed all of that. Serialization became commonplace for transfer and storage of the state of an application, identity information, even just a generic object we wanted to persist for some reason.
In .NET, there are a number of serialization options. After marking an object [Serializable] one can use a member of the System.Runtime.Serialization namespace to render the object to a stable format.
For instance, here is a bit of demo code that serialized a simple class with two properties, and saves it to disk. Keep in mind, this is vulnerable code and should not be used in production!
SerializableClass sc = new SerializableClass();
sc.StringProperty = "Hello World!";
sc.IntegerProperty = 42;
BinaryFormatter fmt = new BinaryFormatter();
using (FileStream stm = File.OpenWrite(@"c:\temp\output.stm"))
{
fmt.Serialize(stm, sc);
}
If we take a look at output.stm in a text editor, we will see that it is, well, binary, as one would imagine.
However, this is just an encoding issue. If we load it up in UTF-8 we see that things get a lot more interesting.
How can something like that be insecure?
It's an injection vector, just like a querystring variable or a INPUT in a web form. An attacker can modify those values and submit them to the server.
"Wait," you are probably thinking, "doesn't the framework make sure it hasn't changed?"
Well, no. It doesn't, and therein lies the rub. The issue, in the case of C# and the .NET Framework, with the BinaryFormatter. When one deserializes the object, no checks at all take place - it is left in the hands of the developer. Since most folks don't know there is a problem, most folks don't confirm that the object is as they expect.
If the developer is depending on data in that object, then we have a real consideration. Bypassing some controls, an attacker might be able to discover SQL Injection, Directory Injection, or even Remote Code Execution commands on the operating system. But that's just where it starts. With no signature confirming that the object is as we left it, nothing is stopping an attacker from reverse engineering the object, writing their own application to deserialize it, and even change its functionality.
How does one fix this?
There are two main solutions to insecure deserialization. The first is to know your framework. BinarySerializer, the class I used in the example, is the only serialization class that remains vulnerable to this kinds of thing. As such, if you have to use it, don't store anything that is important in the class being serialized. Just like a cookie, right? You know the cookie is plain text on the user's computer, so you don't put anything sensitive in it. Right?
And I know this is a C# article, but other languages have this problem as well.In Java, the ObjectInputScream is vulnerable and it is the most commonly used serializer in the language, so watch for that. PHP doesn't have a secure serialization route at all - the unserialize method is the only way (so far as I know) to process a serialized object. The Ruby Marshal.load() method is designed insecure, and they even warn you of it in the documentation. This is not unlike the BinarySerializer - it lets you run with scissors so that you can solve certain hard-to-solve problems.
So what do you do if you have to use a vulnerable serializer? Panic. Not not really. Start to think in terms of a positive security model. If you are allowing something that has been outside the boundary of your system back into your system, you should only allow expected values and reject all others. This starts with type checking, of course, but can extend further than that. If you are expecting a ZipCode parameter to contain five digits, then anything other than that should set off alarm bells. Input validation is your friend here.
Alright, what if I ignore this whole thing and hope it goes away?
In C#land, the BinarySerializer can only be used to store properties, not methods. Therefore, actual code injection is practically impossible. If the data is such that you don't care if the user edits it (say, a local only game state file) then ignoring the problem might not cause you any really large scale problems.
However, if you are storing anything that is used in the running of the program, especially in network connected or web applications, then you have to be very careful of possible side effects. Just like any other input, if you allow the user to change it outside the bounds of your user interface to are begging for problems. Say you store the contents of the shopping cart in a serialized object. Can the user change the quantity ordered to a -1? Would that give them a discount?
At the very least testing of any serialized objects should be part of your vulnerability assessment plan. Any time data crosses the boundary of your application, check it!
A vulnerability was discovered in CSS (!) that will crash your browser. Please don't do this at work.
https://cras.sh/
There is a new fuzzing list out there that I like a lot for searching for hidden files and directories.
https://github.com/Bo0oM/fuzz.txt
The security incident of the week: Marriott lost half a billion customer records, including passport numbers.
https://answers.kroll.com/
And that's the news!