Scanning the Internet for External Cloud Exposures via SSL Certs
demo1
1. Security Design Principles Except where otherwise noted all portions of this work are Copyright (c) 2007 Google and are licensed under the Creative Commons Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Editor's Notes
There are many specific security practices, but they all flow from a small set of well-accepted principles. We’ll go through each in detail.
The first principle, the principle of least privilege, states that to ensure security in a system, a process should only be given access to the most limited set of resources necessary to accomplish its task. That is, a user or a computer program should only be given just enough authority to get his or her or its job done. A common every-day example of the principle of least privilege at work in the physical world is the use of valet keys. A valet is someone that parks your car for you when you arrive at a hotel or restaurant, and people give their car keys to valets so that they can do so. Most cars that you buy these days come with special valet keys, and valets are given valet keys to park cars. The valet key allows to valet to only start the car and drive it to its parking spot. The valet key does not give the valet access to open the glove compartment or the trunk, where valuables might be kept. The idea is to give the valet access to only those resources necessary to do his or her job of parking the car. If we were to attempt to design a valet key system for an automobile even better, we might limit the number of miles that could be driven with the valet key! Similarly, we should follow the same principle when designing our computer programs. If a web server is responsible for serving files to web users, the web server should only be given access to the set of HTML files that the web server is to serve. By following this approach, if the web server is broken into, and the attacker is able to access a command shell, the most that the attacker would be able to do is read the HTML files. An example of how attackers can infiltrate a system that does not correctly take advantage of the principle of least privilege is bad set-uid scripts. On UNIX systems, sometimes it is necessary to elevate the privilege of a process. For example, when a user wants to change her password, the “passwd” program that is used to do this must make changes to the system password file once it authenticates the user. The only user that typically has access to modify this file that contains all of the usernames and passwords of all the users in the system is the administrator. But in order for the passwd program to work, the passwd program itself must be given administrator privileges to change the password for the user’s account once the user is authenticated. The passwd program is said to have its uid, or user id, set to root (the administrator account) when it runs. That is, regardless of which user runs the passwd program, the program is executed with elevated privileges (that of root instead of the regular user) to do its job. While the passwd program is an example of a program that absolutely must be set-uid to root to get its job done, there are examples of other UNIX programs that had a set-uid to root that didn’t absolutely need this privilege. These programs violate the principle of least privilege and lead to security vulnerabilities. For example, old version of the “lpr” command in the UNIX system was used to print files, and could be told to delete a file after it was printed. The old version of this command used to be set-uid to root because the file would need to be copied to a special “print spool” directory owned by root. So, it was possible to abuse “lpr” to delete other people’s files. The way this would work is you provide the name of some other users file to lpr and you also tell it do delete the file. Since lpr runs with root privileges, it copies the file into the print spool directory, and then deletes it. The root account is allowed to delete any file, and so it does not matter that you may not be authorized to delete the other person’s file– when you run lpr, you are given elevated root privileges, and are allowed to do anything that lpr will let you. Had the principle of least privilege been followed in the original design of the lpr command, the command would not be set-uid to root. Instead, a separate user account would have been created for the express purpose of printing files. The print spool directory would be owned by that account. The lpr command would be rewritten such that it would execute in two sub-processes. Sub-process 1 would be set-uid to the print-spool account and copy the file to be printed into the print spool directory, and sub-process 2 would be the traditional rm command that only allows a user to delete his or her own file. Least privilege can minimize the damage that can result from an attack by a trojan horse.
Root account gives the system admin complete access to all aspects of a system.
Due to the way the FileReader constructor works, it will attempt to access the file specified by the string argument relative to the current working directory. The attacker can traverse up the directory tree to the root directory and then access etc/shadow which contains a list of all usernames and passwords. How do we fix this in the code? We need to validate pathnames that are sent in a GET request…
Banks: security guards (guns), bulletproof glass, cash with dye, …
Fail-safe: even if one or more components of a system fail, there is still some level of security. If elevator power fails, they grip their cables by default. Let’s say that you are developing a client for a system that sends a password to an authentication server to check the password. If the authentication server is down, access by all clients should be denied by default
This is a fail-safe approach: If an attacker can force the web server to run out of memory, it crashes, but it does not do something insecure such as skipping an access control check or serving any document requested. Even though this is a fail-safe approach, forcing the web server to run out of memory can result in DoS attack.
SimpleWebServer will continuously read data from /dev/random/ until the web server runs out of memory and crashes.
Check the file length of the requested file and if it is below a pre-defined max (some percentage of available memory), serve the file, else error. Problem: /dev/random is a special file: f.length() returns 0 since it does not actually exist on disk Don’t store the file in memory – just stream the bytes incrementally. Again, /dev/random would tie up the server forever with the one request. No other clients would be serviced. (this is not multi-threaded) Don’t store in memory, and impose a download limit: this will work… Only send MAX_DOWNLOAD_LIMIT bytes to the client before stopping. This deals with the /dev/random issue, but if a client requests a large file, it might get cut off in the middle of a download resulting in file corruption.
For example, Windows traditionally ships with many (network) services on by default (i.e, IIS!). Vulnerabilities become available to attackers immediately after the system is installed and set up! To prevent this, create a “hardened” version of your system, and new installations should be made based on the “hardened” version.
A choke point is a centralized piece of code through which control must pass.
User’s don’t know what they need: stock quote example: users might say that they just want their quotes fast and don’t want them to be encrypted (i.e., since the information is public anyway), but a bad guy might change the content and force people to do trades they wouldn’t want to do otherwise since few people will actually double check the stock quote info.
S ecure S ockets L ayer: The leading security protocol on the Internet. Developed by Netscape, SSL is widely used to do two things: to validate the identity of a Web site and to create an encrypted connection for sending credit card and other personal data. Look for a lock icon at the bottom of your browser when you order merchandise on the Web. If the lock is closed, you are on a secure SSL or TLS connection
![Security Design Principles ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)