Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Serverless security

4Dotnet
October 08, 2018
30

Serverless security

4Dotnet

October 08, 2018
Tweet

Transcript

  1. The Serverless Times Don’t let your serverless solution become the

    frontpage news Security is important! Ede, Tuesday, October 2, 2018 2 cents By @Jan_de_V at 4DotNet
  2. @Jan_de_V Facebook account hacked with Man-in-the- Middle Attack, STILL WORKING

    Facebook is the largest social network, where seems to be every internet user has its account, time-to-time world class hackers, security researchers find vulnerabilities, loop holes in the social network, some inform Facebook security team to get paid and some sell that online, but a vulnerability found in Facebook on 5/9/2013 still not patched and working right now. How you can protect yourself from this Vulnerability: You can be on safe side by using https on your browser while using a facebook app, so for that you can use “HTTPS Everywhere” Browser Extension for automated security, which will protect your personal information while sending or recieving. http://www.hackersnewsbulletin.com/2014/03/can-hack-facebook-account-man-middle-attack-still-working.html
  3. @Jan_de_V Man-in-the-Middle (MITM) Attacks: What They Are And How To

    Prevent Them? A Man-in-the-Middle (MITM) attack is a form of attack that allows a hacker to secretly intercept a wired or wireless connection between two parties who believe they are communicating safely and directly with each other. When performed successfully, a MITM attack allows the hacker not only to eavesdrop on the communication between the victims but also tamper the data they exchange with each other. Most importantly, it may give the eavesdropper full access to the victims' valuable information (login credentials, financial information, and so on)…. …How to Prevent MITM Attacks? There are two common ways you can defend your network, web application or website against MITM attacks: by using authentication certificates and HTTPS protocol. When it comes to protecting web services, the best way is to use an HTTPS protocol instead of a much less safe HTTP. Using SSL/TLS certificates, you can upgrade the protocol of your website from HTTP to HTTPS and keep all the connections set between the website and end users encrypted and secure. https://www.equities.com/news/man-in-the-middle-mitm-attacks-what-they-are-and-how-to-prevent-them
  4. @Jan_de_V $uri = 'http://mysubdomain.mydomain.nl' $password = 'SomeStrongPassword' # Create a

    new Service Principal in your Azure Active Directory $app = New-AzureRmADApplication -DisplayName 'MySNP’ -HomePage $uri -IdentifierUris $uri -Password $password New-AzureRmADServicePrincipal -ApplicationId $app.ApplicationId # Assign the Contributor role to the new service prinicipal New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $app.ApplicationId
  5. @Jan_de_V public static class LetsEncrypt { [FunctionName("letsencrypt")] public static HttpResponseMessage

    Run( [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = "letsencrypt/{code}")] HttpRequestMessage req, string code, TraceWriter log) { log.Info($"C# HTTP trigger function processed a request. {code}"); var content = File .ReadAllText( @"D:\home\site\wwwroot\.well-known\acme-challenge\" + code); var resp = new HttpResponseMessage(HttpStatusCode.OK); resp.Content = new StringContent(content, System.Text.Encoding.UTF8, "text/plain"); return resp; } }
  6. @Jan_de_V "acmechallenge": { "matchCondition": { "methods": [ "GET", "POST" ],

    "route": "/.well-known/acme-challenge/{rest}" }, "backendUri": "https://%WEBSITE_HOSTNAME%/api/letsencrypt/{rest}" }
  7. @Jan_de_V Protect Against Secrets in Git Repositories I recently got

    burned by inadvertently committing secrets to a github repository. This post just outlines one potential solution to avoiding repeating that experience. Within minutes (or maybe it was an hour–not sure) of when I pushed the code to github, I got an email from AWS that, paraphrased, read: “We have found your AWS keys in a github repository. Please fix the problem and DON’T DO THAT AGAIN.” Almost immediately after, I got another email from AWS thanking me for deleting my keys. AWS apparently scans GitHub repositories for AWS keys and has a system (I suspect somewhat automated) for removing the exposed keys. I deleted the GitHub repo and did some local checking and, in retrospect, realized my mistake. Git had dutifully saved the entire history of my project including a version of one file with AWS keys in it. Upon pushing to GitHub, the keys were there in the history. I breathed a sigh of relief that no harm had been done. https://seandavi.github.io/post/2017/12/protect-against-secrets-in-git-repositories/
  8. @Jan_de_V { "IsEncrypted": false, "Values": { "ClientId": "myClientIdGuid", "ClientKey": "TheBase64SecretKey",

    "CosmosEndpoint": "https://kvminify.vault.azure.net/secrets/cosmosEndpoint/[someIdentifier]", "CosmosAuthenticationKey": "https://kvminify.vault.azure.net/secrets/cosmosAccountKey/[anotherIdentifier]", "CosmosConnectionStringSecret": "https://kvminify.vault.azure.net/secrets/CosmosConnectionString/[andAnotherIdentifier]" } }
  9. @Jan_de_V // Fetch configuration values var clientId = ConfigurationManager.AppSettings["ClientId"]; var

    clientSecret = ConfigurationManager.AppSettings["ClientKey"]; var connectionstringUrl = ConfigurationManager.AppSettings[secretKey]; // Create a Key Vault client with an Active Directory authentication callback var keyVault = new KeyVaultClient(async (authority, resource, scope) => { var authContext = new AuthenticationContext(authority); var credential = new ClientCredential(clientId, clientSecret); var token = await authContext.AcquireTokenAsync(resource, credential); return token.AccessToken; }); // Get the API key out of the vault var secret = await keyVault.GetSecretAsync(connectionstringUrl); return secret.Value;
  10. @Jan_de_V { "apiVersion": "2015-01-01", "name": "nestedTemplate", "type": "Microsoft.Resources/deployments", "properties": {

    "mode": "Incremental", "templateLink": { "uri": "[concat(parameters('templateBaseUri’), 'my-nested-template.json')]", "contentVersion": "1.0.0.0" }, "parameters": { "mySuperSecretValueForTheAppService": { "reference": { "keyVault": { "id": "[resourceId(subscription().subscriptionId, parameters('resourcegroup’), 'Microsoft.KeyVault/vaults’, parameters('vaultName'))]" }, "secretName": "MySuperSecretValueForTheAppService" } } } } }
  11. @Jan_de_V { "$schema": "https://schema.management.azure.com/schemas/2015-01- 01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "mySuperSecretValueForTheAppService":

    { "type": "securestring" } }, "variables": {}, "resources": [ { //... "tags": { "displayName": "appSettings" }, "properties": { "MySuperSecretValueForTheAppService": "[parameters('mySuperSecretValueForTheAppService')]" } } // ... ] } ], "outputs": {}
  12. @Jan_de_V Admin Accounts With No Passwords at the Heart of

    Recent MongoDB Ransom Attacks The recent wave of ransom attacks on MongoDB databases happened because database owners forgot to set passwords on their administrator accounts, according to Davi Ottenheimer, Senior Director of Product Security at MongoDB, Inc. "We have been monitoring the situation closely to help investigate and provide assistance," Ottenheimer wrote in a blog post. "We’ve reviewed these details to understand where and when users left systems insecure – connected to the Internet with no password on their Administrator account – and who is attacking them," he said. Recent wave of MongoDB ransom attacks ruined 26,000 DBs The recent wave of attacks came to light two weeks ago. Three new actors have been busy taking over MongoDB databases and rewriting their content with ransom demands. Attackers ruined over 26,000 MongoDB servers, with one group alone being responsible for over 22,000 ransom demands. This wave of ransom demands came after a period of inactivity from MongoDB ransom groups. At the start of 2017, several groups have held for ransom over 50,000 MongoDB databases. Victor Gevers, one of the researchers who's been tracking the attacks, confirmed the findings of the MongoDB investigation to Bleeping Computer earlier today. This puts the blame for this second wave of MongoDB ransom attacks on the shoulders of database owners solely. https://www.bleepingcomputer.com/news/security/admin-accounts-with-no-passwords-at-the-heart-of-recent-mongodb-ransom-attacks/
  13. @Jan_de_V Reddit IT admin accounts compromised in site hack Attackers

    access old backup file, internal systems. One of the most popular discussion forums on the internet, Reddit, today disclosed a data breach in which some user information was leaked. In a post mortem, Reddit said the attack was serious and resulted in an old database backup and a newer set of "email digests" sent to users being accessed. The backup file contained usernames, hashed and salted passwords, email addresses, all public content and private messages from 2005 through to May 2007. The attacker was also able to gain read access to Reddit's storage systems, and used it to access "Reddit source code, internal logs, configuration files and other employee workspace files". However, they were unable to gain write access to Reddit’s systems and weren’t able to alter or delete any data. The attackers gained access via Reddit employee accounts "with our cloud and source code hosting providers". While Reddit uses two-factor authentication to protect staff logins, the challenge and response codes were transmitted out-of-band via SMS, which were intercepted by the hackers. “We learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept," Reddit founding engineer Christopher Slowe said. SMS 2FA continues to be widely used, despute being shown to be insecure. Staff logins will now be protected by token-based 2FA rather than SMS codes. Reddit said it will notify affected users of the data breach, and reset their passwords. Some Reddit users reported that they had already received extortion-based phishing emails that cited the hacked credentials. The emails quote the passwords taken from the 2007 database backup, and claim malware has been installed on users’ computers that is able to record what’s on the screen as well as activate the webcam. The phishers threatened to leak embarrassing recordings captured from the users’ computers to all their contacts, unless they paid a ransom. https://www.itnews.com.au/news/reddit-it-admin-accounts-compromised-in-site-hack-499495
  14. @Jan_de_V "accessPolicies": [ { "tenantId": "[reference(concat('Microsoft.Web/sites/', parameters(functionAppName')), '2018-02-01', 'Full').identity.tenantId]", "objectId":

    "[reference(concat('Microsoft.Web/sites/', parameters(functionAppName')), '2018-02-01', 'Full').identity.principalId]", "permissions": { "keys": [], "secrets": [ "get" ], "certificates": [], "storage": [] } }],
  15. @Jan_de_V var azStp = new AzureServiceTokenProvider(); var keyvaultClient = new

    KeyVaultClient( new KeyVaultClient .AuthenticationCallback(azStp.KeyVaultTokenCallback)); var secretValue = await keyvaultClient .GetSecretAsync($"https://{myVault}.vault.azure.net/", "MyFunctionSecret"); return req.CreateResponse(HttpStatusCode.OK, $"Hello World! This is my secret value: `{secretValue.Value}`.");
  16. @Jan_de_V var keyVaultClient = new KeyVaultClient(async (authority, resource, scope) =>

    { var authContext = new AuthenticationContext(authority); var credential = new ClientCredential(clientId, clientSecret); var token = await authContext.AcquireTokenAsync(resource, credential); return token.AccessToken; }); var azStp = new AzureServiceTokenProvider(); var keyVaultClient = new KeyVaultClient( new KeyVaultClient .AuthenticationCallback(azStp.KeyVaultTokenCallback)); Normal MSI
  17. @Jan_de_V Removing Unauthenticated calls to the Web API On 29th

    May 2017 the /search /tracks /albums /artists and /users (and related) endpoints will start requiring an access token, bringing them in-line with all other Web API endpoints. A detailed overview of the changes [can be found here.](https://developer.spotify.com/migration-guide-for- unauthenticated-web-api-calls/) Back in 2014 when we launched the current version of the Spotify Web APIs, we introduced new functionality and replaced two old web services: search and lookup. As the old web services didn’t support OAuth, we wanted to ease the initial transition for users by allowing unauthenticated consumption of the equivalent endpoints in the new API. Now we’re in 2017, Spotify’s Web API has greatly expanded and a vast majority of endpoints already require authentication. By authenticating you also gain improved rate limits and get access to our automated insights dashboards, which provide statistics on your API consumption and users who authenticate with your application. The affected endpoints will accept all forms of authentication, including client credentials. As before all endpoints can be tried out live before writing any code via our interactive API console. We understand that this update may create some work for you, so we want to ensure you have plenty of time to make the necessary updates to any outstanding unauthenticated requests. We’ve also created a guide to the technical changes you may need to make. Because the calls are unauthenticated we aren’t able to reach out to individuals. If you need help please do contact us via Twitter, GitHub or StackOverflow (tag Spotify). https://developer.spotify.com/community/news/2017/01/27/removing-unauthenticated-calls-to-the-web-api/
  18. @Jan_de_V Hackers can access the Nissan Leaf via insecure APIs

    Two security researchers have demonstrated security vulnerabilities in the Nissan Leaf electric car by using mobile management APIs supplied by the car manufacturer. The unsecured APIs allow anyone who knows the VIN of a car to access non-critical features such as climate control and battery charge management from anywhere across the Internet. Additionally, someone exploiting the unauthenticated APIs can see the car's estimated driving range. "The other main concern here is that the telematics system in the car is leaking all of my historic driving data," one security expert said in a blog post. "That's the details of every trip I've ever made in the car, including when I made it, how far I drove and even how efficiently I drove. This could easily be used to build up a profile of my driving habits, considering it goes back almost 2 years, and predict when I will be away from home. This kind of data should be collected and secured with the utmost respect for my privacy.“ Vehicle Identification Numbers are easily visible through a vehicle's windshield. In a blog and embedded video, the security researchers, Scott Helme and Troy Hunt, described the discovery by a third unnamed person who'd been attending a security workshop with them. Hunt, who is from Australia, then demonstrated how he was able to access Helme's NIssan Leaf -- even though he was 10,000 miles away in England. "What the workshop attendee ultimately discovered was that not only could he connect to his LEAF over the internet and control features independently of how Nissan had designed the app, he could control other people's LEAFs," Hunt wrote in the blog post. The APIs used to access Nissan Leaf cars work with Android or iOS devices. The security workshop attendee, Hunt wrote, went back to his hotel room the first day and proxied his iPhone via his PC, using Fiddler debugging software. "This takes a few minutes to setup and effectively what it means is that he can now observe how the mobile app talks to the online services. Jan then fires up the… https://www.computerworld.com/article/3036964/car-tech/hackers-can-access-the-nissan-leaf-via-insecure-apis.html