Top 5 server level vulnerabilities you must know!

Top 5 server level vulnerabilities you must know!

You might have heard some these vulnerabilities irrespective of domain you are from. These are the well known vulnerabilities which caught attention in social media within the duration of one year (April 2014 and April 2015) Have you ever thought why these vulnerabilities got so much of public/social media exposure?  If not you are at the right place to understand the reason behind it.

Heartbleed was an issue that affected various versions of OpenSSL. This is one such vulnerability which allows attacker to remotely read memory of the systems/servers where vulnerable versions of OpenSSL are implemented. The type of information that could be exposed through depends on number of factors; most cases could include sensitive information like private keys, usernames and passwords of various logged-in users, sessions, database strings and much more.

Since OpenSSL is the most popular open source cryptographic library used to encrypt traffic on the Internet and considering ease of exploitation, large amount of private keys and other confidential information exposed, this vulnerability got much exposure on internet even the CVSS score was 5.0/10.0

Shocking shellshock was discovered by Stephane Chazelas. This is a vulnerability in GNU’s bash shell that allows attackers to run remote commands (remote code execution) on a vulnerable system. GNU Bourne Again shell (Bash) is a shell and command language interpreter used as the default shell on major UNIX based systems like Mac OS, red-hat Linux and much more.

Most of you out there would be thinking that you have bash pre-installed on your systems, now are you guys vulnerable to this attack? Big no! If this bash is accessible on internet then you may vulnerable, let’s say Apache; where in it allow user to set environment variables remotely on that victims system through “mod_cgi”. Shellshock vulnerability not only allows to set few environment variables but also leverages attacker to run malicious code or commands remotely.

  • Poodle :: CVE-2014-3566 (October 2014)

This is the next variant on OpenSSL after Heartbleed. POODLE, it stands for Padding Oracle On Downgraded Legacy Encryption, this bug was discovered by Google Security team. This is such a vulnerability where in attacker can perform man in the middle attack and can easily extract bits of encrypted data using oracle padding. This vulnerability had problem in CBC encryption scheme as implemented in the SSL 3 protocol which was similar to BEAST attack.

This vulnerability was initially affecting the SSLv3 protocol but later it was reported that even TLS 1.0 and 1.1 are also affected. Even though the impact is high, CVSS score given is 4.3 due to easy of exploitation which is pretty much medium/difficult.

  • Ghost :: CVE-2015-0235 (January 2015) 

The GHOST vulnerability is a serious weakness in the Linux glibc library. This is a sort of buffer overflow attack affecting gethostbyname() and gethostbyname2() function calls in the glibc library.

This vulnerability allows a remote attacker to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application or to remotely take complete control of the victim’s machine without having any prior knowledge of any credentials.

  • Freak :: CVE-2015-0204 (March 2015)

Servers that accept RSA_EXPORT cipher suites put their users at risk from the FREAK attack, this allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data. The FREAK attack is possible when a vulnerable browser connects to a susceptible web server—a server that accepts “export-grade” encryption.

Unpatched OpenSSL, Microsoft Schannel, and Apple SecureTransport all suffer from this vulnerability. Note that these libraries are used internally by many other programs, such as wget and curl. You also need to ensure that your software does not offer export cipher suites, since they can be exploited even if the TLS library is patched.

More BUzz:

  • Mozilla said on its blog that “SSL version 3.0 is no longer secure. Browsers and websites need to turn off SSLv3 and use more modern security protocols as soon as possible, in order to avoid compromising users’ private information”.
  • Microsoft also announced that SSL 3.0 will be disabled across Microsoft online services over the coming months.

References:

https://securityblog.redhat.com/

 

Good To Go Live? [Part-1]

This post does not make you hacker overnight, or by this you cannot hack a website, this is not a shortcut to become a security tester. This article is purely for helping individuals in building secured applications.

If you are from infosec, you might be tired of listening to people asking, is application good to go live, can I push my code to production? Below are some of the easy steps for developers for developing a secured application and this would reduce efforts and time of security team on vulnerability assessment and penetration testing. It is always advised to have a proper code with certain validation and verification.

1. Authentication:

a) Don’t hardcode credentials: Credentials should not be saved within the application. To some extent it might be useful during development stage but strongly advised not to be saved within the application code.

b) Store Database Credentials Securely: The credentials must be stored in a centralized location as a separate database for which authentication is required.

c) Error handling on invalid credentials: Error Messages on invalid credentials for authentication must be clear and must not reveal any sensitive data against username enumeration or other available fields.

d) Account lockout against bruteforce attacks: Account lockout policy needs to be implemented to safeguard against brute force attacks for both the login and forgot password features. The account should be locked for a certain period of time say 24/48 hours or until manually unlocked from the application support

e) Browser memory: Credentials should not be retained in browser memory after logout. The credentials should be encrypted with base64 or any secured hashing mechanism.

2. Authorization

a) Access control checks: Make sure that there is a separate mediatory between different privileges with a principle of common security assistance on the application.

b) Least Privileges: Users of an application should not provide root access instead minimal privileges could be given. If not explicitly allowed then access should be denied.

c) Don’t use direct object references: Do not allow direct referencing to any files or parameters that can be manipulated to grant access to the resources. Privileged access should be assigned based on individual user identity.

d) Validated redirects: An attacker can get access to private content without authentication, if redirection are not validated properly.

3. Input Validation and Output Encoding (Text Fields)

a) Output Encoding: All output operations must contextually encode data before displaying it on browser.

b) Set Encoding in the Application: For every page in your application set the encoding using HTTP headers or meta tags within HTML. This ensures that the encoding of the page is always defined and that browser will not have to determine the encoding on its own.

c) Prefer White-lists Over Blacklists: All the input fields should have input validation. White listing input is the preferred approach. Data that meets a certain criteria must be accepted.

d) Tokens against Forged Requests: Applications must embed random token that is not known to third parties into the HTML form for preventing CSRF (Cross-Site Request Forgery) attacks. This CSRF protection token must be unique to each request. This prevents a forged CSRF request from being submitted because the attacker does not know the value of this random token.

e) File Uploads: While accepting files from the user make sure to validate the size of the file, the file type, the file-name, the file contents and where is it going to save as well as ensuring that it is not possible to override the destination path for the file.

f) Parameterized SQL Queries: SQL queries should not be created dynamically using string concatenation. Similarly, the SQL query string used in a bound or parameterized query should never be dynamically built from user input.

g) Terminate/abort invalid inputs: This is a safety and final strategy on unaccepted characters that occur as input, but if implemented poorly it might lead to Denial Of Service attack in which attacker can flood the system with unexpected inputs, forcing the system to expend scarce processing and communication resources on rejecting it.

4. Session management

a) Session fixation: Session tokens must be changed during login and must have different tokens for logged in and logged out states.

b) Session variables invalidation: Session variables should be invalidated in the server after logout or session timeout after a certain period of idle session.

c) Unique session variables:  Session variables must be unique and should not be reused for different accounts.

d) Strong session variables: Session variables should be random and must be of certain length which is not easily guessable by the attacker.

e) Secure cookie variables: Usage of secure cookie attributes i.e., Httponly and Secure Flags. The cookies should be set to exact domain and path and the cookies should not be shared with other sub domains.

5. Communication Protocols

a) SSL: Clear text protocols such as HTTP is always prone to MITM (Man In The Middle) as an attacker can intercept requests in the network level hence SSL is recommended during authentication and post login pages.

b) Disable HTTP: Resources accessible on secured channel such as HTTPS must restrict access with clear text protocols such as HTTP

c) Salted passwords: Passwords must be stored using a secured algorithm and iteratively hashing with a random salt added to hash  makes more stronger to crack

d) SSL Certificates: SSL certificates used must be from a reputed CA signed with secure exchange keys and ciphers.

6. Logs

a) Maintain logs on all privileges: This includes all authentication activities, all privilege changes, administrative activities, access to sensitive data.

b) Secure your logs: Logs are to be saved carefully and maintained on a secure server against tampering to avoid from loss and logs should be maintained for a specific duration according to industry policies.

c) Improper logs: Maintaining appropriate logs and storing them are the important part of logging management. Sensitive information should not be part of logs and the entire log needs to be encrypted in certain situations.

7. Reset password

a) Once reset password link is used, link should be expired for the next use.

b) Till the user resets password, the previous password should not be disabled.

c) Even if the link is unused the reset password link needs to be expired within a defined time say 48 or 72 hours.

d) Reset password link should be over an SSL

e) Old/previous password reset link should be expired once new password link is generated.

f) Token used in reset password link should be mapped to the users email ID and should not be used to reset password of another user.

g) Token should not be sequential or easily guessable or a short one. It should be minimum of 16 characters so that it is not easily brute forced.

h) Password policy should be maintained on reset password page.

8. Error Handling

a) Generic error messages: Display generic error messages to the user, error messages should not reveal details about the application like technology used, internal IP or path, and stack-overflow errors.

b) Framework related errors: All framework generated errors must be generic or messages can be customized so that sensitive information about the framework is not revealed.

c) Unhandled exceptions: Exceptions are strictly advised to handle errors either at client or server side. It is good to have ‘finally’ code block for all unhandled errors with generic error message.

 

References:

Best Practices for Securing Forgot Password Feature

Recently, I authored an article at TestingCircus e-magazine and I like to publish the same on my blog so that I can reach out to my readers who are not subscribed to testingcircus or couldn’t read due to whatsoever reason(s). You can find my article in the following link  http://www.testingcircus.com/testing-circus-2014-august-edition/

Most of the applications having user interaction needs to be more secured and hence securing the application for attacks on stealing users credentials is important. Recent survey says that most of the applications are vulnerable at the user level. For example, its observed that Forget Password feature had most attacks in recent days.

Forget password feature needs to be implemented in such a way that it covers all the possibilities of any attack vector. On a recent case study about a leading security firm says that there was an attack on an social media application because of flaw in the forgot password feature. Hence I would like to come up with guidelines for implementing forgot password feature which ensures the application is more secured.

Initial step during forgot password could be gathering the identity of the user by asking various questions which would in turn proves the identity of the account like, what was the last reset password user remember? Last time user accessed his account? or any other similar questions which reveal the identity of the user.

The next step could be Security Question!

Security questions should not be the same old traditional way asking about mother’s maiden name/place of birth/ favorite teacher or any such questions which are easily crackable and letting the attacker to easily compromise the account. Instead if the application allows user to set his own set of questions) which could infinite set for an attacker to guess the answer.

One more important thing to remember here is that the input field for accepting the answer for the security question should be of type “password” this would protect from shoulder surfing, most of the applications does not do so, which is of more important. Number of attempts user can try answering the security question should also be limited or CAPTCHA needs to implement to prevent brute force attacks. Once the user provides the correct answer the password can be resetted in 2 ways.

  • Reset password link with a token associated to it
  • Temporary password

One of the wage methods on forgot password feature followed by some developers is directly sending the password which was set by the user during registration. This happens only when the password is saved in clear text. Good practice in storing the password is to be hashed+salted before storing it.

Reset password link with a token associated to it

  1. Once reset password link is used, link should be expired for the next use.
  2. Till the user resets password, the previous password should not be disabled.
  3. Even if the link is unused the reset password link needs to be expired within a defined time say 48 or 72 hours.
  4. Reset password link should be over an SSL
  5. Old/previous password reset link should be expired once new password link is generated.
  6. Token used in reset password link should be mapped to the users email ID and should not be used to reset password of another user.
  7. Token should not be sequential or easily guessable or a short one. It should be minimum of 16 characters so that it is not easily brute forced.
  8. Password policy should be maintained on reset password page.
  9. Display custom error message to avoid username enumeration

Temporary Password

  1. Application should force the user to change the password on the first login.
  2. If not used the previous password should not be disabled.
  3. Temporary password should be one time use and should not be able to use it again
  4. Flush the memory of the browser after password change
  5. 302 redirection after successfully resetting the password.
  6. Validity for the temporary password could be not more than 4-5 hours.
  7. Password should not be the same as old password.

Sending reset password link with a token associated to it is the best and economical way of implementing forgot password feature, it avoids usage of CAPTCHA and increased accessibility.

Experience of Security testing on API’s

API

This blog post is all about my first experience with Security Testing on APIs. Back in 2013, I was working on a project “XYZ” in Moolya Software Testing. It all started on April 1st of 2013 when Pari, the “Master Shifu” sent me the mail with the details of the project, which is an advanced voicemail service especially for business people who do not want to miss the calls, at busy times. Ok, now what form is the product in? Is it web app/mobile app? No, those were API’s; we didn’t have any idea on APIs. First task was to understand API and its functionality. Learnt about the API from team members and by exploring on the internet. Understood what an API is, why are they there for an app and how they are used in an app?

An API — Application Programming Interface — allows your product to communicate with each other. In this way, an API allows you to open up data and functionality to other developers and to other businesses.

As API’s act as a backbone for any application, in simple words which are of pure technical stuffs which communicate between presentation layer and the database. API’s reside in business layer and we can test them for its core functionality. And testing functionality of the application in this state will help reducing maintenance of the application. This triggered me to test the API for its security, which would result in great impact on the product or the application. And that is where I decided to do security testing on API’s. Now coming back to the project, what are we supposed to test, what are the requirements, why are we testing, scope of testing, etc were some of the questions that arose.

After getting clarity on all these queries, we started testing. The next issue was to understand windows azure. These were not normal API’s but were built on different technology (Windows Azure). Initially we explored about this technology and started testing. Then there was a dilemma in selecting the tools for testing API’s. We have numerous tools for testing API, selecting the best tool which suites the project was difficult. Finally I landed up on selecting SoapUI, which helps in Manual/Automation testing. Continued with API automation, which was my primary task. Meanwhile, I was testing manually for its functionality.  I thought, why don’t I start security testing on API’s? Now the question was how? Where? Now comes the exploration part on testing API for its security. In simple words, how can a hacker misuse API, what are the effective attacks on API? Santhosh Tuppad who is a well-known security tester suggested me with a book called “Hacking web services” by Shreeraj Shah, which helped me in understanding what kind attacks can be done on APIs.

Now coming to the attacks mentioned in the book, some of the attacks were simply great, but most of them were outdated. Where today’s servers are built in such a way, where it can handle these kinds of attacks in the initial stages. Now coming back to the project, First task was to note different type of attacks or vulnerabilities.

While I was reading, Shreeraj Shah’s book on Hacking Web Services, I found out that they were traditional approaches. However, it was helpful in understanding several concepts. The challenge was to learn new techniques or new ways of hacking web services. There started my exploration! Well, I was doing black box testing, it all depends how much Quality we want to bring in with testing as a black box tester. While performing the web services testing, I didn’t actually look into the code of the application (like the White box tester’s do). I tried to cover all the possible scenarios’ using the tool (SoapUI). The “Groovy Script” came into picture when I started performing the check automation of regular testing on API’s. Though it is not necessary to learn Groovy to perform testing, it surely gives an extra advantage over other testers😉

Tests that I performed to find vulnerabilities,

  • Insecure Direct object Reference

  • Information Leakage and improper error handling

  • Authentication and Certification/Permission and Access Issues

  • Authorization

  • SQL/LDAP/XPATH/OS Command Injection

  • Virus/Spyware/Malware Injection

  • Session/Parameter Tampering

  • Denial of Service/Large Payload

  • Brute-force

  • Data type mismatch/Content Spoofing

  • Information Leakage/Error leakage

  • Replay Attacks

  • Buffer Overflow

  • XML Parsing Attacks

  • Spoiling Schema

  • Complex and Recursive structure as payload

  • Fault Code Leaks/Poor Policies

Learning the basic level of Security on API was fun & easy. To master the same anyone will need to get good grip over basic vulnerabilities. As a starting point for above mentioned attacks, I searched forums & blogs for detailed information.

When malicious requests are executed number of technical layers can be targeted, including,

  • NIC (Network interface Card) and its drivers.

  • Operating System, as it processes the incoming request from the NIC.

  • Target application server that handles the request (for example Apache, IIS, etc.)

Let me explain this in a little more detail on how I could manage to accomplish the task, which is Security testing on API’s.

When I come to think of it – how would I identify security vulnerabilities in the first place? What response would I get back when trying, for example a SQL Injection attack that would allow me to identify that there is security vulnerability? Actually, this wasn’t that easy.

More often I will get an error message back that tells me that the service was unavailable to process the malicious request – this might be a good thing during development but that was one of the situations where I needed to don the hat of the hacker; does the error message tell me something I shouldn’t know about the system? For example which database they are using? Which version? Which language or framework? Maybe it exposes internal IP address? Any of these might be exactly what the hacker is looking for, the information allows them to target specific attacks on your application (there are publicly available databases of known security issues in most software like “Exploit DB”) which in turn might give them the backdoor, what an attacker would have been looking for. It’s something called as “Sensitive Information Exposure” it searches messages returned by application for any information that might expose system details to the hacker – version numbers, software technologies, etc.

Other scenario was tests resulting in a Denial of Service. These are unusual but valuable in the sense that, I found them first and can make sure that they won’t happen again so that the end users using the application are not affected. The actual responses to a Security Test and how to interpret them from a security point of view was one of the major issue which I faced, it requires corresponding system knowledge and understanding to be able report them, that would pin point exploits in responses which helped me the most.

Finally I conclude that,

  • Neglecting possible security vulnerabilities and related issues in your services and APIs can put your data and your business at serious risk.

  • Taking security seriously and building basic expertise around it is an investment well worth making.

  • The core mechanics of most security vulnerabilities are easy to understand, test for, and prevent.

Information Gathering (Footprinting)

Footprinting

Information Gathering/Footprinting is crucial in the whole process of penetration testing.More the information gathered about the target(application/user), more is the probability that appropriate results are obtained. Many tools are available for footprinting which I will be sharing in this post.

Information gathering is not just one phase in security testing! Its an art where each one of us should be a master shifu at gathering relevant info for a better experience in the whole process of Penetration testing.

This post would give you a glimpse of footprinting like, what is footprinting? Purpose of footprinting? What does an attacker gain from footprinting? The various information that can be gathered and how could that be useful in attacking/securing an application or a website.

Ok let me give you a generic example, If a theif wants to rob a bank how does he plan his moves? Will he directly go to the bank and rob without a plan or will he plan by collating all the information required to execute the plan successfully?

The theif would plan by collecting the information from different sources like security loopholes and other required information. Once he plans his moves he would be ready to execute his plan and would go ahead with robbing the bank.

Without this information it would be very difficult for a robber to successfully rob a bank.

Cautionary note: This is only an example. Please use the information wisely and for the purpose of learning only.

Reconnaissance is one such way of collecting the information about an organization/application. The basic reason behind Information gathering here in security context is to learn about the architecture, infrastructure, design, security loop holes of an organization or any application..

There are 2 ways of collecting various information about an organization or 2 types of footprinting,

  1. Active Footprinting

  2. Passive Footprinting

I would be explaining about different ways of gathering information in both the ways using different variety of tools and techniques.

 

1.    Whois is a widely used Internet record listing that identifies who owns a domain or who has registered that particular domain and how to contact them. The Internet Corporation for Assigned Names and Numbers (ICANN) regulates domain name registration and ownership. Whois records have proven to be extremely useful and have developed into an essential resource for maintaining the integrity of the domain name registration and website ownership process.

A Whois record contains all of the contact information associated with the person, group, or company that registers a particular domain name. It also provides information about when was a particular domain registered or getting expired, and when was the last update made on that domain and sometimes this records may also provide the administrative and technical contact information.

2.    Metagoofil is an information gathering or footprinting tools used for extracting information or data which is publicly available on internet belonging to company. INformation can be of any formats like pdf,xls,ppt,doc and much more. Basically metagoofil performs google search in obtaining different files it also uses different file type libraries like PDFMiner which have an index of different PDF files and others. It also provides very useful information like usernames which would in turn be helpful for brute force attack and other information like versions of different softwares and servers being used.

 3.    The Harvester is also used for information gathering where it helps you in extracting the email address and subdomains of a particular target, Harvester is an simple python script which searches information from giant search engines like Google, Yahoo, Bing and much more.

4.    Nmap can be extensively used for information gathering with the help of Nmap Scripting Engine. It can he helpful in basic information about the target like IP address and the ports open and services running, it can be used in determining the information like whois over an nmap console which we discussed earlier, it is also used in harvesting email addresses which discussed earlier(The Harvester), it also helps in discovering additional host names or sub domains that exist on the same server. You can learn more on Namp and other tools on my previous post(Security testing for beginners)

5.    A search engine named Bing(http://bing.com) by Microsoft has a unique feature where in which it could help hacker in enumerating all hostnames which bing had indexed on that server or specific IP address. We can easily use it parameter IP: followed by IP address of the server where in which it provides all the websites hosted on that server. An alternative to the same would be Reverse IP lookup

6.    Blackwidow and HTTrack Website copier is used in better understanding of the website flow as it can be used in cloning the entire domain and could help in offline debugging and to perform tests on local. It can be used in the cases where the server responds only on a particular network.

7.    One of the easiest and craziest way would be Social Engineering. It is an art of wangling people to reveal confidential information which is not supposed to be told out. It involves gaining the trust of an individual in order to obtain confidential information. Social Engineering is a non technical attack but involves tactics for making a victim get trapped. This is an art of gaining important information about an organization, its employees Department, Extension, Email, Role, Phone number etc.

For more information you can have a look at my previous post What is Social Engineering which can give interesting insight on how anyone can be victimised.

I could conclude as, Information Gathering or Footprinting or Reconnaissance is the initial step for penetration testing, more the information you gather more you would be successful in performing the penetration tests. If you are interested in learning further, I would suggest you to start using Kali-Linux or BackTrack!

 References:

https://www.sans.org/reading-room/whitepapers/auditing/footprinting-it-it-why-62
http://hackingmyths.blogspot.in/2012/02/footprinting.html
http://www.domaintools.com/learn/key-terms–definitions-428/#whois

Information Security Myths

Do you think protecting a organization from bad guys is an easy task? not as easy as you/people think, indeed its a difficult task to handle. War between hackers and pentesters on securing and exploiting a website is on one such task which is ageing from past 10+ years, worst part is high level management with in an organization is unaware of risks involved in not prioritising security.

Not just startups even some MNCs fail to take a baby step  towards securing their organization because of some of the below security myths.

 

  1. My organization has passed security compliance from ISO 27001 hence its completely secured

  2. Network/ Application security audits catch all the vulnerabilities

  3. Web Application Security Assessments find all vulnerabilities and no way bad guy can hack

  4. My developers are skilled, We never had any data breaches on our organization and we are safe!

  5. Secure Socket Layer (SSL) Protects my website

  6. We are a mid-size and with limited network/application, hence security is not an issue

  7. We have widely used firewalls and routers which defend us from attacks

  8. Blame game within an organization between developers of application side and network side(lack of information)

  9. Programming/Scripting languages used are secured languages

  10. We don’t have anything worth to steal or trouble

  11. Anti-Virus is protecting me against malware’s and fresh exploits

  12. Data stored in our systems are encrypted/salted and completely under our control

Information Security Myth's

What is Social Engineering?

 

Hmmm. I decided to write this blog keeping aside my inhibitions, and I’m happy I am doing it, particularly, this one!

Okay, I assume you would have heard of something called “Social Engineering”.  If yes, are you aware that there is no patch for human stupidity with respect to Social engineering?  According to me, this is true, as we see many companies/users getting victimized even after many past experiences.

Human beings are weakest links!

What is Social Engineering
Courtesy: http://socialengineeringattacks.blogspot.com

Social Engineering is an art of wangling people to reveal confidential information which is not supposed to be told out. It involves gaining the trust of an individual in order to obtain confidential information. Social Engineering is a non technical attack but involves tactics for making a victim get trapped. This is an art of gaining important information about an organization, its employees, systems etc.

What is Social Engineering

Here, the victim can be anybody; where which includes a high possibility of a hacker himself getting victimized at times! This would be possible when the hacker could be a part of a group of friends, and the entire  group can be victimized at once, as it is completely based on trust where tricking them emotionally would not be very difficult.

Sometimes, it so happens that  in a continuous conversation, we do not even realize that we are revealing personal & confidential information, or end up revealing some hints, which will in turn make the job of a hacker easier, to hack into their extremely personal & confidential information.

Some basic information which can be gathered very easily would include a person’s favorite color, actor, food, car, teacher, best friend etc. It might even include some of the information about childhood, school days or about his/her family. Such information would suffice to an extent in order to hack into any account, as the secret questions to recover the password for any application would mostly involve these.

Let assume, you have become the victim. Now, do you mind answering any questions like your favorite teacher or your pet name or any such questions mentioned above? If you have a very close friend who would try for a social engineering attack does not have to ask you for any such questions, he would be aware of you and your likes and dislikes up to some extent.

A sample Email which can misslead the admin of an organization (An example for social engineering
A sample Email which can mislead the admin of an organization

Generally if you ask for a piece of sensitive information, people naturally become suspicious immediately. If you pretend you already have the information and give out wrong information, they will frequently correct you unconsciously – thereby rewarding you with the correct piece of information you are looking for.

Social engineering toolkit! No, we do not need a SET to victimize anyone! Real-time hackers do not completely depend on social engineering tool kit.

Social Engineering

Preventing Social Engineering:

In my opinion, I don’t think there is any well defined way or application which helps user to prevent social engineering. Different methods are being evolved hence having an eye on different attacks is recommended.

Educating employees of an organization and performing random tests on them might be helpful to identify the mouse traps within the organization, it is recommended not to share their passwords even with their higher authorities or team leaders, let them have an administrator password if access required.

Organizations have to take care of social engineering too, along with other security attacks as it holds more than 50% of share on different attacks.

Frequency of social engineering when compared to other security Attacks.

Frequency of different Security Attacks
Frequency of different Security Attacks

Courtesy: http://securitywize.com/the-risk-of-an-uncertain-security-strategy/1430

If you have any methods of preventing social engineering or any other social engineering cases you are aware of (attention-grabbing) please comment. Let others know your experience.