(Cross-posting from my organization’s blog – http://niiconsulting.com/checkmate/2014/03/insecure-implementation-guest-wireless-networks/)
Most large organizations provide wireless facilities for their guest, which may include vendors, consultants, business associates, employees from other regions etc.
Certain points should be considered while implementing a guest wireless network.
- Encryption in use
- Captive Portals or Guest Authentication
- Network Segregation
Finding the SSID of a Hidden wireless network
To simplify the connectivity for guest devices some organizations configure their networks without encryption i.e. ‘OPEN’. To prevent un-authorized entities from connecting to their networks most of these networks are configured as HIDDEN. As is well known, this configuration does not really provide any security. It is simply a method of obfuscation (Non-Broadcast Wireless SSIDs Why hidden wireless networks are a bad idea).
To identify the SSID of a hidden network you would need:
- Wireless adapter which supports packet injection (http://www.aircrack-ng.org/doku.php?id=compatible_cards)
- Aircrack-ng wireless suite (http://www.aircrack-ng.org/)
I will be using an Alfa AWUS036H adapter. This card is well supported by Aircrack-ng.
Just a quick post for my future reference on the differences between Trusted authentication and Mixed-mode Authentication used by SQL Server
- When a user connects through a Windows user account, SQL Server validates the account name and password using the Windows principal token in the operating system. This means that the user identity is confirmed by Windows.
- SQL Server does not ask for the password, and does not perform the identity validation.
- Windows Authentication is the default authentication mode, and is much more secure than SQL Server Authentication.
- Windows Authentication
- uses Kerberos security protocol,
- provides password policy enforcement with regard to complexity validation for strong passwords,
- provides support for account lockout,
- and supports password expiration.
- A connection made using Windows Authentication is sometimes called a trusted connection, because SQL Server trusts the credentials provided by Windows.
- When using SQL Server Authentication, logins are created in SQL Server that are not based on Windows user accounts.
- Both the user name and the password are created by using SQL Server and stored in SQL Server.
- Users connecting using SQL Server Authentication must provide their credentials (login and password) every time that they connect.
- When using SQL Server Authentication, you must set strong passwords for all SQL Server accounts.
- Three optional password policies are available for SQL Server logins.
- User must change password at next login
- Enforce password expiration
- Enforce password policy
- SQL Server Authentication cannot use Kerberos security protocol.
- Supports environments with mixed operating systems, where all users are not authenticated by a Windows domain.
I’ve been reading a very interesting paper over the weekend. It’s about exploiting ActiveX controls implemented in the Microsoft Windows OS (mostly IE).
The article is very lucid and easy to understand even for beginners. The paper is titled “ActiveX – Active Exploitation” and it’s written by ‘warlord’
Highly recommended. You can find the article here. I’m also adding it to my Reading Room for future reference.