Insecure Binary Serialization: 2018 Redux

Back in 2018, I wrote about Insecure Binary Deserialization, and I'd like to give an update here for C# Advent. Originally, OWASP had just added Insecure Binary Deserialization to the OWASP Top 10, and while the problem was primarily in Java and older serialization libraries, there were still some .NET libraries that were vulnerable.  Well, no longer. Microsoft fixed the problem by deprecating the library in .NET 5.0, and here we will go over what we found in 2018, how Microsoft made the change, and what you need to do.

What is Serialization?

 At its most straightforward, serialization is the act of taking an in-memory object and encoding it as a string. There is a bit more to it than that, but it doesn't change anything in this article, so we won't get super detailed here. Encoding an in-memory object as a string does have a myriad of uses, though, from saving game state to passing objects from server to server with REST services in JSON.

Let's use game save files as an example It is possible to save a serialized file as serialized binary instead of serialized text, but this is it very difficult to send over the internet, either via service or through a web page. If the game is standalone on PC and doesn't have to report state to a server then binary format is fine - it will appear as hex in Windows and honestly be just as editable.  But, you got to do a lot more trial and error.

If the serialized object is text, then it is just a matter of decoding it, editing it, and saving it. It's pretty straightforward. Different frameworks use different methods, and sometimes different methods within the same framework use different methods.

Let's take a look at a quick example.

If I have a class like this:

public class SerializableClass
{
    public string StringProperty { get; set; }
    public int IntegerProperty { get; set; }
}

And I use BinaryFormatter.Serialize() to make a serialized object after setting some values, then save it as a file, I get this:

Pretty slick, eh?

How can Serialization be insecure?

 This file is unsigned, has no Message Authentication Code, and is not encrypted.

That's the quick answer.  The slow answer is that this file can be altered if you know what you are doing.  I covered that pretty well in my 2018 article, so I'll let it pass here and refer you there. That said, this means that any "binary" object (which looks like a bunch of gobbligook to an inexperienced developer) it editable by an attacker. For instance, I changed a word (I'll let you guess which one) and changed the data in the program on file load:

This is just one example in C# - there are a number of examples of serializers that can become a security concern, for exactly the same reason.  The thing is, there are a number of better classes that do the work properly. We just need to use them. So that leads to - what changed.

What changed?

 TLDR: They started deprecating the classes that provide insecure serialization.

The Deets:

In .NET 5.0, Microsoft has begun deprecating the classes that provide insecure serialization.  They started with the BinaryFormatter, and the pattern will gradually be used for all serialization methods. It's easy to say "Hey don't use these methods" but it is harder to follow up.  So, as part of the Long Term Obsoletion Plan, use of the BinaryFormatter will cause a warning in your build.  Eventually, over some time, that will become an error, and then in the fullness of time (h/t Don Box) the appropriate classes and methods will be removed. The goal, of course, is to simply have developers use more secure versions of the serialization classes.

So, for instance as seen at the early pre-release documentation at https://aka.ms/binaryformatter, the recommendation is to use JsonSerializer instead of BinaryFormatter.  If you use BinaryFormatter, you will get warnings today, errors tomorrow, and it will eventually break your build. Over time the other insecure methods and classes will be given the same treatment.

In ASP.NET 5.0, BinaryFormatter is disabled by default.  I recommend you do not override this, especially if you have a big project that uses serialization.  Junior programmers and contractors will use BinaryFormatter because it is the tool they know, and it can sneak into your project.  Blazor also disables BinaryFormatter by default.  This is good news, because web applications are the weakest link much of the time, storing serialized objects in cookies, headers, and hidden form fields to simplify communication. An attacker can deserialize those blobs, then steal secrets or change values. You must be on the watch, and default disable is a great way to help with that.

BinaryFormatter was the first but will hardly be the last serialization feature to be deprecated.  For instance, certain features of SecureString use serialization in an insecure way, and they are on their way out too.

What you need to do.

This is a fluid situation, so the best thing you can do is keep informed.  Subscribe to the Binary Formatter Security Guide.  As time passes, the updates will show there.  You can also get involved!  Two of the key folks involved in this are beer-drinking level friends of mine, and they assure me that the commitment to community involvement is as important if not more important to the security folks as it is to the rest of the developer community.  Write some stuff!

Upgrade to .NET 5.0 as soon as you can.  Then watch your warnings.  If your code base is clean enough, break the build on warnings.  Depending on your CICD situation, you might be able to only break on certain parts of code, which is awesome.  That way, you can take advantage of the changes they are making to the framework as it happens.

Search your codebase for BinaryFormatter and replace instances with format specific instances. For instance, use BinaryReader and BinaryWriter for XML and JSON. Also, if you are working with data objects, take a look at DataContractSerializer.  All of those classes validate inputs properly.

Avoid the SoapFormatter, LosFormatter, and ObjectStateFormatter completely.  Those use the old underlying structure, and are not secure.

Finally, consider if you need to use a serialized object at all. There are a lot of better ways to solve that problem. For instance, make an indirect object reference, save the information server side and give the client the reference ID.  That's better on all accounts.

Assume always that input is untrustworthy.  Consider your risk model and then ask yourself "if someone sent in malicious input here, what could happen?"  Dig deep.  You might be surprised what you learn about your code.

Application Security This Week for November 29

Three tools this week.  Pretty cool.

 

Check your S3 Buckets permission:

https://github.com/nccgroup/s3_objects_check

 

Information Disclosure research requires OSInt.  Take a look at IntelOwl:

https://github.com/intelowlproject/IntelOwl

 

I might have reported on this before - it isn't new.  It is a purposefully vulnerable Android app, for practice purposes:

https://github.com/satishpatnayak/AndroGoat

 

Hope everyone had a good and safe thanksgiving.

 

Application Security This Week for November 22

Troy Hunt has another one of his awesome data breach breakdowns.  Lots to be learned here.

Troy Hunt: Inside the Cit0Day Breach Collection

 

Awesome paper on unwanted app distribution on Android.

2010.10088.pdf (arxiv.org)

 

In the department of information disclosure department, we have a Go project that will look for URLs exposed by shortner services like bit.ly

utkusen/urlhunter: a recon tool that allows searching on URLs that are exposed via shortener services (github.com)

 

Have a great thanksgiving!

Application Security This Week for November 15

Portswigger has a really nice new release - update now! Community and pro.

https://portswigger.net/burp/releases/professional-community-2020-11

 

OWASP ZAP has a fantastic new plugin to help test SPAs and the like.

https://www.zaproxy.org/docs/desktop/addons/ajax-spider/options/

 

Everything old is new again.  DNS Cache Poisoning is back.

https://arstechnica.com/information-technology/2020/11/researchers-find-way-to-revive-kaminskys-2008-dns-cache-poisoning-attack/

 

That's the news!

Application Security This Week for November 8

Compass Security built a really nice Burp plugin that helps with the reporting of findings by copying the request and response pair from various tools.

https://blog.compass-security.com/2020/10/burp-extension-copy-request-response/

 

Container Security is all the rage.  Here is a good primer.

https://cloudberry.engineering/article/practical-introduction-container-security/

 

Random vulnerability names ... so hawt right now.

https://www.theregister.com/2020/11/03/cert_bug_names/

 

One of the Big 4 consulting/audit firms helpfully built a "test your Hacker IQ" quiz that exposes the DB username and password.

https://www.theregister.com/2020/11/05/deloitte_hacker_test/

 

I have written in this humble publication many times about my disdain over cryptic TLS vulnerabilities (pun intended) and now Let's Encrypt is going to cut off 30% of Android devices.

https://letsencrypt.org/2020/11/06/own-two-feet.html

 

That's the news, folks.

Application Security This Week for November 1

Not a lot going on this week.  Almost as if everyone has something else to think about.

 

Get your debugger on.  Good two parter on getting your feet wet with a little close-to-the-metal code.

https://www.moritz.systems/blog/how-debuggers-work-getting-and-setting-x86-registers-part-1/

 

For the bounty hunters - Harvard publicked a guide to the legal risk involved in bug hunting.

https://clinic.cyber.harvard.edu/2020/10/30/cyberlaw-clinic-and-eff-publish-guide-to-legal-risks-of-security-research/

 

Writing Go code? Here's a new fuzzer for your Go apps.

https://adalogics.com/blog/getting-started-with-go-fuzz

 

That's the news folks. Have a great week!

 

Application Security This Week for October 25

Microsoft has created the Adversarial ML Threat Matrix. If you are in Machine Learning, it is certainly worth a look.

https://www.microsoft.com/security/blog/2020/10/22/cyberattacks-against-machine-learning-systems-are-more-common-than-you-think/

 

Fuzzilli is a JS fuzzing library that allows you to write fuzzing patterns in a custom interpreted language to generate errors, find injection points, and do other useful things.

https://www.darknet.org.uk/2020/10/fuzzilli-javascript-engine-fuzzing-library/

 

Hijacking DNS is one of my biggest worries because it slips between the cracks of appsec and devops.

https://github.com/SuperFola/DoNotSend

 

FinalRecon is a recently updated web recon tool. I haven't tried it yet but I'm gonna.

https://github.com/thewhiteh4t/FinalRecon

 

Good writeup on the recent RCE bug patched in Discord.

https://mksben.l0.cm/2020/10/discord-desktop-rce.html?m=1

 

CORS is new (ish) and this is a great breakdown on hacking it from a knowledge perspective.

https://medium.com/bugbountywriteup/hacking-http-cors-from-inside-out-512cb125c528

 

Have a great week everyone.

Application Security This Week for October 18

Great explainer on using OWASP ZAP, instead of DotDotPwn, for directory traversal attacks.  I haven't used it yet but it looks really promising.

https://diegogiacomelli.com.br/owasp-zap-path-traversal-and-asp-dotnet-notes/

 

Wanna write Burp extensions? Me too! Here's some good tools.

https://github.com/doyensec/burpdeveltraining

 

Man, I'm doing a lot with Docker container security.  This is a good breakdown.

https://cloudberry.engineering/article/dockerfile-security-best-practices/

 

That's the news folks.  Hope you are all doing well.

 

Application Security This Week for October 11

Totally forgot to do this last week, sorry.

 

Telerik released Fiddler Everywhere

https://www.telerik.com/fiddler

 

Github has added code scanning

https://github.blog/2020-09-30-code-scanning-is-now-available/

 

Another example of what I am admittedly harping on too much - the power of HTTP Smuggling

https://medium.com/@ricardoiramar/the-powerful-http-request-smuggling-af208fafa142

 

Here's a cool intro to  manual static vulnerable analysis by Will Butler

https://btlr.dev/blog/how-to-find-vulnerabilities-in-code-bad-words

 

Some basics of securing APIs

https://dev.to/bearer/api-security-best-practices-3gjl

 

Have a good week, everyone!

Application Security This Week for September 27

A list of Capture The Flags that are on now or forever!

https://captf.com/practice-ctf/

 

The source code to XP was leaked.  This isn't a surprise, extended support gives folks access to it.  It was bound to get out.

https://thehackernews.com/2020/09/windows-xp-source-code.html

What's funny is the comments though:

https://pastebin.com/PTLeWhc2

 

The EFF is reporting on the very real problem of student contact tracing apps violating privacy considerations.  Balance has to be found.

https://www.eff.org/deeplinks/2020/09/students-are-pushing-back-against-proctoring-surveillance-apps

 

That's the news, folks.  Stay safe.

Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.

 

 

profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites

MonthList