Episode Transcript

GUY NADIVI: Hello everyone. And welcome to episode eight of our series called Software Package Deconstruction, how to assess risks to your software supply chain. Each episode, we deconstruct a software package or two and do a deep dive into its risk profile to better understand its unique attack vector. And we hope that in some small way, we can enable your security team to stay one step ahead of malicious actors.

Next slide. Let's start with a little housekeeping. If you have any questions or comments, please submit them through the Q&A feature on Zoom webinar. We are recording this episode for those who cannot attend live, and you'll be able to find it on our website's media pages shortly after the conclusion of today's webinar.

After the webinar, we'll also be sending out a follow up email to all registrants with any relevant links we think you might find useful, as well as a link to the aforementioned recording. And finally, if you like subtitles, click the live transcript button to enable Zoom's closed captioning feature.

Next slide, please. For those of you who might be wondering, who is ReversingLabs? Let me tell you, we are all about protecting organizations from increasingly sophisticated cyber threats. At ReversingLabs, we leverage the world's largest threat intelligence repository to protect software development and power advanced security solutions.

Our threat intelligence repository is seven times bigger than VirusTotal's, and it keeps the most advanced cybersecurity organizations and fortune 500 enterprises informed and in front of malicious actors. Our software supply chain security and threat intelligence solutions have become essential tools for advancing enterprise cybersecurity maturity globally. ReversingLabs operations are spread throughout the U.S. and Europe with offices in Zagreb, Croatia and Cambridge, Massachusetts. And our customers are in just about every corner of the globe. We've got just under 300 employees and we're looking to hire more. So if you or someone you know is in the market for a new opportunity, please check out our careers page to view our current openings.

Next slide. All right. The man who will be deconstructing these software packages for you is Tim Stahl, a seasoned security professional who boasts almost 20 years of experience in information security, with additional experience in information technology related to both the engineering and administration of enterprise networks.

Tim has secured and defended networks across .mil, .gov, and .com enterprise domains, and his expertise includes the tracking of both APT and criminal groups, threat intelligence, threat hunting, data analysis, OSINT research, DevOps, and SIEM engineering. Next slide. The subject of today's software package deconstruction is OneDrive and Dropbox, two cloud storage apps everyone is certainly familiar with.

OneDrive and Dropbox do similar things, but do they behave in similar ways? From a third party risk management perspective, does one present more risk than the other? In this episode, we're going to do a deep dive and review these two popular cloud storage apps from a TPRM perspective with a focus on the software attack surface, communications and other relevant information to evaluate each option. Before we dive in though.

Let's do a quick poll. I'm going to pop that up on the screen. And hopefully you all see the poll question there, which is, Which do you think is more secure, OneDrive or Dropbox? Please take a moment to answer that, and then we will compare these results to our findings at the end of the webinar. Which do you think is more secure, OneDrive or Dropbox?

Okay, looks like everybody responded pretty quickly, and there's enough is an overwhelming result. Looks like it's almost unanimous for OneDrive. Very impressive. Okay let's keep that in mind. The crowd favorite is OneDrive. And then we'll see how that compares to the results that we found based on Tim's analysis.

Okay, next slide, please.

The tool that we're going to be using to analyze OneDrive and Dropbox is the Software Supply Chain Security platform from ReversingLabs. The SSCS platform decomposes the final deployment software image, describes its underlying software behaviors to determine deployment risks, and when it finds a red flag, it prioritizes remediation guidance.

SSCS is powered by the world's largest private file reputation repository with over 10 billion files and about four and a half million new files, added daily. It not only helps prevent threats from reaching production, but can also find exposed secrets before release. As a bonus, it can also generate a complete SBOM.

And with that, let's turn it over to Tim to begin his deconstruction.

TIM STAHL: Welcome everyone. Thanks for joining us. Like you mentioned we're going to talk about risk assessment from a TPRM perspective . This is a learning series. We're going to talk about different ways to do this. This is a lot of new to folks.

This type of analysis, this data set is newly available. As supply chain gets, more has more weight applied to it and more people take it more seriously, the tools are getting up upgraded and you're getting a lot more access before, all software applications were a black box.

You never knew what was going on inside. You could maybe do vulnerability scanning against that application once it was installed. Your EDR may monitor stuff and may catch some behaviors. Deep visibility should be part of your supply chain risk assessments. So these are some of the elements we're going to look at here.

Size and composition, how many different software components are in this package? How many of them make up of that? How many of those are third party elements? How many of those are aging out? How many vulnerabilities are part of this? What is it doing on the network? What is it communicating with?

What protocols does it speak? What's going on in the background, or what could be going on in the background? Same with behaviors. What is this application capable of doing? Is it just providing the service that it says? Or is there a lot more going on in the background? How much data collection is going on with these devices?

How many files are doing that data collection? How many vendors files? You may see the same type of collection across multiple vendor files. You don't know where that data is going to end up. These are all things you got to be aware of. And, without this level of visibility, you're basically guessing when you do your software assessments.

File rot is something we talked about in a previous episode. That's aging files that normally don't get updated over time. And then just as they age year after year, they never get touched and they pick up more CVEs, they pick up more issues. And as development best practices advance, that's still a snapshot in time.

So those files that are six, seven, eight years old that are still part of your package, they're going to start having missing mitigations and missing elements that are as best practices advance, those things won't be in those older files. So as they age, they get worse and worse, and that becomes a long term risk that just grows.

We'll look at third party components. Obviously, the results of the scan itself and part of this assessment or part of a risk assessment for software should also include your risk assessment of the vendor itself. What does their build quality look like? What is their maturity? You can tell from the detections in our tool and other tools what tools they're running.

Are you catching things when you do your assessment of the software that slip through the vendors? That means that there's a higher likelihood that'll keep happening. You can do other things and we're going to do a full episode just on gauging vendor maturity.

So we'll go to the reports. So this is our application, and this is the report run on Dropbox, the latest version. Same thing with OneDrive, we'll pull down the latest version. So you can see this failed our test. Now, as we've talked about in the past, when you're doing third party risk assessments,

the things you want to look at, the policies you want to have in place, the rules, the alerts that are fired, those things differ from software consumers versus software producers. There's a lot more that's applicable to producers that, as a consumer, you wouldn't care about. So this policy set is based on that.

This is designed around the TPRM use case. So I've just prioritized the things that are necessary for me to do this assessment on our software. So it cuts out a lot of the noise and focuses you on just the things that matter. So we do have a failure here. And on top of that, we noticed this is a relatively small file, less than a meg.

For modern software, that's tiny. There aren't that many issues if we look at the overall view the risks involved. So it's a small application. There's only 24 components, so it's not a very complex application either. We see a lot of bloat with software, and we'll see that in these examples here, but more and more you're seeing applications that don't want to just do a thing, that they want to be part of this package play or this platform play, where that service or that application is just part of a wider thing.

So there's going to be a lot of bloat in there trying to pull you to other services or tie into other services. And we'll see that with the Microsoft version here. But that is part of your risk, right? Is how is, what does your attack service look like for a piece of software? If you're comparing multiple versions for purchase, these are the kind of things you want to look at.

So it's not a very big file. It's not very complex either, which is good. We'll look at the bill of materials here and let's see where all these components come from. There's 24 components who built them. Oh, it's either Dropbox or an unknown publisher. And if we look at the elements, we see a consistent pattern.

They're all related to this. Now looking at another tool, it shows us that these are Google files. So these are all Google components. So the only thing inside this package are Dropbox elements and Google third party components. So smaller attack surface, lower complexity. If we look at the issues, we'll see why this failed and it failed due to a digital signature issue.

So if we look at what that is, digital signature is only partially validated. So what this is a tampering detection. When you sign a file, it has a hash assigned to it. Part of that signing is to say this hash should be the hash that you get when you accept this file, when you install this file here. Here, that's broken.

So something was added to this package after it was signed. Now there are weird corner cases where that's a legitimate thing or some companies do that on purpose for certain reasons It's not a best practice. So here I would take it very seriously. So this is a new version and I'm checking this version before it goes out and this popped up, I wouldn't install this version.

So there's no way to tell without deeper digging and going into a sandbox and some other things to find out what may have happened or contacting the vendor. So this is, could be a significant issue, but again, if this is your application, you're testing it every version before you release, this may be something that just happens with every single time.

So you need that sort of context to understand the severity of this, but this is a significant finding here. So let's move on, but there's nothing else here. There's no malware. There's zero vulnerabilities, which is, this is the first package I've ever seen with nothing that has a vulnerability in it.

That's amazing. There's some missing security mitigations. Which would happen all the time. And this isn't even a, really a high severity issue, right? So there's CFG is an older memory related element, but here there's some files, if we look at the files, it looks like a lot of them. So the Google or the Dropbox installer has that issue.

And then some of the Google ones too. Not a critical issue, but this is part of that assessing the vendor their build quality and that framework. That's what we'll talk about. And there's also some sensitive information. So we see there's an embedded key again, these, the embedded keys happen a lot and we see them very often.

And there's the whole thing is a key. So this whole file is just a private key. Something to ask the vendor about and look into. But again, over time, if you see the same things over time, then it's not so bad, right? If it all of a sudden pops up, then take it more seriously. So we have really nothing to look at for vulnerabilities, signatures are all in line, it's signed by DigiCert, which is good,

we'll see that later, and it's still valid. So now we'll go into the behaviors and network. And this is, these are the, some of those new elements that we've talked about that you have access to now that you never did before. And this should be a core element of any software application testing and risk assessments.

So there's only 35 behaviors. Again, like we said, it's a small package. It's not very complex. So let's just take a look at all of them, all 35. And if we skim through here real quick, we'll see a lot of common stuff. Anti debugging is in every package it's not a big deal. There's some system enumeration.

You expect that it has to know, right? This is a Dropbox. This is file system. So it has to know the file system stuff. There's going to be some low level elements that it hits for the OS, right? So there's a couple of OS related DLLs that it accesses. That's fine. It needs to access the file system. It needs to be able to transfer files.

So that's expected. Enumerates account privilege that can be related to the file permissions. So as you skim through here, controls a service while it actually is a service. So that's not unexpected. And it does some collection, but it's simple stuff, computer name, right? There's some VM detections, but only a couple.

This is likely just means that there may be a configuration issue when it detects it runs in Sunbelt, maybe there's a config thing that has to adjust for that application. We do see some things that won't run on any VM and then you'll see, eight different types of VMware detections plus VM related components and behaviors.

So here we just see these two. Not concerning at all. Downloads a file, obviously that's part of the core capability here. So it does some, you know, OS related stuff, but it's all relevant. Take screenshots. You'd be surprised how often you see this in applications. I don't really even take notice of it anymore.

It's just weird, but it happens all the time. So what are you going to do? So we look through all these behaviors and it aligns with what I would expect from an application built to do this kind of stuff, it's just cloud storage, right? File system on the cloud file system on your computer. This makes it look like they're all one thing.

So there's nothing out of bounds here. There's nothing that looks odd or stands out, which is great. And normally there are larger packages and there are more behaviors. It takes, it's not this easy every time. So we'll go to networking as well. So far, we went through the issues. There's one significant issue that there would be something that we go back to the vendor with that tampering issue, but there's no behaviors that don't look right.

There's nothing odd. It's not doing a lot of stuff that you can't explain. So let's go to the networking tab and let's see what it can do.

So we'll look for strings that begin with HTTP. We'll look at all of them, and we'll see what this application communicates with, or is able to communicate with. These are all strings that are held inside these, the components, the software components. So obviously Dropbox is a big thing. DigiCert, that's digital signing certificate management.

So we see a lot of that in here, which is good. More, so as long as it's related to the service, again, it meets expectations. OCSP is about certificate validation, making sure they're valid. That's great. We'd like to see that. So all these components are good, right? That means that they're taking their security seriously.

They want to check these, make sure everything is signed and the ones that are signed have valid certificates. That's great. We'd like to see that. So overall, Dropbox looks pretty good. There's not a lot of issues except for that tampering thing. There's not a lot of complexity and there's not a lot of hidden behaviors or issues that don't look right.

Or you can't be explained by the services that this application is supposed to provide. So overall, this is a really good application. This is what we like to see. It's streamlined and it's efficient and it's purpose built. The counterpoint to that will be OneDrive, much larger file, 59 megs. So this is 60 some times larger than Dropbox.

Microsoft is famous for bloat, we expect to see this. There's some vulnerability issues and there's more issues here in this report than we saw in the Dropbox. Part of that is related to this. It's a larger file, and it's a much more complex file. 242 different software components inside this.

So we look at the Bill of Materials, and let's look at the Publishers. Let's see who's published software. So we have some React, a lot of different Microsoft. This is actually Russian from Microsoft Corporation. Which is fine. So there's only a couple of third party elements, OpenSSL and Qt company, which I'm not familiar with, but they have multiple components in here, but that gives you a sense of what makes up this package and how we can see where some of these issues lie.

So we saw that one publisher that was Qt company. This is theirs. This is their product. There's the version, and this has CVEs related to it and also has some high priority issues. And we see that they're related to actively exported vulnerabilities, or just critical severity. So the failure here is related to vulnerabilities, whereas the failure for Dropbox was that tampering element.

These are all things you want to wait and make part of your evaluation. And, you wait these however you want and score these however you want. But this is generally the process and we'll keep it high level and we'll go through it pretty quickly. But it's a easy, repeatable process. So you fail because of known vulnerabilities.

There's also some sensitive information. This is hard to decipher. The risk related to these things because Microsoft does this a lot. So let's look where those keys are found. And they're in DLLs, so we can see the DLL name, again, other DLLs. So there are four different DLLs, they look to be Microsoft related.

And if we look at the secret itself, it's not a new secret. So we've seen this for two months. So this isn't something new. When you see this is based on our intelligence from our corpus of malware, we monitor this kind of stuff all the time. We'll know when this was released. So if this is a new version you're installing, and there's an embedded secret that was only seen, a week ago, that's a much higher risk.

That's something you want to dig deeper into. This has been really, for two months, this has been out and this is the same exposure for all of these, all the certificates are in here. So all of that sort of points towards this being a legitimate use. There's some reason that Microsoft has this because we do see these a lot and it's a Microsoft private key blob.

So we do see this in a lot of their software. I couldn't explain why you would have to go to a sandbox or talk to a vendor about that, but it's not really concerning. It's not really a leaked secret. This is more just how they do some things. You dug through that real quickly. That may be something, if this is the first time through and the first time you've seen it, you may want to investigate that, dig a little bit deeper.

Based on experience, I'm not too concerned with this. So again, not a huge number of issues, only two that really matters, the vulnerabilities and sensitive information. So we look at the vulnerabilities. Let's see where they're at. What components have these vulnerabilities? It looks like they're all third party components.

Zlib, we see in almost every package. This is the default compression, decompression component that everybody uses. Nobody rewrites that. There's no reason to recreate the wheel. That's why everyone uses these third party applications. These are pretty out of date though, right? Which is concerning for Microsoft.

Everything else looks good for this, except for this. And this is where we get into that sort of that file rot piece we talked about. So the current version of Zlib is 1.3. So 1.2.8 was 2013. 1.2.1.1 is later, 2017, I think. So these are pretty outdated. And this is what we talked about with that file rot, was these things, if they don't break, the developer is not going to go in and check these things.

As long as it's working, no one's going to go back and touch it. So it'll just continue to age over time. These are also dependencies. So these aren't components of the main package, they're dependencies of sub components of other software components inside this. So now you're two levels deep in your supply chain and that's where these things start popping up.

So the really old version of Zlib has a couple of vulnerabilities. The rest are not too bad. OpenSSL, we see that a lot in packages that have network communications. This isn't too far behind either. So there are some vulnerabilities, but it's not shocking. This is, for a file this size...

usually you see more than these, and some of that has to do with the policy settings here, but overall it's not too bad. Signatures, they're still relevant, nothing has aged out. Sometimes you'll see, this is part of the file rot, we did a whole episode on that as well. Where you'll see components that are signed with a certificate that expired 7 years ago, 8 years ago, 10 years ago.

We see some that are 20. That means that's an old component and it's likely going to have a lot of vulnerabilities attached to it, missing mitigations and other issues as these things age out over time. Here, this isn't too bad. This is where things fall apart for OneDrive. 108 behaviors. So we saw these does the same thing as Dropbox, right?

It's a remote file access, a cloud based file system. How could Dropbox do that with 30 some behaviors and Microsoft needs 108? So we'll poke through some of the major categories here and take a look, but you can just skim through this and get an idea. We'll also do some searching. So Microsoft is famous for collecting data.

So let's see what they're doing. So let's see what they're enumerating. And this again, we talked about earlier. It's the scale of the enumeration and data collection, but it's also the scope. What is being collected, but then how is it being collected? So system information is pretty generic, host name, that kind of stuff.

So I don't really put too much stock in this. I don't worry about that. But user account and privilege information, running processes. Some of these things are a little more concerning. Remote desktop session information. Now, why would this, why would OneDrive need that when Dropbox doesn't or Box or any of the other versions that we compared for part of this, to build up to this, no one has this except Microsoft.

So why does Microsoft need that? And why are 28 different files inside this package able to do that, able to connect and check your remote desktop sessions? This is where that software bloat comes in to play. Also what you have with Microsoft is that they're not delivering one off applications.

Everything they do is in order to hook you into their service. It's a, it's a platform play, which is the big thing now. They don't want you to use OneDrive. They want to push you to 365 or all these other services. So there are all these components. And part of this bloat is the connection to other services that it wants you to use, connections to Teams and all these other things, these, quote unquote features, do you really need them, who knows, but do they add risk, right?

This is all part of your attack service. The more things the software can do, the more ways it can be attacked. So Dropbox was, tight, small and efficient. We're starting to see some bloat show up here in Microsoft, so let's look at some of these other categories here.

Monitor. So let's see what else is monitoring. Same thing. Running processes, but do we really need 30 components to be able to do that? List of logged on users, so this isn't too much. Again, we say screenshots, right? So some of this is expected, but we'll see more and more elements here that aren't related.

Search. What else is it doing? What else is it trying to find on your box? And again, we see more sort of data collection elements. So if we look at this again, we see the remote desktop piece. Let's look. So this is another thing that you see with Microsoft that they like to call it telemetry. It's data collection.

It's just another fancy word for it. But if we look in here, we see three. So there's one DLL here, another DLL here. So there are three bundles of code. The sole purpose of these is to collect data and send it back to Microsoft. That's something to be aware of. You're putting a lot of trust in Microsoft to take that data and to save it and, not get it leaked, released, hacked, whatever.

So this is all part of your attack service. And this is, should be part of your risk assessment is all these elements. If you don't have visibility to this, then it's really, it's harder to do. So let's see what executes too. Let's go to execution. Look at all of them. So do these align with what we expect?

It controls a service. Sure. This is, it runs as a service, it's going to access low level OS DLLs. This is interesting. I would dig into that a little bit further, just to understand why URLmon is in there. But overall it doesn't look too bad. Now this is where it gets a little sketchy. And again, this is Microsoft.

It can start and run and execute PowerShell commands. It also can run batch scripts. It doesn't necessarily need to do these things, but these may be part of that integration with other services, but it's concerning, I wouldn't want my, whatever applications doing this or comms or anything, you know, Notepad or anything like that on your network.

You should know which ones can do this. Now it's ability to run scripts is a significant bump in risk here, because that's part of that attack surface. Same thing with the batch files, right? It's just another way that it can kick off an infection or. It can cause you problems down the road, so it's just things to be aware of. Networking as well.

Microsoft is famous for this. There's so much networking stuff in their applications. It communicates to so many things. So let's take a look

and we have almost 2000 strings in here related to network communications. And if we scroll through this a little bit, let's skip, cause there are a couple of weird ones,

but you can skim through this and see, look, there's some government sites for Turkey. That's odd.

Same thing. So you see a lot of these country code TLDs and it seems to be pointed towards documentation, almost every case, but still that's, a lot of potential networking traffic that this can cook off that again, Dropbox didn't need any of this stuff. This is all part of these things that figure in.

It's all PDFs and documentation usually, but sometimes you'll see scripts pop up in here. Sometimes you'll see domains that are related to third party software package distribution, like GitHub, right? Where you can see elements in here, like Python files or something coming from GitHub.

That's all part of your attack service. So without this visibility, it makes it hard to do a legitimate risk assessment. So we've run through a lot of these things. Now let's switch back to the slides and we'll talk about the assessment here. So these are all categories we're going to take a look at.

We skimmed over them pretty quickly. But I think the point is made. So here's what we do, the behavior related assessment. This is what I looked at when I went through here. So there's a lot more enumeration in OneDrive than Dropbox. Dropbox doesn't use scripts, doesn't use FTP, doesn't collect data, doesn't access cookies, but OneDrive does all of these things.

So when you're weighing these two together, outside of the basics of does it do all the services? Does it integrate with what we need it to do? And what's the price? Outside of that, this should help weigh your decision. Dropbox is smaller. It's purpose built. There's no bloat. It doesn't do a lot of crazy stuff, doesn't do a lot of data collection.

OneDrive does, and it does all of these things, so it loses on multiple elements here.

So anytime, especially with Microsoft, they're big on data collection. They're big on bloat, but a lot of softwares like that, you'll see, complex packages that will have all these third party components that don't really address the core competency of that application. Those things should concern you.

That's a conversation you want to have with the vendor. Or maybe you just, when you're comparing three devices to buy like this, three applications, maybe this one drops off the list. So here's the total assessment based on that initial table. So we go through this again, Dropbox is really focused on doing just what it's supposed to do.

The only third party components are from Google. Lower behaviors. So OneDrive had vulnerabilities. It also has way more components. So it's a much larger, much more complex package. And from the behaviors and from some of the things we looked at, unnecessarily it does a lot of things that.

Microsoft is interested in, but you may not be. 1800 plus different network domains in there. Nothing was bad. There's nothing in there that looks suspicious that I felt like I needed to pull the thread and dig deeper, but it's still a lot of behaviors there are secrets embedded, but again, the Microsoft side, they just, that's one of those things that they do.

ZLib, we talked about older versions here and those versions come with some missing mitigations. And some vulnerabilities, third party components. We saw the Qt company components also had some vulnerabilities and some issues. So all of this together, does this change your opinion from the beginning, which one is more secure?

There's no smoking gun and there generally isn't when you're doing software. There's not, everyone wants to talk about malware and vulnerabilities and everything has vulnerabilities, you just want to keep it within a certain range. This isn't bad. And again, all those vulnerabilities are in the third party components.

And if they just updated the two versions of Zlib that are in here, they'd mostly go away. So this is really a bigger picture. Hopefully if you're doing software assessments, you can see the value of the depth of visibility here and how much that aids an assessment that you can actually stand behind.

So that was all I had for this. So I think Guy, I don't want to kick back to you. But hopefully this helped and gave you some ideas about what this kind of activity should look like.

GUY NADIVI: Thank you, Tim. Very engaging, very interesting. Not what everybody expected, I'm sure.

Okay. By the way, for those of you interested in analyzing your own software supply chain security profile and testing out your own apps that you download we've got a 14 day free trial available to you of the same software that Tim uses to analyze packages like OneDrive and Dropbox. And that should be available at the link that is currently in everyone's chat.

There's no credit card required, or software to install, just create an account and you'll get 14 days of free access to a full blown version of our Software Supply Chain Security platform. You can use it to analyze malware and code tampering embedded in software components of any package you want to analyze, or generate an SBOM listing all open source third party packages and software you're using, or leverage the platform to contextualize and prioritize alerts and threats in your software supply chain.

Again, there's no charge. So please take advantage of this risk free trial. Next slide, please. Please be sure to tune into our next episode of Software Package Deconstruction, when we're going to look into reducing false positives in the SOC with software analysis. Tim will be reviewing how to tune security detections before deploying new software

in the enterprise. It's definitely an episode you won't want to miss, and it airs on Thursday, September 21st, two weeks from today, we look forward to joining us then. One more slide. And that concludes this episode of Software Package Deconstruction. Thank you all again for attending. Please be on the lookout for announcements about future episodes from ReversingLabs.

Have a great rest of the day, everyone, as well as a great rest of the week. And remember to broaden your view of software risk by securing your entire software supply chain.