SSO is an umbrella term for any time a user can login to multiple applications while only authenticating once. It covers both federation and password vaulting which is more commonly known as “Enterprise SSO”. The main difference is that federation eliminates the requirement to use and remember passwords and Enterprise SSO doesn’t.
Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a Person in each application and presents that application with a token that says, " this Person is domain\johndoe or email@example.com". No password is required for the user to login to each system. Because of the trust between the two systems, the target application accepts this token and authenticates the user. The federation server passes that token using one of the standard identity protocols: SAML, OpenID, WS-Trust, WS-Federation and OAuth. The benefit to federation is security and authentication into both on premise and cloud applications.
Enterprise SSO is when the applications all still require that a password be sent to login, but the software handles storing it and automatically retrieving it for the user and inputting it into the application for an automatic login. The user still has a password for each system that must be provided to login, must be changed on a regular basis, etc.
I like analogies; in my mind, Identity federation is like an amusement park. With Enterprise SSO (ESSO), you get into the amusement park but still need a ticket for each ride (think Santa Cruz Beach Boardwalk). With federation, you get into the amusement park but have a wristband that every ride operator recognizes and lets you on (think Disneyland).
The simplest way to discover someone’s password is to have them tell you it. This can be done by persuading them to type it into a website you control (commonly known as phishing), by installing a keylogger (either hardware or software) on a computer, or by reading traffic on an unencrypted wireless or wired network. For intruders these methods have the great benefit that it does not matter how long or complex a password the user has chosen: the intruder can simply read it. Cracking of hashes/brute force If the intruder cannot obtain the password then he can simply use a program to generate billions of possible passwords (often using the same techniques as are suggested for choosing passwords) and try each of them against the account. The crudest way to do this is to simply attempt to log in using each generated password: the resulting flood of password failures should be easy for a system administrator to spot, but since attackers continue to use this approach it seems it is still reasonably successful. Attempts may be made against obscure authenticated services, such as SSH and LDAP, to reduce the chances of detection.
Brute force attacks are much less obvious if the intruder can obtain a copy of an encrypted password, for example if a system’s password file can be downloaded, if a hash has been included in a public file, or if an unknown machine can join an authentication group. Once the intruder has one or more encrypted passwords he can do the brute force guessing on his own machine (using modern hardware and algorithms this may take only a few minutes for short passwords), or even use a cloud service, and then return to login to the target once the correct password has been discovered.
Password recovery/reset systems
An intruder may not need to get the password from the user if he can persuade the authentication system to either mail it to him or change it to something of his choice. Systems to allow the legitimate user to recover or change a password they have forgotten can also let other people do the same. Helpdesk operators need to be particularly careful to check the identity of anyone asking for a password reset. On-line systems that rely on “secret questions” such as “name of first school” or “birthday” are trivial to defeat if that information can be found on a social network. Systems that send reminders to a backup e-mail address or phone number can fail if the user changes address or number allowing the abandoned backup to be registered by someone else. Educated guesswork It should be obvious that the same techniques used to guess the answers to secret questions can also be used to guess passwords. Anything based on something your friends will know, or that is available from a website, is a very poor choice as a password.
Reuse of Passwords
Most people now have many different accounts on different systems in both their private and work lives. Although best practice is to have a different password for every account, unfortunately it’s much more common to reuse the same password on different services. That means that an organisation doesn’t just have to worry about the above attacks against its own systems, it has to worry about the same attacks on all other systems where the same password has been used. This probably means that an organisation can no longer completely control whether its passwords are secure: it should also develop plans and systems to detect and respond when a password has been compromised.
Equipment and software often has standard pre-configured passwords which, of course, are well known to intruders. Such passwords should always be changed, though it can still be hard to find out where they may have been used. A related problem is where a password is set for the user by a local administrator. Unless the user is required to change the password to one that the administrator does not know, doubt can always be raised which of the two people who knew the password was actually logged in and responsible for the account’s activity. If there are reasons that users cannot be forced to change their passwords on first use then procedures need to be carefully designed and followed to ensure that suspicion does not fall on the wrong person.
Password embedded in code
Passwords are also sometimes disclosed by being included in scripts or programs. While this may appear an easy way to automate access to an interactive system it carries high risks of disclosure and alternatives should be used wherever possible. If there is no other alternative then the script or program must be very carefully protected against deliberate or accidental access. The worst possible outcome is for a script containing a plaintext password to end up on a public website.
SNMP enumeration is the process of using SNMP to enumerate user accounts on a target system. SNMP employs two major types of software components for communication: the SNMP agent, which is located on the networking device, and the SNMP management station, which communicates with the agent.
Almost all network infrastructure devices, such as routers and switches and including Windows systems, contain an SNMP agent to manage the system or device. The SNMP management station sends requests to agents, and the agents send back replies. The requests and replies refer to configuration variables accessible by agent software. Management stations can also send requests to set values for certain variables. Traps let the management station know that something significant has happened in the agent software, such as a reboot or an interface failure. Management Information Base (MIB) is the database of configuration variables that resides on the networking device.
SNMP has two passwords you can use to access and configure the SNMP agent from the management station. The first is called a read community string. This password lets you view the configuration of the device or system. The second is called the read/write community string; it's for changing or editing the configuration on the device. Generally, the default read community string is public and the default read/write community string is private. A common security loophole occurs when the community strings are left at the default settings: a hacker can use these default passwords to view or change the device configuration.
The simplest way to prevent SNMP enumeration is to remove the SNMP agent on the potential target systems or turn off the SNMP service. If shutting off SNMP isn't an option, then change the default read and read/write community names.In addition, an administrator can implement the Group Policy security option Additional Restrictions For Anonymous Connections, which restricts SNMP connections.
Prior to testing it's important to determine what parts of the application require authentication and authorization. Security testing should approach the application from both a non-auth and pre-auth perspective. The goal of the non-authenticated assessment is to identify any security risks which are openly exposed by the application. The authenticated assessment is to identify the security risks once a valid user logs in. For an authenticated assessment ensure that the project team provides credentials in advance.
Browser (e.g. Firefox, Chrome) Manual crawling of the application and support manual testing of the application. Firefox has a number of built-in plugins such as Web Developer and Firebug that can provide easily viewable information on the source including hidden fields and HTML parameters.
Burp Suite Pro Web proxying tool that supports automated crawling, intercept and manipulation of HTTP requests, replay, injections, randomness of session identifiers, etc. The pro version also supports passive and active scanning.
Nikto (Kali distro) Web server vulnerability scanner that can fingerprint the web server and identify any known vulnerabilities with the web server software or installed application components (e.g. Tomcat) residing on the web server.
Nmap (Kali distro) Port scanner that can quickly identify open application ports on the systems as well as fingerprint the services bound to each port. Nmap additionally provides power in the NSE scripts which can probe services for detailed information, e.g. SSL supported ciphers.
Web Inspect Automated vulnerability scanning of web applications and web services. This is particularly useful for large, complex applications.
SQLmap (Kali distro) SQL injection and blind SQL injection tool used to pinpoint and execute proof of concept SQL injections.
Dirbuster (Kali distro) Brute-force directory guessing to find hidden web interfaces (e.g. admin pages, server status pages).
In order to gain better understanding of the risk associated with a vulnerability, one must gather contextual information related to an application's use.
For example, a cross-site scripting (XSS) vulnerability found post-authentication on an internal app accessible to only 10 employees within the organization will have a lower risk of exploitation than a pre-authentication XSS found on an Internet-facing app.
Questions to ask:
Business Purpose What business function does the application serve? How important is the application to the success of the business' goals?
User Population How many and what type of users are anticipated to use the application?
Data Types What type of data does the application process and/or store? Are there any PII or PCI elements?
Access Roles How many roles does the application offer and to what granularity?
Depth of the Application How many pages/components does the application consist of? [Crawl the application]
Web/application server What web and application server product does the application run on? [Fingerprint the front end]
Back end server Is data stored in a relational database (e.g. SQL) or flat file? [Fingerprint the back end]
Wireless access is enabled (and not required)? Wireless access is configured with open access? SSID suppressed/not broadcast? not ideal, will confuse users, hackers can find it.
MAC address filtering? not ideal, can be spoofed
Wireless access point uses WEP? Wireless passphrase is easily-guessable?
Bluetooth access is enabled (and not required)? Bluetooth pairing is not configured with authentication?
Does the DNS service allow unauthorized zone transfers? Is the DNS service vulnerable to cache poisoning? Does the DNS service allow unauthorized dynamic updates?
Is the system configured for NTP? Is NTP from an authenticated and authorized source?
Is FTP (21/TCP) enabled? Is anonymous FTP login allowed? Is TFTP enabled and not necessary? Is DHCP enabled and not necessary? Is DNS enabled and not necessary? Are unnecessary routing protocols (e.g. BGP, EIGRP, OSPF, RIP, VRRP, GLBP, VTP, DTP) enabled? Are other unnecessary protocols (e.g. echo, finger, chargen) enabled?
Is Telnet (23/TCP) running on the system? Is HTTP login enabled on the system? If HTTPS is enabled, are weak ciphersand protocols suported? If SSH is enabled, is SSHv1 supported? Is SNMP v1 or 2c supported? Is the administrative interface accessible over other clear-text protocols (e.g. rlogin, rsh)?
Does the application set redirect or forward targets within parameters? Are redirect(s) and forward(s) not validated by the server prior to redirecting the user?
Is the web server running outdated or unsupported software? Are built-in accounts still enabled or set with default passwords? Are built-in extraneous features (i.e.debug pages, sample code, demo/test functionality) accessible? Do application error messages reveal stack traces or debug information? Does the web server support unnecessary HTTP methods?
Does the application display object references (e.g. acct=100001) in the URL? Can a user access other application functions for which they are not authorized? Are administrative functions directly accessible via direct URI reference?
Is the application vulnerable to persistent (stored) XSS? Is the application vulnerable to reflected XSS? Is the application vulnerable to Cross-Frame Scripting (XFS)?
Are session IDs displayed in the URL string? Are session IDs vulnerable to session fixation? Are session IDs predictable? Are session cookies exposed to unauthorized access? Are sessions not properly terminated after a timeout or after a user-initiated termination? Does the application lack a proper logout function?
Does the application submit authentication credentials over an unencrypted connection? Does the application store authentication credentials in cleartext or weak format? Do application functions allow for anonymous enumeration of valid user accounts? Does the application allow for caching (i.e. remembering) of a user password?
Is the application vulnerable to SQL injection?
Custom-coded apps (both in-house and 3rd party), commercial of the shelf (COTS) app, web service, thick client/desktop app
Review initial security scoping documents, submitted by the project team, for completeness and accuracy.
Review system requirements packages to ensure that projects address enterprise and compliance requirements, standards, and best practices.
Review system design packages to assess the proposed system architecture, communication paths, roles, and functionality. Ensure you understand the as-is and to-be states.
Perform source code review of in-house developed applications to identify vulnerable code.
Conduct technical security testing of the application or system to identify vulnerabilities and determine risk exposure.
Work with the project team to address outstanding security findings. Complete your review providing a summary of the assessment, findings, mitigations, and recommendation.
Document a repeatable, comprehensive security testing methodology to evaluate the security controls for various technology types. This will better assure consistent, accurate testing of systems during the SDLC for projects.
Prior to any security assessment, have the PM/tech lead complete the scoping questionnaire. This will identify all in-scope and out-of-scope technologies and components and will allow the security engineer to estimate the level of effort to complete security testing. The in-scope items in the questionnaire will be reflected in the security test plan and confirmed by the PM/tech lead prior to security testing.