An astonishingly well-written article by Google Project Zero on a vulnerability in iPhone's proximity features.
https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html?m=1
For something totally different, a tool that de-pixelizes values in images.
https://github.com/beurtschipper/Depix
Another fuzzer, ostensibly for debugging, but you know how that goes.
https://opensource.googleblog.com/2020/12/announcing-atheris-python-fuzzer.html
Fortinet has a good writeup of some info disclosure problems with current browsers.
https://www.fortinet.com/blog/threat-research/leaking-browser-url-protocol-handlers
That's the news! Have a fantastic week.
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.
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.
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!
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.
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!
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.
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.
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!