Google Cloud’s ‘Cloud DLP’ solution does not actually actively prevent data exfiltration

Hi Security nerds. In my learning GCP journey, I came across Google Cloud’s DLP Solution ; and immediately, I think ‘hey that is cool – they have a Data Loss Prevention tool built in to GCP’ and can stop data going out the door.

The truth is a little less satisfying. Although there are some data masking features, (which I’ll get to here in a minute), GCP Cloud DLP is a Data Classification Tool (with some data masking abilities). In Google’s words:

“Cloud DLP gives you the power to scan, discover, classify, and report on data from virtually anywhere. Cloud DLP has built-in support for scanning and classifying sensitive data in Cloud Storage, BigQuery, and Datastore, and a streaming content API to enable support for additional data sources, custom workloads, and applications”

This miffs me a bit because…

Part of the issue here is DLP acronym actually has two meanings. I understand DLP to mean…..Data Loss Prevention as Gartner defines it – and when talking about DLP tools the last ten/fifteen years or so, they typically include the ability to actively block /prevent data from going out the door.

The same acronym has a watered down version, DLP can also mean Data Loss Protection. So, okay, I’ll be fair – Let’s go by Gartner’s definition for Data Loss Protection DLP, which talks a lot about scanning and classifying which Cloud DLP does. However, in the tool page; Google is calling it ‘Cloud Data Loss Prevention’ !

Yeah, Cloud DLP a Data Classification Tool named like a Data Loss Prevention Tool. Ok, so you may say ‘ well wait, google also says Cloud DLP can ” mask, tokenize, and transform sensitive elements “. Yes, those things prevent sensitive data loss; not data loss.

So, what we have here industry buzzword marketing vs. functionality ; and in the mind of this Engineer, the product is inappropriately named because its name infers functionality the product actually does not do. Thinking a tool rename is in order… call it GCP’s Amazing Data Classifier and Masker. Or TaggadyMcDataTagger or.. ?

Funny how I came across this; I was doing a practice test for my Google Cloud Security Engineer Professional certification and I came across a question about Cloud DLP, which I got wrong because Google Cloud DLP does not actively stop data exfiltration; it can scan, classify, mask and transform data. Hahaha.

AWS vs. GCP IAM Terminology and Functions

I’ve spent the last 7 years in AWS, and now I am learning GCP, so why aren’t there courses out there that teach GCP with analogies from AWS? Maybe that’s on me to create? For now, let’s take apart the differences of GCP and AWS IAM.

Start with users… leveraging AWS as baseline understanding. In AWS we, have regular IAM users, users that exist as individual principals in a particular account, where the AWS account itself performs the authN and authZ. These users are created in IAM console of AWS. In AWS we also have Federated users/ entities, which are principals’ AuthN and AuthZ is performed by external trusted entities; and a AWS Role is assumed by that Principal that aligns with the level of AuthZ. Last we have the Root account user, which is associated to the billing email address of the account, or organization(group of accounts).

This was a bit weird for me, in Google Cloud, there are a few different entities that are “users” within a GCP account.

Google Account: A Google Account, which can be a Gmail account or a Google Workspace account, can be associated with a GCP account. It represents an individual user and can be used to access GCP services.

GCP Identity: GCP provides its own identity management system called Cloud Identity. Cloud Identity allows you to create and manage users directly within GCP. These users can be associated with specific GCP projects and have permissions and roles assigned to them.

Service Account: A service account is a special type of account in GCP that represents an application or a service rather than an individual user. Service accounts are used to authenticate applications and services that need to interact with GCP resources. Service accounts are assigned roles and permissions to access specific resources.

Google Groups: Google Groups can also be considered as users within a GCP account.

That is a bit of a brain-breaker, when using AWS as my reference, hoping this helps you. The GCP concept I needed to learn was the GCP Service Account.

The GCP service account functionality sort-of aligns to an AWS IAM Role, (although GCP also has “Roles”, ugh…more on those differences in a minute).

A service account is used by a .. service! Really, an application or compute workload, (not a human!). In GCP, A service account is identified by its email address. (weird, right?)

Applications use GCP service accounts to make authorized API calls by authenticating as the service account itself. When an application authenticates as a service account, it has access to all resources that the service account has permission to access. Service account are attached to the resource running the application, (sounds a bit like an AWS role, yeah?)

Let’s talk more about the differences with GCP and AWS Roles. While both GCP and AWS roles serve the purpose of granting permissions, GCP roles are more focused on defining permissions for specific resources or services, while AWS roles are centered around trusted entities assuming roles to acquire permissions.

AWS Roles:

In AWS, roles are Trust-based: ( think trust policy.. who can assume the role) An AWS role is a way to delegate access permissions to trusted entities, such as IAM users, AWS services, or external federated users. Roles define what actions and resources can be accessed, (via the policies attached to them); and who can assume the role.

Assumption of Roles: IAM users or services can assume an AWS role to temporarily acquire the permissions associated with that role. This, of course, enables entities to access AWS resources securely without having their own long-term access keys or credentials, YAY!

Service-oriented: AWS roles are often associated with AWS services and resources, allowing services like EC2 instances, Lambda functions, or ECS tasks to assume roles and access other AWS services. Roles can also be assumed by IAM users to gain temporary permissions.

GCP Roles:

Permissions-based: In GCP, a role is a collection of permissions that determine what actions a user or service account can perform on GCP resources. GCP provides a set of predefined roles with specific permissions, (Viewer, Editor, and Owner). Custom roles can also be created to define granular permissions.

The big differentiator for GCP… There is no concept of assuming roles in GCP. GCP roles are permission-based and are assigned directly to users or service accounts.

I’m back!

I finished a nearly 4 and a half year stint at AWS, during which time I did not blog here because I did not want to create a legal situation for myself in giving my opinions about the state of Cloud Security, etc..

Looking forward to getting this going again!

NGINX Moscow Office Raided!

Hi friends. I received an interesting letter from: Gus Robertson <gus.robertson@nginx.com> letting me know that NGINX’s Moscow office was raided by Police!!!

 

This referenced ZDNET Article corroborates the email.  Also, here is a link to a photo of the search warrant, that was originally posted on twitter.

Between those two links, you have most the details surrounding the raid. However, what is not in those two links – I will comment on + dive into a bit here:

What makes this whole thing is interesting about this is that F5 now owns NGINX. It is eyebrow raising where F5 says in the letter that they are “not a party” to the intellectual property that is in dispute. Well, what is the IP exactly?

From ZDNET  “The Moscow police executed the raid after last week the Rambler Group filed a copyright violation against NGINX Inc., claiming full ownership of the NGINX web server code”

When F5 bought NGINX, did they not also not purchase the referenced disputed IP? This is not clear to me why F5 would say they are “not a party”. Maybe some corporate veil between F5 and NGINX gives them the right to legally state that. AND/OR . . . they may be attempting to keep the F5 name squeaky clean and not tie F5 name and F5 software to Russia and Russians. Damage control.

The other interesting part about the letter I received is that F5 only took measure to secure the master builds for NGINX products AFTER THE RAID. That’s basically saying that all master builds of referenced NGINX products were not secure prior to the raid. Is there any other way to read that?

What is not said in their letter is interesting…

1. According to ZDNET, “Equipment was seized and employees were detained for questioning“. Equipment was seized. If I am a customer, was any of MY data seized? That would seem to be priority one for F5 to let customers know this if they have not done so.

2. Although the letter states that none of the master builds are not on Russia servers ( at the time of the letter was crafted? ). Were the Master builds of the mentioned products on Russian Servers BEFORE the raid?

3. Why did F5 not tell customers that all of the MD5 file hashes of all the build files, from both pre and post raid, were in fact, the same?

The fact that F5 is saying that the master builds were not secure prior to this raid really bothers me. I know some of the builds may have been open source, but NGINX Plus, UNIT and WAF are not, ( which are all referenced in the letter).

It will be interesting to watch this play out..

Note: This blog and the opinions in it are 100% my own, and in no way reflect those of any present or previous employer.  This blog is not associated with any company.

 

How Domain Fronting Attacks work. Explained in seven steps

Domain Fronting Attacks were on of the top 5 attacks listed in material that came out of the RSA 2019 Conference as a way for attackers to obfuscate their activities. This was of high interest to me, so I dug in.

Formally, Domain Fronting is a technique leveraged by threat actors to use high reputation domains to disguise C2 callbacks from both the user and security tool sets.

Domain Fronting attacks work in Cloud Distribution Networks, (CDNs). CDNs are leveraged by companies who want to put themselves ‘closer’ to the customer and thus will allow the CDN to cache specific elements of the application on CDN owned Points of Presence(POPs) that are geographically close to the customer base. To do this, the CDN will also host the SSL Web Certificate of the Domain.  This is where we get started.

1. Attacker sets up their own server on the same CDN as the target company, (the target company is the company whose legitimate SSL Certificate is intended to disguise callbacks to the attacker’s C2 network).  For an example, let’s say the legitimate domain with a SSL cert is Henson.com hosted on a CDN. Attackers server is on the same CDN.

2. Initial Malware callback to legitimate domain. Attacker’s malware that is resident on any internal corporate network(that got there via phishing / or other means), makes its initial callback. However, the callback does not go to attacker owned domain, instead the callback goes to the a legitimate domain, Henson.com, hosted on the CDN. This step simply sets up TLS session between Malware endpoint and Henson.com property on the CDN.

3. User and Security Tools are fooled. The DNS resolution and the following call looks like any other web call to a legitimate domain, and the browser trusts the certificate.

4. Malware makes a second call to the attacker owned resource in the same CDN as Henson.com, hidden via the http 1.1 host header inside the valid TLS connection.

5. Request is routed. CDN fronts this second request as it is for Henson.com, but next it unwraps the TLS header, it reads the http 1.1 host header and re-routes request to the attacker’s server on the CDN.

6.  Another Re-direct. The attacker, not wanting their activity to be discovered by the CDN, simply has their server in the CDN do a second re-direct to an off-CDN command and control server anywhere in the world. From the CDN point of view, Nothing nefarious there, just a redirect . . .

7. The Command and Control Channel is set up. At this point, the redirect to the off-CDN command and control completes, so the full C2 is set up:

 Infected Host inside corp network -> CDN -> Henson.com on CDN -> Attacker's re-direct server on CDN > Attacker C2.  and completely hidden.

Defending Against Domain Fronting

As a Security Defender, your best defense against Domain Fronting is to have a proxy server for all your internet connections leaving your corporate network that is configured for TLS interception.  You can configure your proxy server to ensure the http 1.1 host header matches the domain that is in the URL. If the domain does not match, you can overwrite it, log (and alert) on the action.

Another defense technique to think about is to ensure you don’t have any dangling DNS / CDN fronted resources that the CDN would route to an origin host that is no longer present.

Also, taking several steps back, it was assumed that malware was present; and was making a callback. Strong host security, code signing, and application white listing can help prevent malware from running in the first place.

Stay safe, friends!

 

Disclaimer: This blog is private and independent. This blog not is associated with AWS or Amazon in any way.

Is Azure lowering the bar on their certification exams?

Hi friends. I want to take a different approach today and offer some a speculation on something I saw which caught my eye. This is only speculation, so as you read, please keep this in mind.

Scrolling through LinkedIn on my phone, I came across this post, which I have pasted below: (identity of the source of the post removed purposefully )

Anything strike you as strange here? As  you know, it was announced publicly last weekend that Microsoft won the JEDI contract.

My theory is this: Microsoft recently re-graded tests on a lower curve to increase the number of Azure Certified individuals.  Perhaps to support JEDI initiative? The timing of the Contract award and the above post seem coincidental, but hey… maybe I am just a paranoid Security guy.

At present there are no good data sources with actual current certification counts to put some data behind the theory. However, according to a recent Cloud Security Alliance (CSA) report , AWS is the most popular public cloud infrastructure platform, comprising 41.5% of application workloads in the public cloud.

Therefore, it would stand to reason there are MORE AWS certified individuals than Azure Certified individuals to support the cloud workloads. Microsoft simply may be trying to level the talent playing field by retroactively re-grading exams.

The Azure Certification program hit some bumps last year as well and Microsoft  re-vamped its Azure Certification Program after getting feedback  from the community that the tests were “too broad”.

Okay, it’s time to end  ‘theory hour’ and get back to working on facts. Stay safe!

 

Disclaimer: This blog is private and independent. This blog not is associated with AWS or Amazon in any way. The opinions of this blog are my own NOT those of Amazon.

New GuardDuty Alerts worth mentioning

Amazon recently added a few notable alert types to help mitigate against some known attack types. I have been following, studying and blogging on AWS GuardDuty since it was released and it is amazing to watch the innovation happen in this product since its inception.

The first new alert is:

UnauthorizedAccess:EC2/MetadataDNSRebind

is interesting because it is designed to mitigate against attacks very similar to the recent Capitol One attack, where the attacker queried EC2 metadata service as one of the key steps in the attack kill chain. Put simply, this alert will fire when an EC2 instance in your AWS environment is querying a domain that resolves to the EC2 metadata IP address 169.254.169.254.

Per Amazon, “A DNS query of this kind may indicate that the instance is a target of a DNS Rebinding technique which can be used to obtain metadata from an EC2 instance, including the IAM credentials associated with the instance. ”

The second alert, (with very descriptive name)

Stealth:IAMUser/S3ServerAccessLoggingDisabled

basically does exactly that – tells you that someone shut off s3 server access logging on a particular bucket. I imagine the false positives with this would be low, there are not many reasons to disable this on a bucket, except in cases where someone may have billing shock, or the bucket is being decommissioned. Otherwise, a strong indicator of bucket tampering. Enabling this alert would help detect if someone is uploading bad stuff to your bucket, such as in this attack, where the threat actors added malicious code to s3 buckets to be served on websites.

Last, this alert falls in the same category of Bucket Tampering:

Policy:IAMUser/S3BlockPublicAccessDisabled

Same deal here, this one basically says that ‘your bucket is public now’, (where is was not before). This is to mitigate against data exfiltration, where a bucket could be leveraged as a temporary storehouse before moving data out of the company completely.

Enjoy and Stay Safe!

Disclaimer: This blog is private and independent. This blog not is associated with AWS or Amazon in any way.

 

 

 

 

The SalsaCentralDenver Phishing Campaign – Exclusive

Sometime on or before Friday, October 18th, the email account belonging to Denver Salsa Central had been compromised.

What is not in their courtesy notice is that the attacker(s) leveraged the info@SalsaCentralDenver email account to initiate a phishing campaign.  By sending phish emails from this domain, SPAM filters would likely not match existing blacklists and flag the phish. I know it got through gmail’s SPAM filter.

Here are screen shots of the three Phishing emails, pretending to be notifications from Amazon, American Express and Chase. All of these arrived within a few minutes of each other.  Take a look just below.  The email address where these phish are sourced are info@salsacentraldenver.com

 

The hook links [ middle button on each phish ]  are similar, all going to the rs6.net domain:

Fake Chase:
hxxp://r20.rs6.net/tn.jsp?f=001JXpTPVvaw8Za5wyc1tOV4IIhr1iiO8uXOX87_fRPtuJwbDK_vDhnf4HwdFkGvSGRscR_ng0dB0JFoiI5CKok1-6r0jbU8WZmt8GKLYtPhQJWMMynae3b8SVzdB64k1mK9Pn0GgiHAGT1kVux-WnfAU8aVfStiVYO&c=xxAs40ZUomXSX50x5PKouuoDD1CCTH6LmgL9CIvuC2zDIV7TuHfVGw==&ch=VngmDcyiYPxmM6aPlukgrMJvhmrUlm7hD5GS1o7_RCgNuNFtM098Kw==

Fake Amazon: 
hxxp://r20.rs6.net/tn.jsp?f=001DxKEhl7FukUIG9W_XeNKfQPgYA9tL1aW7OH0SV0OWC8K8kCWWZEhxxMjdmdkNCYC3fJ879jKnJ2-7uQbdVuRp0nVIUhH3CRVz2lofPLxGdSWxu25PqUHq51QnWbsSxjOgdHozJNVkQn1QE-OqpoQ_ggef2aO76ju&c=omRnvkKXUlD65znA5wavcPaptpm3fezuTe8WLpm7GHcsbL4Eutqizg==&ch=w2FTck3mc9gPFnwErfcKfSpEbl8mYFGCyCO6vruOtRKwhIqtQszjrA==

Fake American Express:
hxxp://r20.rs6.net/tn.jsp?f=001Aml9EoWQ0-q8cJjCstWSyaC_dOeY8h6R3Tb-l49kHQanU3nI0FnQJahiWHyc_3C0yQmuBAV79HS5N9IpQguXghqMEKJKIw6q2Ab6gII-27zn3xQkTWiigeLBB41nLr31QeQ6IF5SHWgALNPxNj96EQ==&c=OacERVHNGaWMdOx_kyHBrz5Ip90v2h2_NtQyKNpsMgkeTMcDogp0PA==&ch=YHjVBwhFVH0IPJHnwpxit_w76o9betL9tcYy5aqlP3J3m5emxZX4Jw==

This is where is gets weird. A whois for rs6.net shows it belongs to markmonintor.com

MarkMonitor appears to be a reputable Security company, but the emails came from a known account hack. Why would the hackers go through the trouble of compromising an email account to only redirect it to a supposedly legit Phishing / Fraud company?  It gets even stranger when I open a sandbox vm and follow one of the links. Keep reading

So… I turn on a pcap on my sandbox vm and follow the fake Amazon link:

Fake Amazon: hxxp://r20.rs6.net/tn.jsp?f=001DxKEhl7FukUIG9W_XeNKfQPgYA9tL1aW7OH0SV0OWC8K8kCWWZEhxxMjdmdkNCYC3fJ879jKnJ2-7uQbdVuRp0nVIUhH3CRVz2lofPLxGdSWxu25PqUHq51QnWbsSxjOgdHozJNVkQn1QE-OqpoQ_ggef2aO76ju&c=omRnvkKXUlD65znA5wavcPaptpm3fezuTe8WLpm7GHcsbL4Eutqizg==&ch=w2FTck3mc9gPFnwErfcKfSpEbl8mYFGCyCO6vruOtRKwhIqtQszjrA==

I am first redirected by the MarkMonitor owned domain to a new domain, hxxp://81-op-0-1.com

And ..

Seems the only purpose of this redirect is to be redirecting again, to the hxxp://02-02.002.com. Obfuscation?

From my capture, I see the DNS name resolution resolving 02-02-002.com to 143.95.237.93

which is owned by Athenix, which is important since this IP is actually hosting the fake stuff, which you’ll see when you keep reading.

The hxxp://02-02-002.com link takes me to a copy of the real amazon site:

Ok – all of that noted, lets get on with giving these guys what they want. When I get to the page, the fake amazon is asking for me for my email, so I make up something and put it in

Next, I am presented with my second screen, so I make some stuff up and fill this out as well.

Oh, not done, Screen number three, this is where it gets good. They want my credit card number. Now I am thinking I wonder what all of this has to do with MarkMonitor?

The form works and its actually uploading my data. A sniff of the http post req shows these the POST with “my credit card”

After hitting continue.. more stuff.. they want the password to the email account I originally supplied.  Sure.. let’s give them access…

After hitting Continue one more time.. I am actually redirected to the the REAL Amazon.com!!!!

This is a real Phish alright. These guys asked for email account + password,  and my credit card. So did why did MarkMonitor  just collect PCI and PII data from me? They didnt. The fakes sites are all hosted at 02-02-002.com. I think MarkMonitor has lost control of one of their subdomains. The Hacker placed the first redirect

 

Stay tuned for more + Stay safe!

 

 

 

 

 

 

 

 

Two handy AWS API Calls useful for Forensics

A little while ago, I wrote a blog on how to use Lambda to shut down a compromised instance . The idea behind this was a way to quickly detect and remediate an instance which AWS GuardDuty Intrusion Detection flagged as infected.

To add the ability to do a Forensic Investigation to the automation, take a look at a couple more API calls to add to your function.

For volume forensics, create a forensic volume snapshot after your instance is stopped

aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "This is my root volume snapshot

or Python

ec2 = boto3.resource('ec2')
snapshot = ec2.Snapshot('vol-1234567890abcdef0')

The snapshot allows you to investigate the volume and not compromise the evidence ( original volume ) in an investigation.

For memory Forensics, think about automation to Hibernate the instance. Yes, instead of stopping the instance, if you are running certain flavors of linux, ( e.g. instance meets the prerequisites for hibernation ), can instead place the instance into hibernation .

Per AWS What happens when an instance is hibernated:

“When you hibernate an instance, we signal the operating system to perform hibernation (suspend-to-disk), which saves the contents from the instance memory (RAM) to your Amazon EBS root volume. We persist the instance’s Amazon EBS root volume and any attached Amazon EBS data volumes. When you restart your instance, the Amazon EBS root volume is restored to its previous state, the RAM contents are reloaded, and the processes that were previously running on the instance are resumed. Previously attached data volumes are reattached and the instance retains its instance ID. “

For CLI:

The instance has be to run with Hibernation on:

aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type m5.large --hibernation-options Configured=true --count 1 --key-name MyKeyPair

and the Hibernate is a parameter on stop-instances  . . .

aws ec2 stop-instances --instance-ids i-1234567890abcdef0 --hibernate

This feature was released about a year ago, and as you can see, only supports limited instance and volume types, however it is great for Forensics on memory resident malware.

Additional Forensic information

EC2 Forensics SANS Paper

Digital Forensics AWS Paper

Incident Response in AWS BlackHat Paper

Top 3 Open Source tools for AWS Incident Response

 

Stay Safe Friends!

The importance of Scope and Rules of Engagement in a Penetration Test

Hi friends! An interesting story appeared on theregister.co.uk about a pair of Professional Penetration Testers getting arrested after attempting a physical break-in at their client’s building.

Crazy, right? The core of the story is that, YES –  they were hired by this client to engage in a penetration test to access computer records, however, the client apparently did not sanction testing physical security controls as part of the test.

Often times, too much emphasis is put on the excitement of running an exploit and gaining a foot-hold in a network, finding the goods / capturing the flag as it were… and no one seems to be having the conversations about preparedness. You know, all of the things that happen before a pen-test.

Rule 1 is Get Permission before doing anything pentest related. This is in the form of a legal contract between you and the client. (If its your own company, having formal sign-off at an Senior Executive level )

Rule 2 is Determine and Document Scope of the Test. The outcome of this workflow will actually be referenced as part of the permission document in Rule 1. Scope is simply, in a broad sense, is what you are allowed to do as a Pentester.  What networks are you testing against? What hosts? Only internal parts of the network? Is Social Engineering allowed as part of this test? Is this a black box(secret) pentest or is a whitebox pentest, where the Building Security and IT Security Team knows what’s up? Am I allowed to plug in equipment to the network? Am I testing in DEV, TEST or PROD environment? Are physical Security controls at the facility housing the computer system in scope? These questions are not all-encompassing, but provide a decent example –  You get the idea here. The scoping document is signed off by all Executive parties (Legal) and is apparently what the two afore mentioned gentlemen did not have in their engagement.

From the referenced Article: “The bureaucrats were, however, unaware the tests could also involve physical break-ins, it is claimed.”

Rule 3 is to Determine Rules of Engagement. Well, Chris, you just said if they had a scoping document, everything would be ok, what gives?  Rules of Engagement guides the Pentester’s actions when specific findings, events or circumstances occur during a test.

For the above reference. The Rules of Engagement document would state, that if a Physical Alarm is tripped, then the Pentester must approach building Security building Security must verify the PenTester’s Identity and then call the Sheriff and let them know this was a Security Exercise. Or if this was a silent alarm, protocol might have been to display a temporary badge to the arresting officers and a phone number of a Senior Executive who could be contacted to verify identities if needed.

More specifically though, What happens if a critical (unexpected) finding is uncovered that puts the company at risk? Do we stop the Pentest?  If I see a vulnerability on a box, can I run a metasploit script against it? Or do I just report that vulnerability. If I run an explout on a box and it breaks the box, what do I do? Rules of Engagement tells me this.  You get the idea.

I don’t think our friends had this one sorted out either; as there appeared to be no protocol for the Pentesters to rely upon when the Police showed up… that would have kept the testers out of jail. And no protocol for Building Security/Alarm Company (other than to call the Police).

So, the take-away… Definitely spend your time making sure you, your team and the client are on the same page with regards to all aspects and details of the Penetration test!

You can find the Official Scoping and Rules of Engagements worksheets here:

https://pen-testing.sans.org/resources/downloads

And NEVER NEVER run a test without (written, legal) permission. Verbal will not do. Ever.

Stay safe, friends!