Tag: IoT

Industry standards would provide predictable and understandable IoT security frameworks.Industry standards would provide predictable and understandable IoT security frameworks.Read More

Using certificates to authenticate and encrypt data is vital to any enterprise security. For example, companies rely on certificates to provide TLS encryption for web applications so that client data is protected. However, not all certificates need to be issued from a publicly trusted certificate authority (CA). A privately trusted CA can be leveraged to issue certificates to help protect data in transit on resources such as load-balancers and also device authentication for endpoints and IoT devices. Many organizations already have that privately trusted CA running in their Microsoft Active Directory architecture via Active Directory Certificate Services (ADCS).

This post outlines how you can use Microsoft’s Windows 2019 ADCS to sign an AWS Certificate Manager (ACM) Private Certificate Authority (Private CA) instance, extending your existing ADCS system into your AWS environment. This will allow you to issue certificates via ACM for resources like Application Load Balancer that are trusted by your Active Directory members. The ACM PCA documentation talks about how to use an external CA to sign the ACM PCA certificate. However, it leaves the details of the external CA outside of the documentation scope.

Why use ACM PCA?

AWS Certificate Manager Private Certificate Authority (ACM Private CA or ACM PCA) is a private CA service that extends ACM certificate management capabilities to both public and private certificates. ACM PCA provides a highly available private CA service without the upfront investment and ongoing maintenance costs of operating your own private CA. ACM PCA allows developers to be more agile by providing them with APIs to create and deploy private certificates programmatically. You also have the flexibility to create private certificates for applications that require custom certificate lifetimes or resource names.

Why use ACM PCA with Windows Active Directory?

Many enterprises already use Active Directory to manage their IT resources. Whether it is on-premises or built into your AWS accounts, Active Directory’s built-in CA can be extended by ACM PCA. Using your ADCS to sign an ACM PCA means that members of your Active Directory automatically trust certificates issued by that ACM PCA. Keep in mind that these are still private certificates, and they are intended to be used just like certificates from ADCS itself. They will not be trusted by unmanaged devices, because these are not signed by a publicly trusted external CA. Therefore, systems like Mac and Linux may require that you manually deploy the ADCS certificate chain in order to trust certificates issued by your new ACM PCA.

This means it is more efficient for you to rapidly deploy certificates to your endpoint workstations for authentication. Or you can protect internal-only workloads with certificates that are constrained to your internal domain namespace. These tasks can be done conveniently through AWS APIs and the AWS SDK.

Solution overview

In the following sections, we will configure Microsoft ADCS to be able to sign a subordinate CA, deploy and sign ACM PCA, and then test the solution using a private website that is protected by a TLS certificate issued from the ACM PCA.

Configure Microsoft ADCS

Microsoft ADCS is normally deployed as part of your Windows Active Directory architecture. It can be extended to do multiple different types of certificate signing depending on your environment’s needs. Each of these different types of certificates is defined by a template that you must enable and configure. Each template contains configuration information about how Microsoft ADCS will issue the certificate type. You can copy and configure templates differently depending on your environment’s requirements. The specifics of each type of template is outside the scope of this blog post.

To configure ADCS to sign subordinate CAs

On the CA server that will be signing the private CA certificate, open the Certification Authority Microsoft Management Console (MMC).
In the left-side tree view, expand the name of the server.
Open the context (right-click) menu for Certificate Templates and choose Manage.

This opens the Certificate Template Console, which is populated with the list of optional templates.

Scroll down, open the context (right-click) menu for Subordinate Certification Authority, and choose Duplicate Template, as shown in Figure 2. This will create a duplicate of the template that you can alter for your needs, while leaving the original template unaltered for future use. Selecting Duplicate Template immediately opens the configuration for the new template.

To configure and use the new template

On the new template configuration page, choose the General tab, and change the template display name to something that uniquely identifies it. The example in this post uses the name Subordinate Certification Authority – Private CA.
Select the check box for Publish certificate in Active Directory, and then choose OK. The new template appears in the list of available templates. Close the Certificate Templates Console.
Return to the Certification Authority MMC. Open the context (right-click) menu for Certificate Templates again, but this time choose New -> Certificate Template to Issue.

In the dialog box that appears, choose the new template you created in Step 1 of this procedure, and then choose OK.

That’s all that’s needed! Your CA is now ready to issue certificates for subordinate CAs in your public key infrastructure. Open a browser from either the ADCS CA server itself or through a network connection to the ADCS CA server, and use the following URL to access the certificate server’s certificate signing interface.

http://<hostname-of-your-ca-with-domain>/certsrv/certrqxt.asp

Now you can see that in the Certificate Templates list, you can choose the Subordinate Certification Authority template that you created, as shown in Figure 4.

Deploy and sign the ACM Private CA’s certificate

In this step, you will deploy the ACM PCA, which is the first step to create a subordinate CA to deploy in your AWS account. The process of deploying the ACM PCA is well documented, so this post will not go into depth about the deployment itself. Instead, this procedure focuses on the steps for taking the certificate signing request (CSR) and signing it against the ADCS, and then covers the additional steps to convert the certificates that ADCS produces into the certificate format that ACM PCA expects.

After the ACM PCA is initially deployed, it needs to have a certificate signed to authenticate it. ACM PCA offers two options for signing the new instance’s certificate. You can choose to sign either through another ACM PCA instance, or via an external CA. Since you are using ADCS in this walkthrough, you will use the process of an external CA. The ACM PCA deployment is now at a point where it needs its CSR signed by Microsoft ADCS. You should see that it is ready in the AWS Management Console for ACM PCA.

To deploy and sign the ACM PCA’s certificate

When the ACM PCA is ready, in the ACM PCA console, begin the Install subordinate CA certificate process by choosing External private CA for the CA type.

You will then be provided the certificate signing request (CSR) for the ACM PCA. Copy and paste the CSR content into the ADCS CA signing URL you visited earlier on the CA server. Then choose Next. The next page is where you will paste in the new signed certificate and certchain in a later step.
From the ADCS CA URL, be sure that the new Subordinate Certification Authority template is selected, and then choose Submit. The new certificate will be issued to you. The ADCS issuing page provides two different formats for the certificate, either as Distinguished Encoding Rules (DER) or base64-encoded.
Copy the base64-encoded files for both the certificate and the certchain to your local computer. The certificate is already in Privacy Enhanced Mail (PEM) format, and its contents can be pasted into the ACM PCA certificate input in the console. However, you must convert the certchain into the format required by the ACM PCA by following these steps:
To convert the format of the certchain, use the openssl tool from the command line. The process of installing the openssl tool is outside the scope of this blog post. Refer to the OpenSSL site documentation for installation options for your operating system.
Use the following command to convert the certchain file from Public Key Cryptographic Standards #7 (PKCS7) to PEM.

openssl pkcs7 -print_certs -in certnew.p7b -out certchain.pem

Using a text editor, open the certchain.pem file and copy the last certificate block from the file, starting with —–BEGIN CERTIFICATE—– and ending with —–END CERTIFICATE—–. You will notice that the file begins with the signed certificate and includes subject= and issuer= statements. ACM PCA only accepts the content that is the certificate chain.

Return to the ACM PCA console page from Step 1, and paste the text the you just copied into the input area provided for the certificate chain. After this step is complete, the private CA is now signed by your corporate PKI.

Test the solution

Now that the ACM PCA is online, one of the things it can do is issue certificates via ACM that are trusted by your corporate Active Directory joined clients. These certificates can be used in services such as Application Load Balancers to provide TLS protected endpoints that are unique to your organization and trusted only by your internal clients.

From a client joined to our test Active Directory, Internet Explorer shows that it trusts the TLS certificate issued by AWS Certificate Manager and used on the Application Load Balancer for a private site.

For this demo, we created a test web server that is hosting an example webpage. The web server is behind an AWS Application Load Balancer. The TLS certificate attached to the Application Load Balancer is issued from the new ACM PCA.

Conclusion

Organizations that have Microsoft Active Directory deployed can use Active Directory’s Certificate Services to issue certificates for private resources. This blog post shows how you can extend that certificate trust to AWS Certificate Manager Private CA. This provides a way for your developers to issue private certificates automatically, which are trusted by your Active Directory domain-joined clients or clients that have the ADCS certificate chain installed.

For more information on hybrid public key infrastructure (PKI) on AWS, refer to these blog posts:

How to implement a hybrid PKI solution on AWS
Integrating Microsoft Active Directory with AWS Certificate Manager Private CA using Secardeo certEP

For more information on certificates for Mac and Linux, refer to the following resources:

Add certificates to a keychain using Keychain Access on Mac
Ubuntu – Installing a root CA certificate in the trust store
RedHat – Making CA certificates available to Linux command-line tools

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Using certificates to authenticate and encrypt data is vital to any enterprise security. For example, companies rely on certificates to provide TLS encryption for web applications so that client data is protected. However, not all certificates need to be issued from a publicly trusted certificate authority (CA). A privately trusted CA can be leveraged toRead More

The success of Domino’s Flex IoT project can be attributed in large part to the security best practices it followed.The success of Domino’s Flex IoT project can be attributed in large part to the security best practices it followed.Read More

We’re continuing to expand the scope of our assurance programs at Amazon Web Services (AWS) and are pleased to announce that seven new services have been added to the scope of our Payment Card Industry Data Security Standard (PCI DSS) certification. This provides our customers with more options to process and store their payment card data and architect their cardholder data environment (CDE) securely in AWS.

You can see the full list of services on our Services in Scope by Compliance program page. The seven new services are:

Amazon DevOps Guru
Amazon HealthLake
AWS IoT SiteWise
AWS Lake Formation
Amazon Location Service
Amazon MemoryDB for Redis
Amazon WorkMail

We were evaluated by Coalfire, a third-party Qualified Security Assessor (QSA). Customers can access the Attestation of Compliance (AOC) report demonstrating AWS’ PCI compliance status through AWS Artifact.

To learn more about our PCI program and other compliance and security programs, see the AWS Compliance Programs page. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

We’re continuing to expand the scope of our assurance programs at Amazon Web Services (AWS) and are pleased to announce that seven new services have been added to the scope of our Payment Card Industry Data Security Standard (PCI DSS) certification. This provides our customers with more options to process and store their payment cardRead More

When Katie Yates suddenly started receiving nude photos of her friend, Natalie Claus, over on Snapchat, she instantly recognized that Claus had just become a victim of a sextortion attack. She also knew how Claus should respond.

This happened in December 2019 when Claus was a sophomore. Both were students at the State University of New York.

Yates has a story of her own, too. Months before receiving those messages from Claus, she was herself a victim of sexual assault. After reporting the abuse, Yates started receiving abusive messages on social media. Seeing the lack of support from anyone on campus, she explored ways to identify her harasser.

This vigilanteism—Yates taking the matter into her own hands because she’s not getting any help—proved beneficial for Claus. So when Yates asked Claus if she wanted to catch her hacker, Claus said, “Yeah.”

Hacker posed as “Snapchat Security”

The case of Claus’s hacker, David Mondore (a chef), actually made headlines around 2020 and 2021. Claus is not his sole victim, and a press release revealed that Mondore was involved in a string of Snapchat hijacking activities from July 2018 to August 2020. During this period, the hacker gained unauthorized access to at least 300 Snapchat accounts, including Claus’s.

This Bloomberg article mentioned that Mondore posed as a “security employee” who warned Claus of an alleged breach of her Snapchat account. The Office of the US Attorney of New York provided more detail on the ruse that tricked Claus into handing over her account to Mondore.

According to Claus, whom the press release refers to as Victim 1, she received a Snapchat message from an acquaintance, whom the press release refers to as Acquaintance 1. The person messaging Victim 1 is actually Mondore using Acquaintance 1’s account.

Acquaintance 1 asked Victim 1 for her Snapchat credentials, so they can use the account to check if another user blocked them. In Snapchat, you can’t see anyone who’s blocking you even when you search for their username or full name. It appears the only way to see who’s blocking who is using another account. Several sites use this tactic.

Clearly, Mondore took advantage of this.

After Victim 1 sent her credentials to Acquaintance 1, Mondore sent Victim 1 a text message via an app anonymizing his actual phone number. The message he sent purportedly came from Snapchat Security, requesting Victim 1 to send the passcode for her “My Eyes Only” folder to verify that Victim 1’s account has been legitimately accessed.

“My Eyes Only” is a secure, encrypted, and private folder within Snapchat where users can save potentially sensitive photos and videos. This can only be accessed with a passcode.

After gaining access to Victim 1’s Snapchat account and her “My Eyes Only” folder, Mondore rinses and repeats. He contacted Victim 1’s contacts using her account, asking for their credentials under the pretense of checking who blocked them.

Mondore also used Claus’s private photos, which she had taken for herself as she attempted to recover from a rape, to gather compromising material from her Snapchat contacts. The message sent out with her nude images says, “Flash me back if we’re besties.” It was sent to 116 people, four of whom responded with explicit photos of themselves.

“Gotcha”

Claus hatched a plan to trap her hacker with Yates’s help. Using her own Snapchat account, Yates sent a message to Claus’s account, which Mondore had already controlled by then, saying she had nude images to share, with a URL link made to look like a porn site.

The URL, once clicked, collected the IP address of anyone who accessed it using the Grabify IP Logger website. Not only that, Yates and Claus set up the URL to redirect Mondore to the Wikipedia page for the word “gotcha” instead of the porn site he probably expected.

Mondore, upon seeing the Wikipedia redirect, messaged Yates saying, “What the hell is this?” She then blocked Claus’s account after collecting Mondore’s IP: he was in Manhattan and using an iPhone without a VPN.

Claus sent her police report to the campus police, who then forwarded it to the New York state police. One of the officers then knew who to contact within the FBI. The tip eventually led to Mondore’s arrest. He received a sentence of 6 months jail time.

“It was him being an idiot that did it,” Claus said of her hacker. “When I passed all that information to the FBI, they said, ‘There’s a really good chance that we wouldn’t have caught him without this.’”

Despite what happened to her and the “too light” punishment Mondore received, Claus believes he’s not a monster. “He’s a human,” she told Bloomberg. “That’s what makes it scary.”

The post When a sextortion victim fights back appeared first on Malwarebytes Labs.

Converged SASE platform provides AI-driven Zero trust security and simplified, optimized connectivity to any network location or device, including IoT.Converged SASE platform provides AI-driven Zero trust security and simplified, optimized connectivity to any network location or device, including IoT.Read More