Some famous security vulnurabilities

1. RSA signature forgery by unprivileged users.

RSA signatures are used to authenticate the source of a message. To prevent RSA signatures from being forged, messages are padded with data to ensure message hashes are adequately sized. One such padding scheme is specified in the Public-Key Cryptography Standard #1 (PKCS-1), which is defined in RFC 3447. Many RSA implementations may fail to properly verify signatures. Specifically, the verifier may incorrectly parse PKCS-1 padded signatures, ignoring data at the end of a signature. If this data is ignored and a RSA key with a public exponent of three is used, it may be possible to forge the signing key’s signature.

Note that any application that uses RSA signatures may be affected by this vulnerability. This includes, but is not limited to, SSH, SSL, PGP, and X.509 applications.

http://en.securitylab.ru/notification/276087.php

http://www.mail-archive.com/cryptography@metzdowd.com/msg06732.html

http://www.mail-archive.com/cryptography@metzdowd.com/msg06537.htm

http://en.securitylab.ru/notification/276087.php

2. Telnet login vulnerability gives root access to unauthorized users.

/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c
3198
3199     } else /* default, no auth. info available, login does it all */ {
3200                   (void) execl(LOGIN_PROGRAM, “login”,
3201                                   “-p”, “-h”, host, “-d”, slavename,
3202                                   getenv(“USER”), 0);
3203     }

/usr/src/cmd/login/login.c
1397                            break;
1398
1399                  case ‘f’:
1400                            /*
1401                             * Must be root to bypass authentication
1402                             * otherwise we exit() as punishment for trying.
1403                             */
1404 if (getuid() != 0 || geteuid() != 0) {
1405           audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407           login_exit(1);     /* sigh */
1408           /*NOTREACHED*/
1409 }
1410 /* save fflag user name for future use */
SCPYL(user_name, optarg);
1411
1412 fflag = B_TRUE;

So if we supply a USER environment variable of “-f<username>” we can get in without a
password.

3. DNS server cache poisoning by unprivileged users

http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

http://www.infobyte.com.ar/demo/evilgrade.htm

4.Cross‐site scripting attacks, which allow attackers to execute scripts within the context of a user’s browser.

https://www.governmentsecurity.org/SecurityHackingNews/Sun_Alert_247046_Cross_Site_Scripting_XSS_Vulnerability_in_Sun_Management_Center_SunMC_Performance_Reporting_Module

5.Injection flaws, such as SQL injection attacks in which SQL commands are sent as
part of input data.

6. Poorly managed authentication in distributed applications that allow, for example, a
victim’s username and passwords to be stolen

7. Insecure communications, in which private and confidential information is sent in
unencrypted or easily decrypted form

Secure programming Tips

Some of the programming  mistakes lead to serious security issues (vulnerabilities). This programming errors very important to deal with because these costs companies a lot in terms of money, customer confidence on product. Some of these may cause

-> threaten the confidentiality of private information

-> threaten the integrity of data and operations

->threaten to disrupt availability of critical systems

-> Escalate the privileges of unauthorized users

1. Check for integer overflow.

While calculating Fibanoci seris or factorial, the next value may exeed the MAX interger value, make sure to check for the overflow condition.

2. Create temporary file with mkstemp(3C) mkdtemp(3C)

Most common progrmming mistake is creating temporary file with a well known names or predictable names like tmp.$$ or tmp.pid. If a malicious user predicts this temp file pattern, we will create them in advance and try to manage them with his own data or cause application crash.

3. Buffer overflow issues with string operations.

people say use strn series functions for string operations.The strncpy() functions are preferable to strcpy() because they accept boundaries for buffers that can be checked against. However, they are still vulnerable to certain attacks if used improperly:

a. passing of NULL for src or dest causes exception
b. ‘count’ size parameter is often incorrectly passed in
c. not guaranteed to have null terminated string upon exit

Make sure the buffer and bounds are the proper size to hold the source string plus a NULL character.

4.Improper Input Validation

5. Web application security : For more information about application security, especially Web
applications, see the Open Web Application Security Project (OWASP) at http://www.owasp.org.

http://nob.cs.ucdavis.edu/~bishop/secprog/index.html

http://sunsite.uakom.sk/sunworldonline/swol-08-1998/swol-08-security.html

WEP, WPA and WPA2

WEP  

The Wired Equivalent Privacy (WEP) protocol was defined in the late 1990s for encrypting wireless communications. Within several years, flaws were found in the algorithm, and tools are available today to break WEP encryption in minutes.

How to break WEP encryption?

http://docs.lucidinteractive.ca/index.php/Cracking_WEP_and_WPA_Wireless_Networks

http://www.smallnetbuilder.com/wireless/wireless-howto/30114-wep-crackingreloaded

http://forums.remote-exploit.org/tutorials-guides/1556-newbie-guide-how-crack-wep-key-step-step-another-newbie.html

http://lifehacker.com/5305094/how-to-crack-a-wi+fi-networks-wep-password-with-backtrack

Wireless networks should use the Wi‐Fi Protected Access (WPA) or WPA version 2 (WPA2) encryption, both of which are stronger than WEP.

SSL and TLS

SSL – Secure socket layer
TLS – Transport layer security

The original Secure Sockets Layer (SSL) implementation was developed in the early 1990s by the Netscape Communications Corporation to secure HTTP, which sends its data as plain text over the Inter- net. The first official release was version 2.0, which gained widespread acceptance despite some design
problems with the protocol.

In the late 1990s it became apparent that SSL 2.0 was not secure. Netscape began working on SSL 3.0. In conjunction with Netscape, the Internet Engineering Task Force (IETF, the Internet standards governing body) began work on standardizing SSL, a project that became known as TLS (Transport Layer Security).

SSL 3.0 was not developed as rigorously as TLS, so it became available sooner and quickly overtook SSL 2.0 as the industry standard. TLS was finalized in 2000, providing the first standardized protocol for SSL. Although SSL 3.0 is still in widespread use, it is mostly obsolete for new development since almost all modern browsers support TLS.

The differences between TLS protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0).

SSL is simple in theory (keys are exchanged using public-key cryptography, communication is done using symmetric-key cryptography), the actual implementation is quite complex. This section briefly covers the details of establishing an SSL connection and communicating using that connection.

SSL hand shake diagram http://en.wikipedia.org/wiki/Secure_Sockets_Layer