Cloud Computing

                  CLOUD COMPUTING

Cloud computing is a technique in which software’s, resources and data are shared virtually provided by servers on computers. In today world it has great value; we can do everything without changing our locations.  

Cloud computing can be public as well as private. In public, resources are available to everyone whereas in private, resources are available only in private network.

Cloud computing can be of different types in which we can download or use any software such as spreadsheet tools etc. online. We can also develop new applications using APIs deployed and configurable remotely such as Force and Google APP engine etc. It also provides virtual machines, abstracted hardware and operating systems which may be contracted by service API such as Amazon EC2 and S3, Windows Live Skydive etc.

VULNERABILTIES OF CLOUD COMPUTING:

1. Confidentiality- Data provided by the customers is not stay confidential on cloud because no one knows where the data is stored when one is not using it.
2.  Integrity- Data is not protected as whole because it is not centralized.
3. Availability- If any error occurs the availability chances of data decreases

  Some systems are malicious which provides unauthorized access to the resources, so hackers can attack the system easily.




RISKS IN CLOUD COMPUTING:

1.   Customers bind to one provider for data and services which may lead to business failure should bankrupt the service provider. It increases the likelihood of sudden changes in provider policy and non-binding agreements such as terms of use.
2. There is the risk of availability of the cloud services because if hacker hacks the services it can force the provider to stop their services due to huge loss.
3.    There is a risk of data security as data is processed by the cloud customers but it is carried out by the cloud provided which causes security breaches.

     

CONSEQUENCES OF CLOUD COMPUTING:

1. The reputation of the company affects due to risks which has an huge impact on the cloud systems.

2.  Personal data is not safe to store in the cloud systems due to vulnerabilities and risks in the system.

3. Service delivery will be affected due to restrictions occurred during the data flow from one cloud system to another.

Linux Commands

These are the main Linux Commands which are used:

1. “/” – this is the root directory and it is the top of the file system and all other directories are mounted under in it.
2. “/root” – this is the default home directory of administration i.e.; root
3. “/home” – it contain all users home directories
4. “/boot” - this directory contain the kernel i.e.; core of the operating system.
5. “/sbin” - it contain administration commands used by super user
6. “/bin” – this directory contain command used by super user and normal user
7. “/usr” - it contain programs and application which are available for users
8. “/var” - it contain variable information such as logs and print queues
9. “/dev” - this directory contain device node through which the operating system can access hardware and software device on system
10. “/etc”- it contain all configuration files
11. “/proc” – this directory is a mount point for virtual information about currently running system process
12. “/tmp” – this directory contain temporary files used by the system
13. “/opt” –it contain the third party of removable media such as cd-rom, floppy disk and pen drive
14. “/lib” – it contain libraries files and no. of different application.

Meterpreter Service

Meterpreter Service

This is a network service wrapper for the Meterpreter. It can be used as a Windows service, or run as a command line application.

Version 1.0 was released on May 29, 2007. The distribution contains source code under a BSD license.

Downloads

• metsvc-1.0.zip (PGP .sig)

Compilation

You'll need GNU make and Visual C++. Go to the src directory and run make.

Installation

1. Copy metsvc.exe and metsvc-server.exe from the current directory to the installation directory.
2. Copy metsrv.dll from Metasploit to the installation directory.
3. To register the Meterpreter as a service, go to the installation directory and run:

   metsvc.exe install-service
    

Usage

If you registered the Meterpreter as a Windows service, it will start automatically. Otherwise, you have to start it manually by running metsvc.exe.

Once the Meterpreter is running, you can test it using the included test.rb script. It will connect to the Meterpreter and run the sysinfo command:

$./test.rb 192.168.70.12 31337

* Initializing Meterpreter
* Loading Stdapi
* System info:
{"OS"=>"Windows XP (Build 2600, Service Pack 2).", "Computer"=>"VM-WINXPPRO"}
* Closing socket

Uninstallation

If you registered the Meterpreter as a Windows service, you need to stop it and remove the service by running:

metsvc.exe remove-service

Then simply delete all files.

Immunity Debugger

Immunity Debugger is a powerful new way to write exploits, analyze malware, and reverse engineer binary files. It builds on a solid user interface with function graphing, the industry’s first heap analysis tool built specifically for heap creation, and a large and well supported Python API for easy extensibility.

Features of Immunity Debugger:
1. A debugger with functionality designed specifically for the security industry
2. Cuts exploit development time by 50%
3. Simple, understandable interfaces
4. Robust and powerful scripting language for automating intelligent debugging
5. Lightweight and fast debugging to prevent corruption during complex analysis

Immunity Debugger’s interfaces include both GUI and a command line. The command line is always available at the bottom of the GUI. It allows the user to type shortcuts as if they were in a typical text-based debugger, such as WinDBG or GDB. Immunity has implemented aliases to ensure that your WinDBG users do not have to be retrained and will get the full productivity boost that comes from the best debugger interface on the market.

Conficker.B Worm

                          

Here is the detailed summary of a computer worm named Conficker.B about how it spread itself to computers and the threats posted by it and also the measures to combat this malware.

Overview : The word Conficker is thought to be derived from two words – English word “configure” and a German word “Ficker”. Microsoft analyst Joshua Phillips gives an alternate interpretation of the name, describing it as a rearrangement of portions of the domain name trafficconverter.biz  which was used by early versions of Conficker to download updates. This worm is capable of disabling security services and obstructing a user's access to security related websites. This restriction opens the infected system to more attacks on top of preventing the system from downloading any new security software or receiving any updates for current security software. The worm also attempts to prevent its removal by using the access control list to fasten its executable onto the infected system.

Exploited vulnerability :  Conficker.B worm exploited a vulnerability in Windows Server Service (SVCHOST.EXE) which allowed remote execution of victim’s system when file sharing is enabled known as MS08-067. The worm saves a copy of its Dll form to a random filename in Windows System folder, then adds registry keys to have svchost.exe invoke that Dll as an invisible network service.

Methods of distribution : Although almost all of the advanced malware techniques used by conficker have been seen in the past but the worm’s combined use of so many techniques  made it unusually difficult to eradicate. It uses various ways to get installed.

1. Via System  - The worm saves a copy of its DLL form to a random filename in the Windows system folder, then adds registry keys to have svchost.exe invoke that DLL as an invisible network service. When executed, Win32/Conficker.B drops copies of itself in the following locations:

%program files%/movie maker/<random filename>.dll

%program files%/internet explorer/<random filename>.dll

%system%/random filename>.dll

%documents and settings%/<username>/application data/<random filename>.dll

%temp%/random filename>.dll

It is here noted that %system%program files%,%documents and settings% and %temp% are variable locations. The malware determines the locations of these folders by queying the operating system. Conficker.B drops the file “<random number>.tmp” in the %system% directory. It also creates a service with the following characteristics, to automatically execute on system start:

Service name:”<random filename>”

Path to executable: %system%svchost.exe –knetsvcs

And then adds the following registry entry:

HKLM/SYSTEM/Currentcontrolset/services/<random filename>/parameters/serviceDll=”%system%/<random filename>”

2. Via Removable Drives – Conficker.B spreads via removable drives by saving a hidden copy of its executable to “<drive>/RECYCLER/S-%d-%d-%d-%d%d%d-%d%d%d-%d%d%d-%d/<random filename and extention>” in the root directory of the located drive where %d is a decimal number. It also creates the file”autorun.inf” which automatically runs the worm executable when the drive is next accessed.

3. Via Network Shares or propagating – Conficker.B also attempts to propagate via windows file sharing by gaining access to any available network share (IP/ADMIN$/system32) by attempting to guess the administrator’s password. It firstly drops a copy of itself in a target machine’s ADMIN$ share using the credentials of the currently logged-on user. It uses a series of combination of various usernames and passwords. If successful then it copies itself to an accessible ADMIN$ share as ADMIN$/system32/<random filename>.Dll.

Passwords Storage In Windows XP and In Linux

How Windows XP stores passwords:

In windows XP the passwords are stored in SAM (Security Account Manager) using LM or NTLM hashes method.

When a user sets password for an account or changes the password for his user account, the password is first hashed using basically two methods LAN Manager hash (LM hash) and NTLM hash. If the password supplied by user is 14 character long or less than 14 characters, Windows generates both hashes LM hash and NTLM hash of such password. Once the hashes of password are generated the both hashed passwords are then stored in the local Security Accounts Manager or SAM.

The LM hash method is relatively less secure as compare to NTLM hash. This hash method is based on IBM peer to peer system and can store passwords with maximum length of 14 characters. It converts all characters of password in upper case and divides into two groups of 7 characters in each. Each group is separately encrypted with 56 bit DES encryption key and stored together as LM hash. If second group is empty a 16 bit pattern AAD3B435B51404EE is stored in SAM as second group. The 0s are added as pad to fill 7 characters if needed.

The NTLM hash is more secure method to store password in SAM. The password with more than 14 characters is stored as NTLM hash in SAM.  NTLM provides large character set including unicode. It is case sensitive and uses Md4 hash (128 bit) method to hash a password. 

How Linux stores passwords:

In Linux the user information and passwords are stored in etc/passwd file in an encrypted form. The etc/passwd file actually contain user information and the passwords are stored in etc/shadow file and only root user has access to shadow file. The passwords in Linux are encrypted using following cryptographic methods before storing in etc/shadow file:

In original UNIX systems the passwords are encrypted using a program called crypt which adds a salt of 2 characters in 11 character password. The salt added in password is random as a result even if two users have same passwords the hash created to store is different. Newer UNIX systems use MD5 hash method.

In Linux system the passwords are encrypted using DES, Blowfish and MD5 hash with password salt. Once the password is encrypted using one of these hashing algorithms the password along with user account information is stored in etc/passwd file as under:

tsingh:7aabc345d7346:47:3:T Singh:/usr/jsingh/:/bin/csh

Cross-site Scripting (XSS)

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

Cross-Site Scripting (XSS) attacks occur when:

1. Data enters a Web application through an untrusted source, most frequently a web request.
2. The data is included in dynamic content that is sent to a web user without being validated for malicious code.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.