Securing Network Device Communications for Application Deployment
This turned out to be fairly light on the front end with the Network Device and Communication Security, this is a long but very important read, includes a huge range of threat types (Injections, embedded Scripting), and covers Security Threat Prevention and Breach Mitigation techniques.
Finishes with a Robust review of Password Evolution, Hacking / Cracking Techniques (and how we stay one step ahead of them!), and end with a huge coverage of social engineering techniques to get you to give up that sensitive info!
With that a quick intro into Network Device Types / Techniques to second the Infrastructure, then diving into the really fun exploits and prevention 🙂
Firewall (Software and Physical) Security
This comes both in the form of a Physical Appliance and the Firewall Software on a Server or PC, which I’ve found real world it is a mixed bag as to whether Servers will run their own Software Firewall or whether the Security is placed on the Physical Appliance.
At the basic level a Firewall (Software or Physical) will allow or deny traffic based on a set of rules that tells it whether it accepts traffic from certain IP Addresses (Layer 3) / Ports (Layer 4) / Applications or Services (Layer 7) – More modern firewalls are allowing for Layer 7 filtering based on websites / applications that is specific to well known applications such as Facebook Messenger / Youtube Videos / Netflix Streaming.
A good rule of thumb on the Firewall – Allow as little and well defined traffic as possible.
For example if a developer needs to access a Server on the LAN, you can either set a static rule that allows for their specific Host Public IP to be allowed to the LAN IP via a NAT statement “inbound” on the firewall, or if the Developer needs it be able to access it from many different geographical locations they should create a static “Jump Box” that they log into via Client VPN or RDP + 2-FA – Then this Jump Box with the IP that will not change can be added as the Static Source Public IP allowed Inbound.
Jump Boxes may also be on the LAN for a Developer as well, so that you can control their access into the Environment first, and then restrict it internally as well adding an extra layer of security.
One big item I would expect to see on DEVASC exam day – Firewalls should prevent ANY outside access to an untested Application on the Network!
You don’t want to find out the Application allows for Network Access to Crypto Ransomware after the fact, so lock that Application Down from Outside Network Access which goes back to the Internal Jumpbox on the LAN to then connect to the Application.
As the Application is Developed some Firewall Access will need to be opened, and the Development Environment should match the Production Environments rules as closely as possible once it gets towards the end goal, to catch any firewall related Application issues such as ports being blocked that is required by the Application.
Load Balancer Security
When it comes to Load Balancers it is more about the method you are using for Load Balancing Traffic on how you can mitigate the chance of a Security Issue.
To quickly review the different methods a Load Balancer uses for traffic:
- Persistent Sessions – The Load Balancer forwards traffic for open sessions to Server handling that session, almost not really “load balancing” traffic
- Round Robin – Usually a default method for load-balancing, this hands off traffic to a set of servers based on the “next” server, equal load balancing despite traffic load
- Least Connections – This is the best method of “load balancing” from an actual load sharing perspective, forwards traffic to the least busy server
- IP Hash – The Load Balancer sends traffic to servers based on the result of a Hashed Algorithm based on criteria like an IP Address or Protocol, goal is not to really “load balance” but to direct traffic to the proper Server
As a real world note, there are ways to secure Network Load Balancers, but for the purpose of the DEVASC it is looked at in a very high level / operational viewpoint.
That being said there are two different ways to Load Balance Application Deployments into Networks that allow for a layer of Security that has been previously discussed:
- Red-Blue Deployment / Load Balancing – This is a method in which the traffic can be “cut over” from one Production Environment to another, with the ability to cut back over if there are issues by directing traffic back to the original environment
- Canary Deployment / Load Balancing – This involves redirecting traffic for certain users of an application that is in Development for Testing, and once Tested the Load Balancer can use its usual methods of Balancing to all production users
This is all you really need to know for the DEVASC exam, but I did want to mention that Load Balancers are not just devoid of Security Features, however in terms of what matters to Developers like us this is what we care about in terms of load balancing!
DNS (Domain Name System) and Reverse Proxy
This is just a quick review of what they do, as these will play more into the next section of Securing Applications from specific attacks, so some quick overviews of these:
DNS – This maps IP Address to Domain Names as you probably know, and just to state some obvious Security measures that are considered for this is preventing Rogue DHCP Servers on the network as these hand out DNS Servers that are generally internal IPs. For this reason Internal DNS is generally set to use either ISP DNS Servers or I will generally advise to leave a Secondary DNS pointed to Googles DNS as a backup if the ISP DNS gets decomissioned which is often confused with an ISP Outage when the IP Connectivity is there but the DNS Servers for the ISP Changed. I will halt my rant there on DNS for now.
Reverse Proxy – Quite literally a Proxy Server in Reverse, how a Proxy Server will make traffic from several Hosts appear to be coming from a single destination, at the remote destination there may be a Reverse Proxy where all IPs enter a single point but are distributed to several different Server – Though the response from all the different Server will look like they are being returned from a single IP from the Destination.
I actually have not worked with a whole lot of Proxy / Reverse Proxy before, so I cannot speak too much to Securing them, but wanted to define what it does for the following section I will be running through on Securing Applications.
Speaking of which!
Application Development Security / How to Secure your Application Data
When it comes to Securing Applications the two main components should be end to end Security by using HTTPS (SSL) connections rather than HTTP (Referred to as “Data in Flight” or “Data in Motion”), and also using Encryption on Data Stores that host the Data used by the Applications (Referred to “Data at Rest”), which would reside on a Server.
Encrypting Data
Security is a very robust topic that is barely touched in my class material beyond concepts for some reason, so I will need to look at other resources to see if I can fill this in more, however for now I’ll go though what Cisco Study Materials cover for DEVASC.
The first being Data should never be stored in Clear Text on a Database with the expectation that limiting access to a few users having access will secure it, as if a bad actor gains access through social engineering or phishing, then when the bad actor gets to the Database contents they should only see scrambled hash of user data rather than Clear Text information.
There are two methods of Data Encryption:
- Two Way Encryption – This is something like PGP or GPG, where Clear Text is encrypted using “Key Pairs” which is a Public Key which is publicly shared to Encrypt Data and then a Private Key used only by authorized parties to Decrypt the Data back to Plain Text based off the output used by the Public Key from the Pair
- One way Encryption – This is Data that is not meant to be Decrypted by an end user, but rather take Plain Text being entered by an end user like a Password, and Encrypt it for storage on a Database so that it the password cannot be retrieved if it is lost however if a bad actor gains access it cannot be harvested
Two-Way Encryption is used for Communication, one way Encryption is used for Data Storage, which includes using Key Management Services to store the Encryption Keys securely as having the Key to your encrypted Data stored locally or in a non-secure manner defeats the purpose of Encryption for sensitive information.
Software Vulnerability
Being that Developers may not also have expertise in Data Security, there are several tools that can be used to scan code for possible vulnerabilities, which include pieces of software such as “Bandit” / “Brakeman” / “VisualCodeGrepper” to review YOUR code however there could also be Security Vulnerabilities in Libraries your code uses.
There is also some things that cannot be helped like the notorious “HeartBleed” exploit that was found in OpenSSL which is what most of the Internet uses, as well as an exploits that are found in existing systems Hardware such as “Meltdown” that effected multiple Vendor Processors that was used in almost every device type in use.
If you are not familiar with these EPIC exploits, give them a read on WikiPedia:
https://en.wikipedia.org/wiki/Heartbleed
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
Point being – If you are not the Security Person responsible for keeping up to data on these types of Vulnerabilities then someone in your Development Team or Organization should be – Even if that means hiring an Outsourced Security Person like a PenTester.
One excellent resource for all things Exploits and Security Attack Vectors – OWASP!
OWASP is a Security Project with Paid Memberships and Donations for Public info, one great read is the “Top Ten Web Application Vulnerabilities” found here:
https://owasp.org/www-project-top-ten/
There are exploits on there I never would have thought of, but one of them which will also be discussed here, however back on track to finish off my Study Group stuff 🙂
Storing too much data
Bad actors cannot get data you don’t store, so its a good practice to limit the information stored to identify someone, such as the last 4 digits of a Social Security # or the last 4 digits of a Credit Card for recurring payments – The first portion should be encrypted!
However outside of this, if you don’t NEED Data, don’t store it for others to steal.
Storing Data in the Cloud
Though Cloud Security is probably better than most Enterprises security for Data Storage, it is still stored in Servers that can possibly be accessed by Employees, its kind of a flimsy point as any Public Cloud hosting customers Data are probably as Secured as just about possible but it is something to consider when it comes to Security.
Roaming Devices
This is something that I assume anyone taking the DEVASC realizes, but anyone using a Google or Apple device is likely having their data backed up to a Cloud, and if you ever lose that phone or PC the amount of Sensitive Data on it should be minimal if any.
This means texting yourself a PIN # to your Credit Card to remember it, taking pictures of a Password as a way of storing it, there are mobile applications such as KeePass to encrypt passwords even on mobile phones as well as Laptops.
Best Practice for Data Transport
There are three different ways of Transporting Data that are secure and should always be used in place of their Plain Text counterparts:
- HTTPS rather than HTTP – This was originally SSL but is now more TLS (Transport Layer Security), as TLS provides stronger Ciphers and Authentication
- SSH rather than Telnet – SSH Provides Encryption of communications, so packet sniffers cannot see what data is being passed, whereas Telnet packet will show clear text in every packet received on something like WireShark
- VPN – This is the most secure way to connect to an environment and provides as much or minimal security as you want (such as DES vs AES-256 Encryption), as well as using several Authentication Mechanisms including Certificates / Authentication Servers / 2-Factor Authentication on top of the end-to-end Data Encryption
A rule of thumb with Data Transmission is to assume that someone is sniffing every packet you send, so in some situations it may be perfect fine to use HTTP if playing with API’s in Postman to “GET” Chuck Norris jokes from CNIDB or using Telnet to your home lab routers – However from a business perspective this should not be acceptable.
What is a SQL Injection, how to identify a SQL Injection, and how to Prevent one
A SQL Injection is a code Injection Technique for Data Driven Applications, in which malicious SQL statements are inserted into a data field, which aims to dump the Database from a Server to the Attacker upon execution. This type of exploit must use a vulnerability in Software itself, where a string literal escape character is embedded in a SQL statement or a user statement is not “Strongly Typed” in the statement.
Strongly typed input means using a " rather than a ” in a statement, as a ” is considered a weak or loosely typed character in programming language.
SQL attack allow the attack to:
- Spoof Identities
- Tamper with Existing Data
- Cause “Repudiation Issues” such as voiding a transaction or changing values
- Dump all Data from a SQL Database to an attacker or just to do it
- Become a Rogue Admin of a Database Server
These are prevalent in Web Services or Web Page attacks that have user logins, as this is a way to input a malicious line of code that will be executed in the SQL Database by design of the login process, which is unknowingly run on the SQL Database.
The how it happens with SQL Inject attacks
One example is grounded in the 1=1 is always true SQL, and taking an example of the UserID (UID) input to a login, if there is nothing in place from preventing “wrong” data input someone code type in something like “2020 OR 1=1” as the UID.
The SQL Database will search the UID or UserProfile Database for a match, and being the “OR 1=1” will be always be true, it will return the entire UserProfile table in the SQL Database if not protected from a simple attack such as this.
A more complex variation of this might be entering a username / password of:
” OR “”=”
” OR “”=”
Which the SQL Database may add its own ” to the statement so it would read:
Username=”” OR “”=”” AND Pass=”” OR “”=””
However SQL will not see it as it is shown color coded here, showing the input VS what SQL Adds to the Input Statement, so this login will be Always True and succeed!
Yet another example is tied to Batched SQL Statements with a SQL Injection, where multiple SQL Statements are separated by semicolons (;), an example input:
dave; DROP TABLE UserProfiles
SQL might process this as something like:
FROM Users WHERE UID = dave; DROP TABLES UserProfiles;
Aaaaaand its gone!
This is where “Strongly Typed” input is critical to use even on Internet Forums, as there may be a comment with a JavaScript based attack waiting for a Weak or Loose typed escape character to Trigger its execution, so literally “quoting” a forum comment could trigger the code to execute in that comment when you could have type it Strongly saying:
“some quote” – Weak or Loosely Type
"some quote" – Strongly Typed
There are some crazy injection exploits that can use this all over internet forums, the OWASP Top 10 Exploits is a highly recommend read that I linked to above!
How to Detect and Prevent SQL Injection attacks
Open Source tools “SQLmap” and “SQLninja” are tools that can test for these vulnerabilities against a SQL Database and the Applications that use them, and some raw source code Security Analysis Tools called SAST (Static Security Application Testing) tools, which can test for several different attack types like SQL Injections / Buffer Overflow Attacks / Etc.
Preventing attacks might start with working with Database Firewalls that will filter out “wrong” input such as the above demonstrations, detect multiple incorrect SQL Queries and prevent them from running against the Database, that can detect these “Always True” statements or UNION Blocks like DROP TABLES inside a request.
Using “Prepared Statements” with Variable Bindings AKA Parameterized Queries is the foundation on which a SQL Database is built, as it pre-defines SQL Code so that the Database can tell Code from User Data Input – This works because it separates the statement and the query so a user input statement cannot trigger a Query.
So when someone enters an “Always True” type statements, it will go through a validation check of the input data, which will find that it is just an invalid request rather than triggering the execution of the SQL Database function.
Stored Procedures is another way to mitigate attacks where SQL Databases where Parameters are automatically Parameterized, which is essentially the Same as Prepared Statements mentioned above, the difference being Stored Procedures are stored inside the SQL Database and called by the Application itself so it can be as effective depending on your companies need for one over the other (Static vs Dynamic “Variable Binding”).
Stored Procedures however carry more risk because of the “Roles” assigned by SQL as “db_datareader” / “db_datawriter” / “db_owner” which can become susceptible to permission levels of these roles leading to “db_owner” being used to allow certain application to work – So if a Breach were to occur the Attacker is the “db_owner” once in.
Whitelist Input Validation is a mechanism that can built into a SQL Database to prevent input parameters from targeting things like Tables or Columns, by detecting input that isn’t expected / legal locations for bind variables. This prevents user input using “illegal parameters” from making it to the SQL Database for execution.
This is kind of abstract to me honestly, but how I am understanding it is kind of like assigning a Python variable of a = 1, only for SQL you take Table Names that can be appended to queries and predefine them so they cannot be misused.
OWASP has a cheat sheet for this:
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
In this link it goes on to explain that many SQL Database Admins make the mistake of “Blacklisting” common SQL Objects like the 1=1 Always True concepts, when proper and secure design is by whitelisting or identifying allowed items, thus implicitly Blacklisting illegal parameters (rather than doing this the other way around).
Though this should be done as a secondary or fallback mechanism (or design?) to a SQL Database design if other methods to prevents SQL Injections that are the Primary Line of Defense fail this is the secondary line of defense for your SQL Database.
Escaping all user-supplied input is a sort of last resort way of protecting against SQL Injection attacks, that uses “character escaping Schemes” to certain kinds of queries, which can be used to “escape all user supplied input” from being run against the SQL Database thus not allowing any sort of Injection attack based on User Input.
Additional Defenses to add Security Depth to the SQL Database
These are not primary defenses to prevent attacks, but ways to mitigate damage done or permission the attacker gains upon a successful attack.
Least Privilege
This is determining exactly what level of access is needed for the SQL Database users that access the Data, so maybe accounts only need “Read-Only” so an attacker might be able to access the Data (which isn’t a huge deal if Encrypted), but won’t be able to dump it and their hi-jacked account is only able to read a bunch of encrypted output.
This may also be in the form of instead of an Application running Queries directly to the SQL Database, it leverages a User Account with previously discussed “Stored Procedures” so it does not have a free-for-all access to code execution against SQL.
This also takes into account the privileges of the user logged into the OS itself, as the user should not be logged into a root / owner level account, this will mitigate damage done if a successful exploit penetrates your defenses.
Multiple Database Users
This follows the Least Privilege idea by assigning different DB Users with different Permission levels for different components of say a website, for example the user login of the Application may use one DB User with Least Privilege needed of Read-Only for logging in, while the sign up page / input uses a separate user that has “write-only” privilege only to “Write” to the Database but no other permission to change or delete things within the SQL Database – This distributes the vectors of attack while also limiting the scope of access / damage the attacker can cause.
SQL Views
This is yet another layer of Granularity where you can assign Views to Users and their Roles so that they can only access Sub-Sets of the Database that they NEED to access instead of running Queries again the DB as a whole (all tables / columns)
With all of this in place, SQL Injection Attacks may not be stopped all together, but can be extremely limited in scope if they do somehow succeed.
How to secure your Applications – With the use of the OWASP Tools / Projects!
OWASP (Open Web Application Security Project) has an extensive set of Tools and Projects that the entire community of members help to keep the bad actors out of their applications, and here I will review some of these different items.
First to start with some Tools and Projects for Developer Security:
- Tools – ZAP (Zed Attack Proxy) looks for vulnerabilities during development, Dependency Check looks for vulnerabilities in code, DefectDojo helps to streamline the testing process
- Code Projects – ModSecurity Core Rule Set (CRS) provides generic attack detection rules that can be used with web application firewalls, CSRFGuard helps to prevent Cross Site Request Forgery
- Documentation Projects – This includes the “Top Ten” list mentioned above, the Cheat Sheet series which explains ways to mitigate issues, among others!
Reviewing some of the Top Ten items on the OWASP List and what they do!
SQL Injection Attack
Already covered in painful depth 🙂
CSS (Cross-site Scripting)
This is User Submitted content that isn’t sanitized and is displayed to other users, such as embedding this code in a forum comment, and when users view the comments of that forum it performs some malicious attack.
This code or script executes against your machine, which can range from stealing your sessions cookies / redirecting your connection to another machine, to forcing your machine to perform actions as well.
I’ve actually had this happen to me on my PS4 on YouTube when going through very obscure music videos that are user created rather than a popular artists channel, just browsing suggestions, and suddenly I saw someone log into my YouTube session.
Given it was my PS4 and and my YouTube account it was a huge WTF moment, I had no idea what that was until today actually in reading that content, crazy.
Reflected XSS Attack
This is an attack where Malicious code is embedded in a URL (URL encoded Script) which looks like a line to a website, but includes a malicious script that mimics search results, for example:
loopedback.com?search-terms%2Script46%37f730wn3%byAv1ru$
So its different from a Phishing or Spear Phishing attack in the way that the true URL cannot be viewed by hovering over the link, because they will match from what is displayed and where it goes however the script is executed immediately upon clicking the URL with the embedded malicious code.
How do you prevent these types of very well hidden attacks?
The straight forward answer is to sanitize content where possible, and if it cannot be sanitized, do not allow it to be displayed.
OWASP suggests not items to be displayed in the follow locations:
- Inside Script Tags
- Inside Comments
- As part of attribute names
- as part of tag names
- in CSS (within style tags)
You can display the contents in some locations if its sanitized:
- The Content of an HTML Tag
- The value of an attribute
- A variable within your Javascript
Some tools made available publicly can assist in sanitizing content:
https://github.com/mganss/HtmlSanitizer – HTML Sanitizer
https://owasp.org/www-project-java-html-sanitizer/ – OWASP Java Sanitizer
https://pypi.org/project/bleach/ – Python Bleach
Cross Site Request Forgery (CSRF)
A similar attack to Cross-Site Scripting sometimes referred to as “Sea Surf” shares the similar nature of the target executing the code without knowing it, the difference is that this attacks intent is to use your identity to access sites like Banks, Paypal, e-commerce, and use your authenticated browser settings to log in as you to change the password and joy ride it into the ground (Virtual Identity Theft).
If you have ever been through ID Theft in real life, its a total nightmare to deal with, however you can prove you were not in some different geographical location where all the charges are happening. However with Virtual Forgery, the victim is very unlikely to realize what has happened or how to prove it wasn’t them, and if you bring it a step further for US Residents if someone hi-jacks something like Turbo Tax to get your Tax Return sent to their bank account the IRS is not going to re-issue a second Return.
These attacks are extremely hard to prevent, however they can be mitigated by turning on 2 Factor Authentication on every site you use, where you must approve login from your phone or an Authenticator App like Google Auth, DUO, Etc!
You can also use “Hidden Cookies” when it comes down to exam day, this is called a CSRF Token, though in real life practice 2-FA / Strong Password / Different Passwords / using encrypted Password Managers like KeePass will go a long way.
Like SQL Injection it may not be impossible to prevent unless you power the server off, but there are mitigation steps that can dramatically reduce the damage done outside of just using “Hidden Cookies” that are just common sense, as you will not see these attacks happening unless you have mechanisms in place to alert you of abnormal activity!
The Evolution of Password Systems
From the very first password ever used to secure a computer system to the Multi-Factor Authentication systems we have in place today (Credentials, DUO Auth, Certificates) its been a long journey of the good guys trying to stay one step ahead of the bad guys.
Plain Text Passwords
Very straight forward, a username and a password, and it was stored on a system that was stored in a secured database in plain text. If someone gains access to that system, all credentials are plain text, when logging into a system you type in your username and password and if it matches the clear text database you are allowed into the system.
Password Hashing
This is the next step in Evolution is taking a plain text password, and running it against a Hashing Algorithm, which kick out an string of random characters, so if an attacker gains access to the system they will not receive a straight forward plain text password (however there are methods to retrieve the hashed password) and the end user can still use the plain text password input to the system and it will match the hashed result to verify it matches the stored hash to allow access to the system.
Deterministic
This is password hashing function that ensures the same password will always produce the same output, if this function was not in place to produce the same result every time the password is hashed, hashing would not work.
Salted Password
A salt is a chunk of random data that is added to passwords to add an element of randomness to the hashing / password combination, adding a layer of difficulty to cracking password by brute force guessing based on known hashing, and if different salts are used for every user password with the same hashing algorithm everyone could use the exact same password and they would all be incredibly complex and different!
This can protect against “Rainbow Table” Attacks where there are pre-computed combinations of re-used salts and hashes that can be used to guess passwords, so one important aspect of salting is not to reuse the salts between systems that may contain the same users or the password become much easier to brute force / rainbow table attack.
The last line of defense against this is to use long and complex passwords, so even with the correct hash and salt combination it may take years to guess, that is of course assuming there isn’t a key logger installed on your PC completely subverting all of that.
For this reason there was a need for extra layers of Authentication!
Single-Factor Authentication (SFA)
Single Factor Authentication is just that, a single point of proving who you are, which is unfortunately your login credentials and their strength / them not being reused.
This simply is not enough for most system anymore, as even if this is left for something like a utility site you log into to pay your bills, if this becomes compromised it can provide the attacker data to steal your real life identity or change things in that account just to be a pain.
Security is always a balance of convenience vs security, and unfortunately most people will choose convenience until they have their life put through a meat grinder by ID theft or some other malicious intrusion of their private life.
Two-Factor Authentication (2-FA)
This is credentials plus an extra layer of identifying yourself, commonly an email sent or a mobile phone that a text is sent to within a given amount of time, and with the right password strength and 2-FA notifications in place such as a text-based system this is often good enough to secure most systems even though it may be inconvenient.
I cannot stress enough that where possible with financial systems that 2-FA should be setup to a cell phone that cannot be hi-jacked during one of the above described attacks.
Multi-Factor Authentication (MFA)
This is multiple factors of authenticating your identity by your credentials, and at least two extra factors that may includes something you know, and something you have (like a phone that can receive SMS codes to Authenticate to the site).
Again I would advise using email for 2-FA, as if your session is being hi-jacked, this may be compromised as well whereas your phone likely will not be!
And finally to look at the other side of things – Cracking Passwords!
Cracking passwords is only as sophisticated as it has to be to gain access to the system, so its not necessarily quantum computers running salts and hash Rainbow Table attacks, but it could be just simple password guess or leaked login creds from other sites that had been previously hacked – When a site you have used has been hacked you should change all of your passwords used immediately or it WILL come back to haunt you.
Hackers do not just throw away username / password databases they work to acquire!
Password Guessing
This is attempting to guess a password to gain entry to the system, which is generally detectable by systems using “Clipping Levels” which is what a system considers the threshold between a user entering the wrong password and someone entering passwords repeatedly to guess the password, however the “Clipping Level” can be determined using test accounts to establish that threshold and guess passwords under the threshold of detection.
Generally this type of attack is thwarted by account lockouts, which prevents the continued attempting of guessing passwords.
Dictionary Attack
This is also a method of guessing passwords in an arranged listing of most probable passwords to succeed, which are common words with very slight variations or an extra digit on the end of a short word, which may be guess thousands or millions of times until it succeeds. This is not necessarily words from a Dictionary, but a list of well known / used passwords obtained through past data breaches.
Pre-Computed dictionary or Rainbow Table attack
This is a combination of running a Dictionary List of passwords through known hashing algorithms to produce the key hash, which the dictionary only needs to be right through the hash once to come up with the key needed to decrypt system passwords.
This type of attack can be thwarted using Password Salts as long as they are not re-used from previously compromised systems.
Social Engineering
This technique of gaining access to a system is based on a target “cognitive biases” in how humans make decision based on assumed attributes, which might mean they see a fake email from their supervisor asking for a password IMMEDIATELY, or a phone call from a “Regional Manager” that knows enough information to provide to cause someone to give up the information in a panic.
Other strategies might include gaining the persons trust enough to ask them for sensitive information like a password, inviting them out for a drink and either getting them intoxicated enough to give up their password, or enough personal information to blackmail them for system access – There really is no limit to how someone can be tricked into providing if not the password itself enough info to obtain it.
Some techniques might include gaining physical access to the network by pretending to be some kind of maintenance or inspector to gain access to sensitive areas where the core network components can be accessed physically.
There are 6 key principles of influencing a human:
- Reciprocity – We have a tendency to return the favor extended to us, for example flattening a coworkers tire only to be the person that shows up to help, then asking the next day for a system login to clock in on time or you will be fired this time!
- Commitment / Consistency – Some people have a tendency to honor their commitments whether in person or online, so if they get a pop-up on their PC saying “Please enter password to authenticate strength” even with the option to do it later, with enough persistence they will generally do it to preserve self image
- Social Proof – Based on the human behavior of staring at something happening, even if your not interested most people will stop what they are doing to repeat that behavior, this can be used to manipulate sharing info they normally wouldn’t (like sharing your password out loud to discuss how difficult / complex they are getting)
- Authority – This goes back to the Boss Email Emergency, the yelling over the phone Regional Manager, or possibly the blackmailing anonymous stranger with info to leak if you don’t give them your system access
- Liking – Likeable and charismatic people make excellent social engineers, as most people desire to bask in the glow of a likeable person acceptance, this may come at the cost of unknowingly providing them with info you’d normally not share
- Scarcity – Also known as FOMO (Fear Of Missing Out), people will do just about anything to get in on something they think is quickly disappearing, including giving up their life savings or system credentials
There are also 4 vectors of attack that build off social engineering:
- Phishing – A legitimate and urgent looking message that requires your credentials
- Vishing – Voice Phishing where a phone call is made to gain credentials through the help desk calling to confirm credentials to see if yours match those that were caught looking at inappropriate material
- Smishing – SMS or Text based Phishing to bait clicking a fake link and providing information to the person on the other end of that link
- Impersonation – The Maintenance person that needs to service a system to gain physical access to an otherwise secured area
Now for a quick review of Password Strength and how hard it gets to Crack!
There are a 3 different types of passwords generally used:
- mypassword – This is almost immediately crackable
- MyPassword1 – This is not much better and will take little extra time to crack
- tR1kk33p@sSw0Rd!# – Not hard to remember, takes 10 life times to crack
There are applications that can help identify weak to strong passwords, though these are generally built into websites when changing a password, its not a bad idea to have a centralized password Manager such as KeePass that encrypts all your passwords and you only have one master password to remember to open the Password Manager.
And that is it for the Security Portion of this weeks DevNet Study Group!
I was thinking that would be a lot more focused on building security into API Calls and things of that nature, but I am glad to have pen to paper, now onto the next week!
Until Next Time 🙂
The DEVNET GRIND! 