So, hey, yeah, how are all of you.  Clearly SolarWinds has completely overwhelmed the news this week, so I have a couple of notes about that. To those of you who are having to deal with this, I am with you in spirit. Doing what I can here from The Bunker to help you out.

Here was my first indication there was a problem, I believe.  It's pretty old news now.

https://thehackernews.com/2020/12/new-evidence-suggests-solarwinds.html

I spoke about Supply Chain problems at the Central Ohio .NET Developer's group in March.  Oddly timed.

https://www.youtube.com/watch?v=KWt0Brcc2Ag

MicroSolved has a good writeup you should read.

https://media.microsolved.com/SolarWindsBrief.pdf

This is Microsoft's breakdown on DLL Injection.  For the record, I attended a BoF session on this at DefCon 15(!) and everyone I talked to blew it off.  Guess not.

https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

Some other news, thank goodness.

Github is gonna ban passwords.

https://www.theregister.com/2020/12/17/github_bans_passwords/

The NSA finally figured out that authentication systems are under attack.

https://www.nsa.gov/News-Features/Feature-Stories/Article-View/Article/2451159/nsa-cybersecurity-advisory-malicious-actors-abuse-authentication-mechanisms-to/

And finally, a short article about memcpy. 

https://r2c.dev/blog/2020/when-devsecops-goes-wrong-a-short-lesson-from-huaweis-source-code/

That's the news, folks, have a great holiday and end-of-year. May your systems be secure and your code be frozen.

There is a potential new addition to DNS security, which is sorely needed.

https://blog.cloudflare.com/oblivious-dns/

A good writeup on discovery of a Facebook vulnerability.

https://alaa0x2.medium.com/how-i-hacked-facebook-part-one-282bbb125a5d

I am not in favor of brigading FireEye, and if you are I'll fight you.  That said, the analysis of the stolen tools is very enlightening.

https://www.picussecurity.com/resource/blog/techniques-tactics-procedures-utilized-by-fireeye-red-team-tools

That's the news, folks.  Stay safe.

Once a week or so, someone calls and asks for OWASP Top 10 testing.  I have to make the call on the spot weather or not to explain that isn't what they want, or say "Sure!" and then give them actually what they need, or have a larger scale meeting to see where their appsec maturity is, and base training on that.  Usually it is the third.

The problem is, app security is hard to teach, and frankly many shops need secure coding training, which is even harder.  Let's break down why that is the case.

OWASP Training yes, OWASP Top 10 training, no

 OWASP is a great organization.  For those unfamiliar, it is a global nonprofit with the mission of evangelizing application security to developers.  It has it's political problems sure, but in general it solves a very hard problem with grace and clarity.

One of the most famous products to come out of OWASP is the Top 10.  This list is the most risky vulnerabilities discovered by member organizations, ranked.  It is a useful.  Useful for printing out, rolling up, and smacking your CIO with until you get a security budget. 

The OWASP Top 10 is not an application security plan.  It is also not a training curriculum.  It is a marketing vehicle, and a remarkably effective one. Use it for that and you are golden.  Try and do an OWASP Top 10 training, and you are performing a disservice.

This discussion doesn't go over well with most.  Everyone wants a magic bullet for application security, but there just isn't one.

Sorry.

The plan is simply to do three things:

1) Teach the developers to recognize security flaws.

2) Teach the developers to repair the security flaws.

3) Give the developers tools to prevent security flaws from ever making it in the code.

Let's count 'em down.

When you need to learn how to test apps

 Let's be straight here.  The only way to make applications more secure is to code them securely.  Okay pokey? Good, that's settled.

Now.  There are a few things that need to happen first, and therein lies the rub.  CIOs and Dev Leads want to drop a process in place that will secure their code.  Then I stop by, put '; in their website search field, blow the whole thing up, and get the O face from the team. First, we need to show developers what the attacks are, and how to check for them.

The issue among the high level development security instructors is that they are so far along in their personal skill set that they wanna talk about indepth output encoding for style sheets, without realizing that many developers are still wondering what the other site is in Cross-Site Scripting anyway? I get it. I do.  But we gotta judge that audience, and it's rough. Average 40 person dev team you are gonna have 7-8 people that already know the basics, but not well enough to teach the other thirty-odd.  We need to start there.

Security champions - I love you all very much. Take a look at your dev teams. Close your eyes.  Take a deep breath.  Open your eyes.  Does everyone in there understand JWT risks? Does your organization remove dev names in comments? If not, you need to run an application security testing class.  No, you don't have to have everyone be an uber-hacker. But it is fun, and it does give everyone a starting point.

When you look at code in code review, ask what input validation is being done. Ask about how that viewstate is encoded.  If you get a glassy eyed stare, then consider a class on testing.

When you need to learn how to write secure code

 Once folks can recognize insecure code, it is time to start fixing things. Sounds far, far easier than it actually is. However, this is when we need to start getting the development staff into the process of building security into their everyday process.

My experience is that you need to do a few things.  First, static analysis.  It isn't perfect, but it is a start.  Static analysis is the process of analyzing the code to best determine the potential security flaws. Dynamic analysis is the act of looking at the flaws in a running application. Either can be automated - meaning a script does the work - or manual - meaning a human does the work.  Automatic static analysis, say with a tool like SonarQube, is very likely to generate a ton of false positives at the start, but the rules can be honed over time. It is an imperfect but fairly effective tool.

Another important tool that should be used is a secure coding standard.  This is a custom built document not unlike a style guide.  It is something you can hand to new devs and say "this is how we do things."  Now, this leads well into the next section, about language agnostic testing and training, because the secure coding document should be tailored to the platform used by your organization. 

Testing is language agnostic, but secure coding isn't

The issue, as one discovers writing a secure coding standard, is that testing is very platform agnostic, but writing more secure code is not.  From a tester perspective, I can say "you need to encode your outputs" but from the developer perspective, there is a different way for every language and platform.  Html.Encode()? Sanitize()? Different everywhere, and a few frameworks do the work for you.  

When the report is written, there should be remediation advice, and it should have detailed guidance.  However, that means the tester should have detailed information about the language and platform and framework used to build the tested application.  This is extremely unlikely.   

When trying to teach generally, there needs to generally be an expertise in the language, platform, and framework.  Now, some folks know several languages, platforms, and frameworks,, if they have been around a while.  I for instance know C# and ASP.NET on Windows, Java and JSP on Apache, and Python with various frameworks quite well. Others less so.  But I have been doing this a long, long time.  Teaching secure coding in Ruby on Rails requires a specialty in appsec, AND Ruby.  That's not an everyday set of skills.

So what are we gonna do?

 Whatcha gonna do?  It's not the easiest problems to solve. I have a system that I would like to share, though.

First, have someone give a security talk at your company.  Usually, I do a lunch and learn or something, obviously online these days. Go over the vaunted OWASP Top 10, or give a demo of Burp or ZAP. Heck, click F12 and see what you see. I usually invite developers, business analysts, and testers (quality assurance, whatever your term is). Some people will nap through it, some will stay after to ask questions.  Those people that stayed after might very well be your security champions.  

OK, so now we know who is interested.  Second, we do training on testing. Have the security champions help to collect together the folks they think are important to understand what the vulnerabilities are, and hold a real training - one or two days, with labs - on application security testing.  This gets the core group of people the information they need about vulnerabilities to look for.  In the labs, have them look for them.  In their own code.  Encourage folks to test their own dev instances.  Dig in.

Third, retrospective.  Get the champions back together.  What did we learn?  How can we do better?  Most important, what are the secure coding principles that must be taught?  This is where we solve the language agnostic issue.  You can't just call someone in to teach secure coding, you must learn what it means to you and your team and your company.

Fourth, write a secure coding standard. It should be based on the lessons from the retrospective.  Base it on the categories of vulnerabilities, but couched in developer terms.  I use:

1. Security Principles
2. Access Control
3. Content Management
4. Browser Interaction
5. Exception Management
6. Cryptography
7. System Configuration

But your mileage may vary.  The goal is to build a guide you can give someone on their first day.  Say "We write secure code here.  This is how it is expected to be done."  Think that through.  Usually my documents are 12 pages or less.

Finally, you train the secure coding standard.  Now you know what needs to be trained.  Yes, you have to write the materials, but they can be reused.  It can be as long or as short as you like but you get everyone back together and teach.  Then, as new people join the team, you have the culture in place to hand them the document.

Next, if you want to, you start to enforce the standard with a static analysis process.  That, however, is for another post.

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.