How to Hack/Reset Kali linux login password

Recently changed Kali Linux Log in Password and you have forgotten it. or May be You want to Hack someone's Kali Linux PC. I am giving you one full proof solution for both issues. I really don't know why Kali developers left a loophole behind the Kali Linux well i also want to tell you that this is also working with Backtrack. So doesn't matter you have forgotten your Backtrack Admin log in password or Kali Linux Admin Log in Password just follow below instruction.
1. First boot your kali linux and wait  untill the Grub will come,  As you will see the grub , then scroll down to recovery mode  then press E

                                                                   (click image for large view)

2. After pressing E you will see this screen. Here you have to change some words and need to add some sentence as shown in image 

3. After changing and adding just press F10

4. After pressing F10 it will be reboot and you will see this screen, Here you have to type a command passwd root and hit enter

5. Then type your new root password, hit enter and again retype your root password and hit enter afterthat you will see a massage password update successfully 

6. Now power off by pressing your laptop/PC power button and switch on it again and login with your new password 

Original post: http://www.geekyshows.com/2013/06/how-to-hackreset-kali-linux-login.html

Download test VMs of IE for Windows, Linux, OSX

Test versions of IE using Virtual Machines that you download and manage in your own development environment.

The Microsoft Software License Terms for the IE VMs are included in the release notes and supersede any conflicting Windows license terms included in the VMs.
By downloading and using this software, you agree to these license terms.

http://www.modern.ie/en-us/virtualization-tools#downloads

Getting started with VMs

Instructions

1. Download the SFX and all RAR files for the VM (smaller VMs may not have files with RAR extension). In each set below that contains a split archive, the provided text file (.txt) contains URLs to all files in the set, and this can be used directly with the 'wget' command in Linux. From the terminal, enter wget -i [URL TO TEXT FILE]. For Windows XP single file downloads, use wget [URL TO DOWNLOAD FILE] instead.
   Example 1: wget -i https://az412801.vo.msecnd.net/vhd/IEKitV1_Final/VirtualBox/Linux/IE8_Win7/IE8.Win7.For.LinuxVirtualBox_2.txt
   Example 2: wget https://az412801.vo.msecnd.net/vhd/IEKitV1_Final/VirtualBox/Linux/IE6_XP/IE6.WinXP.For.LinuxVirtualBox.sfx
   
2. After the download of all files for a set is complete, give the SFX file execute permission by typing chmod +x filename.sfx at the terminal.
3. Execute the SFX executable from the terminal with ./filename.sfx to expand the virtual machine to the current directory.

Alternative Extraction Option

Regardless of the host platform that you are using, if you have problems using the self extracting archive, you can always install a program that can extract RAR files and use that to extract the VM.

How To Install Virtualbox On Ubuntu

Quick & easy Guide:

$ sudo add-apt-repository ppa:dreibh/ppa
$ sudo apt-get update
$ sudo apt-get install virtualbox

UNABLE TO LOGON VMWARE VCENTER APPLIANCE WITH ROOT

Symptoms

• You are unable to log into the root account for the vCenter Server Appliance (vCSA).
• The root account for the vCSA is locked.

Purpose

This article provides instructions on preventing the forced lockout of the root account and on unlocking a locked root account.

Cause

The 5.5 release of the vCenter Server Appliance (vCSA) enforces local account password expiration after 90 days by default. This policy locks out the root account when the password expiration date is reached.

Resolution

This behavior affects vCenter Server Appliance 5.5.

Prevent forced lockout when the root account is still active

If the root account is still accessible through the vCSA console or via the secure shell (SSH), you can prevent this issue from occurring by modifying the /etc/cron.daily/pass-expiration script.

To prevent the forced lockout when the root account is still active:

1. Log in to the vCSA as the root user.
   
2. Open the /etc/cron.daily/pass-expiration script in a text editor.
   
3. Replace the commands at the bottom of the script to replace the forced lockout with a forced password change:
   
   
   1. Delete these commands:
      
      # disable the password if it's time and not already done.
      # don't rely on the pam account facility. prepend an x in the shadow file.
      if [ $TODAY -ge $DEADLINE ] && ! grep -q 'root:x' $SHADOW; then
         sed -e 's/^root:\(.*\)/root:x\1/' $SHADOW -i
      fi
      
   2. Enter these commands:
      
      # force a password change for root if we've reached the password expiration date.
      # pam.unix2 doesn't do this the way we would like, so we do this instead.
      if [ $TODAY -ge $DEADLINE ]; then
         chage –d 0 root
      fi
4. Save and close the file.

Unlocking a locked out root account

If the root account is not accessible via the console, the secure shell, and the Virtual Appliance Management Interface (VAMI), the root account has been inactivated due to password expiration. To reactivate the root account, the vCSA must be rebooted and the kernel option modified in the GRUB bootloader to obtain a root shell.

To reactivate the root account:

1. Reboot the vCSA using the vSphere Client.
   
2. When the GRUB bootloader appears, press the spacebar to disable autoboot.
   
   
   
   Note: If the time between when you power on the virtual machine and when it exits the BIOS or EFI and launches the guest operating system is too short, you can adjust the delay. For more information, see Delay the Boot Sequence in the vSphere Client in the vSphere Single Host Management guide.
   
3. Type p to access the appliance boot options.
   
4. Enter the GRUB password.
   
   Note:
   
   • If the vCSA was deployed without editing the root password in the Virtual Appliance Management Interface (VAMI), the default GRUB password is vmware.
   • If the vCSA root password was reset using the VAMI, then the GRUB password is the password last set in the VAMI for the root account.
5. Use the arrow keys to highlight VMware vCenter Server Appliance and type e to edit the boot commands.
   
   
   
6. Scroll to the second line displaying the kernel boot parameters.
   
   
   
7. Type e to edit the boot command.
   
8. Append init=/bin/bash to the kernel boot options.
   
   
   
9. Press Enter. The GRUB menu reappears.
   
10. Type b to start the boot process. The system boots to a shell.
    
11. Reset the root password by running the passwd root command.
    
12. Restart the appliance by running the reboot command.
    
13. Important: Follow the instructions in the Prevent forced lockout when the root account is still active section of this article to prevent future root account lock out and retain password expiration functionality.

Additional Information

The vCSA allows you to establish your own password expiration and warning email policies by using the Admin tab of the Virtual Appliance Management Interface (VAMI).



By default, the password expiration on the local root account in the vCSA is set to 90 days after the password has been changed. This typically occurs at first boot. If the password is not changed on installation, there is a 90-day period before expiration.

Email addresses configured in the Admin tab in the VAMI (https://IP_address:5480 or https://VAMI_host_name:5480) receive email notifications each day for seven days prior to password expiration. The email settings, such as relay SMTP server, are configured through the vSphere Client in the vCenter Server mail settings.  

* Original KB: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2069041

How to Install Komodo Edit on Ubuntu 14.04

This simple tutorial shows how to install latest Komodo edit on Ubuntu 13.04 Raring, 12.10 Quantal, 12.04 Precise via ppa repository.

Komodo Edit, based on the award-winning Komodo IDE, offers sophisticated support for all major scripting languages, including in-depth autocomplete and calltips, multi-language file support, syntax coloring and syntax checking, Vi emulation, Emacs key bindings. It provides dynamic language expertise for Perl, PHP, Python, Ruby, and Tcl, plus JavaScript, CSS, HTML, and XML, and template languages like RHTML, Template-Toolkit, HTML-Smarty and Django.

Install Komodo Edit

A PPA repository has been created for Ubuntu users. So far it supports Ubuntu 13.04, 12.04 and 12.10.

To add the repository, press Ctrl+Alt+T on your keyboard to open terminal. When it opens, run below commands:

sudo add-apt-repository ppa:mystic-mirage/komodo-edit

After that, update your package lists and install this tool via command below:

sudo apt-get update; sudo apt-get install komodo-edit

Once installed, open it by running komodo command. 

Thanks to Ji m from http://ubuntuhandbook.org/index.php/2013/07/install-komodo-ubuntu-13-04-12-04-12-10/

Enable SSH in Ubuntu 14.04 Trusty Tahr

his simple tutorial is going to show you how to enable Secure Shell (SSH) service in Ubuntu 14.04 Trusty Tahr.

Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers.

SSH is not enabled by default in Ubuntu, but you can easily enable this service viaOpenSSH, a free version of the SSH connectivity tools developed by the OpenBSD Project.

To do so, run the command below in terminal:

sudo apt-get install openssh-server

Or install the openssh-server package via Ubuntu Software Center if you’re on Desktop edition:

Once installed, you can change the port, disable root login and do other changes by editing the config file:

sudo gedit /etc/ssh/sshd_config

Finally restart the ssh server to take place:

sudo /etc/init.d/ssh restart

Thanks to Ji M from: http://ubuntuhandbook.org/index.php/2014/04/enable-ssh-ubuntu-14-04-trusty-tahr/

OpenSSL Security Advisory - TLS heartbeat read overrun CVE-2014-0160

OpenSSL Security Advisory [07 Apr 2014]

========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

More information:

• https://bugzilla.redhat.com/show_bug.cgi?id=1084875
• http://heartbleed.com/
• http://www.openssl.org/news/secadv_20140407.txt
• http://www.centosblog.com/critical-openssl-vulnerability-heartbleed-openssl-1-0-1-1-0-1f-patch-bug-centos-system/
• http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/
• http://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it
• http://seclists.org/fulldisclosure/2014/Apr/92
• https://isc.sans.edu/diary/OpenSSL+CVE-2014-0160+Fixed/17917

Check you OpenSSL Version (CentOS):

#openssl version
#openssl version -a
#rpm -q openssl
#yum update openssl
#rpm -q --changelog openssl-1.0.1e | grep -B 1 CVE-2014-0160


How can I check if my HTTPS site is still vulnerable?

You can use http://filippo.io/Heartbleed/ to test if your HTTPS site is vulnerable (thanks to Filipo).


OpenSSL 1.0.1g has been released to fix "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64kB of memory to a connected client or server. This issue did not affect versions of OpenSSL prior to 1.0.1."[1] known as the Heartbleed Bug [3].

/*** update by Johannes Ullrich ...: ***/

Ubuntu released a patch for affected versions:

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-0160.html

Ubuntu also updated OpenSSH.

CentOS/RHEL has a patch available. 

https://rhn.redhat.com/errata/RHSA-2014-0376.html

For CentOS, the OpenSSL version did not change. Instead, only the compile time changed. To test if you are running the right version, look at the second line of the "openssl version -a" output:

Fixed version:

$ openssl version -a | head -2
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Apr  8 02:39:29 UTC 2014
 
Old version:
 
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Wed Jan  8 18:40:59 UTC 2014
 
You probably want to make sure you at least restart affected daemons that load OpenSSL, or just reboot the system. 
 
If you are concerend that the vulnerability was already used to read memory from your systems, you at least should change your SSL keys.
---

The quickest way to figure out which version of OpenSSL you are using is:

openssl version -a

But not that some software may be compiled statically with openssl.

For a vulnerable system, this will return a version of 1.0.1f (or anything but 'g'). Also there will be no complier flag-DOPENSL_NO_HEARTBEATS.