If you have an LSI RAID controller in your ESX host and you would like the LSI RAID health information to show up in vSphere, under Health Status -> Storage, you will need to install the LSI VMware SMIS Provider. Further, in order to perform CLI RAID commands on the ESX host for the LSI controller, you will need to install the MegaCLI vib package.
I am using the following packages on ESX 5.1 Update 1
VMWare SMIS Provider VIB - MR 5.6
MegaCLI 5.5 P1
And downloaded them from here:
http://www.lsi.com/products/storagecomponents/Pages/MegaRAIDSAS9280-24i4e.aspx
Step 1: Download the vib files from LSI.com. I found it easier to find them on the product page instead of the LSI download page.
Step 2: scp the vib files over to your ESX host and put them in the /tmp directory
Step 3: SSH to the ESX host and install the vib packages by running the following commands:
/tmp # esxcli software vib install --no-sig-check -v /tmp/vmware-esx-MegaCli-8.07.07.vib
/tmp # esxcli software vib install --no-sig-check -v /tmp/vmware-esx-provider-lsiprovider.vib
Step 4: Shut down any running VMs and Reboot ESX host
Step 5: Power up all your VMs you shut down in Step 4. NOTE: It will take about 20 minutes for all of the data to show up in the Health Status section. Also, I had issues with the SMIS Provider randomly stopping on ESX 5.1, and thus upgraded to 5.1 Update 1.
Some useful MegaCLI commands are:
cd /opt/lsi/MegaCLI
Controller information
./MegaCli -AdpAllInfo -aALL
./MegaCli -CfgDsply -aALL
Enclosure information
./MegaCli -EncInfo -aALL
Virtual drive information
./MegaCli -LDInfo -Lall -aALL
Physical drive information
./MegaCli -PDList -aALL
NOTE: If you want to run the MegaRAID Storage Manager from your Windows/Linux system and have it manage the RAID controller in your ESX host, you need to be in the same Layer2 VLAN. The software uses multicast to find controllers that it can support. I also found that if your systems are not in DNS, and just have IP addresses, then you MUST add entries for them in the /etc/hosts file or /Windows/system32/drivers/etc/hosts file. If you do not do this then the software will get confused and refer to every device it finds as a NULL string.
Wednesday, May 8, 2013
Upgrading ESX 5.1 to 5.1 Update 1
A week or so ago, VMware released 5.1 Update 1 (Build Number: 1065491). This post will show you how to quickly and easily upgrade your system. If you read VMware's documentation and are still confused, than this should help you. It is just too bad that VMware has to make everything more complicated than it needs to be.
Step 1: Download zip bundle (update-from-esxi5.1-5.1_update01.zip ) not iso from VMware's download site: http://www.vmware.com/patchmgr/download.portal When you get to the portal, select "ESXi (Embedded and Installable) from the dropdown.
Step 2: Copy (scp) the update zip file to your datastore (/vmfs/volumes/datastore1)
Step 3: Shut down all running VMs on the host you want to upgrade
Step 4: SSH to the ESX host you are going to upgrade and run the upgrade command
esxcli software vib install --depot /vmfs/volumes/datastore1/update-from-esxi5.1-5.1_update01.zip
Step 5: When the upgrade finishes reboot the ESX host
Step 6: Start all of the VMs that you shutdown in Step 3
Step 7: Upgrade the vmware-tools for each VM that had older versions
Step 8: Upgrade your vSphere application
Step 1: Download zip bundle (update-from-esxi5.1-5.1_update01.zip ) not iso from VMware's download site: http://www.vmware.com/patchmgr/download.portal When you get to the portal, select "ESXi (Embedded and Installable) from the dropdown.
Step 2: Copy (scp) the update zip file to your datastore (/vmfs/volumes/datastore1)
Step 3: Shut down all running VMs on the host you want to upgrade
Step 4: SSH to the ESX host you are going to upgrade and run the upgrade command
esxcli software vib install --depot /vmfs/volumes/datastore1/update-from-esxi5.1-5.1_update01.zip
Step 5: When the upgrade finishes reboot the ESX host
Step 6: Start all of the VMs that you shutdown in Step 3
Step 7: Upgrade the vmware-tools for each VM that had older versions
Step 8: Upgrade your vSphere application
Tuesday, June 26, 2012
More things to worry about
RSA SecurID 800 tokens appear to be compromised along with other brands. This month has been crazy on the security exploit and malware side of the house. There has been a rash of new and very interesting exploits and some pretty fun new malware. Earlier this month we also saw the boat get rocked, per say, when we learned of an exploit for hypervisors. Now a hypervisor attack has always been the holy grail of theoretical attacks right behind hard tokens, but before this month it was just that, theoretical. If the hypervisor attack proves to be true and left un-patched, this could nullify a lot of cloud deployments. (reference)
And it even gets more scary. Today, once again, we get to worry, really worry. The objects we have come to rely on for real secure authentication, hard tokens, are proving to be vulnerable in under 9 minutes of hacking. Today we learn that the RSA SecurID 800 along with a few other brands of tokens have been exploited. (research paper)
And it even gets more scary. Today, once again, we get to worry, really worry. The objects we have come to rely on for real secure authentication, hard tokens, are proving to be vulnerable in under 9 minutes of hacking. Today we learn that the RSA SecurID 800 along with a few other brands of tokens have been exploited. (research paper)
Saturday, March 10, 2012
How to compile CRRCSim v0.9.12 for Mac OSX 10.7.3
CRRCSim is an RC model-plane simulator (http://sourceforge.net/projects/crrcsim/) for Linux that allows you to fly planes with not only your mouse/keyboard/joystick, but also with your RC plane transmitter. See my next post for how to get your RC plane transmitter talking to your Mac and CRRCSim. Now compiling and getting CRRCSim to run on a Mac is a bit tricky so let me walk you through the steps.
Step 1: You will need to install XCode if you have not already
Step 2: You will need to install MacPorts and then some Linux libraries from MacPorts that are not included with MacOSX by default
> sudo port install plib
> sudo port install jpeg
> sudo port install portaudio
> sudo port install libsdl
Step 3: Download the source code for CRRCSim from sourceforge.net and unpack it:
> cd $HOME/Downloads
> tar xzf crrcsim-0.9.12.tar.gz
Step4: You will need to edit src/mod_misc/filesystools.cpp to make the search path work right for MacOSX. Here is a diff file that will allow CRRCSim to be launched via the Finder or via the command prompt.
187c187,189
< std::string s = "/Library/Application Support/" + appname;
---
> // Bret
> //std::string s = "/Library/Application Support/" + appname;
> std::string s = "./crrcsim.app/Contents/Resources";
193a196,211
>
> std::string s1 = "./Resources";
> if (dirname != "")
> {
> s1.append("/");
> s1.append(dirname);
> }
> pathlist.push_back(s1);
>
> std::string s2 = "../Resources";
> if (dirname != "")
> {
> s2.append("/");
> s2.append(dirname);
> }
> pathlist.push_back(s2);
Step 5: Configure, Compile, and Install CRRCSim
> cd $HOME/Downloads/crrcsim-0.9.12
> ./configure CPPFLAGS="-I/opt/local/include -DAPIENTRY=" LDFLAGS="-L/opt/local/lib -lintl -framework OpenGL" --prefix=$HOME/crrcsim.app
> make
> make install
Step 6: Fix up the directories to be MacOSX like
> cd $HOME/crrcsim.app
> mkdir Contents
> cd Contents
> mkdir Frameworks PlugIns Resources SharedFrameworks
> mv ../bin MacOS
> mv ../share/crrcsim/* Resources/
> mv ../share Resources/
> rmdir Resources/share/crrcsim/
> mv Resources/share/doc/crrcsim/* Resources/share/doc/
> rmdir Resources/share/doc/crrcsim/
Step 7: Add the Icon file from the source tree. NOTE: if you download the tar.gz tar ball then you will not have the MacOSX icn file. You need to get this from the source tree itself. It is called: crrcsim.icns and you need to put it in $HOME/crrcsim.app/Contents/Resources/
Step 8: Create the Info.plist and PkgInfo files in $HOME/crrcsim/Contents/ see the following web sites for more details. I will include samples below. (https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigFiles.html) and (https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html)
Step 9: Copy the crrcsim.app directory over to your /Applications/ directory and have fun playing the RC plane simulator. I will post more details about making a disk image at a later time.
Wednesday, February 1, 2012
802.1X password exploit on many HTC Android devices
February 1, 2012
Subject
802.1X password exploit on many HTC Android devices
Abstract
There is an issue in certain HTC builds of Android that can expose the user's 802.1X Wi-Fi credentials to any program with basic WI-FI permissions. When this is paired with the Internet access permissions, which most applications have, an application could easily send all stored Wi-Fi network credentials (user names, passwords, and SSID information) to a remote server. This exploit exposes enterprise-privileged credentials in a manner that allows targeted exploitation.
Affected Vendors
HTC
Affected Versions
We have verified the following devices as having this issue (there may be others including some non-HTC phones):
Desire HD (both "ace" and "spade" board revisions) - Versions FRG83D, GRI40
Glacier - Version FRG83
Droid Incredible - Version FRF91
Thunderbolt 4G - Version FRG83D
Sensation Z710e - Version GRI40
Sensation 4G - Version GRI40
Desire S - Version GRI40
EVO 3D - Version GRI40
EVO 4G - Version GRI40
Non-Affected Versions
myTouch3g (Appears to run either unmodified, or only lightly modified
Android build)
Nexus One (Runs unmodified Android build)
Severity
Critical
See also
CVE ID: CVE-2011-4872
Timeline
- 2012-02-01: Public disclosure
- 2012-01-31: Submit final public disclosure doc to HTC Global for feedback
- 2012-01-31: HTC publishes information via their web site
- 2012-01-20: Public disclosure ? postponed
- 2012-01-19: Discussion with HTC Global on their time schedule
- 2012-01-05: Conference call with HTC Global
- 2012-01-02: Public disclosure ? postponed
- 2011-12-05: Discussed public disclosure time frames with HTC and Google
- 2011-10-11: Updated all individuals and groups that are aware of the issue
- 2011-10-11: Follow-up conference call with HTC Global and Google
- 2011-09-19: Updated all individuals and groups that were aware of the issue
- 2011-09-19: Conference call with HTC Global and Google
- 2011-09-08: HTC and Google verified exploit
- 2011-09-07: Notified key government agencies and CERT under non-public disclosure
- 2011-09-07: Initial email and phone call with HTC Global and Google
Vulnerability Details
There is an issue in certain HTC builds of Android that can expose the user's 802.1X password to any program with the "android.permission.ACCESS_WIFI_STATE" permission. When paired with the "android.permission.INTERNET" permission, an app could easily send user names and passwords to a remote server for collection. In addition, if the SSID is an identifiable SSID ("Sample University" or "Enterprise XYZ"), this issue exposes enterprise-privileged credentials in a manner that allows targeted exploitation.
Although the published Android APIs don't provide access to the 802.1X settings, it is possible to view the settings with the .toString() member of the WifiConfiguration class. The resulting output will look something like this:
* ID: 2 SSID: "ct" BSSID: null PRIO: 16
KeyMgmt: WPA_EAP IEEE8021X Protocols: WPA RSN
AuthAlgorithms:
PairwiseCiphers: CCMP
GroupCiphers: WEP40 WEP104 TKIP CCMP
PSK:
eap: PEAP
phase2: auth=MSCHAPV2
identity: [Your User Name]
anonymous_identity:
password:
client_cert:
private_key:
ca_cert: keystore://CACERT_ct
On most Android devices, the password field is either left blank, or simply populated with a "*" to indicate that a password is present. However, on affected HTC devices, the password field contains the actual user password in clear text.
This is sample output from a Sprint EVO running Android 2.3.3:
* ID: 0 SSID: "wpa2eap" BSSID: null PRIO: 21
KeyMgmt: WPA_EAP IEEE8021X Protocols: WPA RSN
AuthAlgorithms:
PairwiseCiphers: CCMP
GroupCiphers: WEP40 WEP104 TKIP CCMP
PSK:
eap: TTLS
phase2: auth=PAP
identity: test
anonymous_identity:
password: test
client_cert:
private_key:
ca_cert: keystore://CACERT_wpa2eap
Vendor Response
Google and HTC have been very responsive and good to work with on this issue. Google has made changes to the Android code to help better protect the credential store and HTC has released updates for all currently supported phone and side-loads for all non-supported phone.
Customer with affected versions can find information from HTC about updating their phone at: http://www.htc.com/www/help/
Google has also done a code scan of every application currently in the Android Market and there are no applications currently exploiting this vulnerability.
Credit
Chris Hessing from The Open1X Group (http://www.open1x.org) who is currently working on Android, iOS, Windows, Mac OSX, and Linux 802.1X tools for Cloudpath Networks (http://www.cloudpath.net/) discovered this password exploit.
Contact Information
Chris Hessing
Senior Engineer, Cloudpath Networks (chris.hessing@cloudpath.net)
Chief Architect, Open1X Group (chris@open1x.org)
Bret Jordan CISSP
Senior Security Architect, Open1X Group (jordan@open1x.org)
About
Cloudpath Networks
Cloudpath Networks provides software solutions that allow diverse environments to operate WPA2-Enterprise and 802.1X networks in a scalable, sustainable manner.ˇ From Bring Your Own Device (BYOD) in enterprise to student-owned devices in education, Cloudpath's XpressConnect Wizard has been proven to provide unmatched simplicity on millions of devices around the globe.
XpressConnect is an automated, self-service wizard for connecting users to WPA2-Enterprise and 802.1X across a wide range of device types and authentication methods, including credential-based (PEAP and TTLS) and certificate-based (TLS).ˇ For certificate-based environments, XpressConnect?s integration technology seamlessly connects to existing Microsoft CA servers to extend automated certificate issuance to non-domain devices, including iOS (iPhone, iPad, iPod Touch), Android, Windows, Mac OS X, and Linux.
The Open1X Group
The Open1X Group is a strategic research and development group established in 2001 to support the creation and adoption of secure authentication systems over traditionally insecure network connection.
The Open1X Group performs active and ongoing research and analysis in to the IEEE 802.1X protocol, the IETF EAP Methods, emerging authentication technologies, and various cryptographic implementations. The Open1X Group has had the support of major Universities, enterprise companies, major Hi-Tech companies, and non-profit organizations. The Open1X Group also performs on-going analysis of business and academic interests in to secure authentication and single sign-on systems, and Government and non-Government regulations and mandates for compliance in secure authentication.
The Open1X Group leverages a distributed team of security architects, engineers, and research scientists with specializations in 802.1X, gird and high performance computing, wireless networking, federated authentication, black box testing, cryptography, large enterprise and University deployment experiences, and global project development.
The Open1X Group is a pioneer in the secure authentication space with the first major wide spread 802.1X federated deployment back in 1999/2000, and the development of a fully featured 802.1X supplicant, XSupplicant.
Subject
802.1X password exploit on many HTC Android devices
Abstract
There is an issue in certain HTC builds of Android that can expose the user's 802.1X Wi-Fi credentials to any program with basic WI-FI permissions. When this is paired with the Internet access permissions, which most applications have, an application could easily send all stored Wi-Fi network credentials (user names, passwords, and SSID information) to a remote server. This exploit exposes enterprise-privileged credentials in a manner that allows targeted exploitation.
Affected Vendors
HTC
Affected Versions
We have verified the following devices as having this issue (there may be others including some non-HTC phones):
Desire HD (both "ace" and "spade" board revisions) - Versions FRG83D, GRI40
Glacier - Version FRG83
Droid Incredible - Version FRF91
Thunderbolt 4G - Version FRG83D
Sensation Z710e - Version GRI40
Sensation 4G - Version GRI40
Desire S - Version GRI40
EVO 3D - Version GRI40
EVO 4G - Version GRI40
Non-Affected Versions
myTouch3g (Appears to run either unmodified, or only lightly modified
Android build)
Nexus One (Runs unmodified Android build)
Severity
Critical
See also
CVE ID: CVE-2011-4872
Timeline
- 2012-02-01: Public disclosure
- 2012-01-31: Submit final public disclosure doc to HTC Global for feedback
- 2012-01-31: HTC publishes information via their web site
- 2012-01-20: Public disclosure ? postponed
- 2012-01-19: Discussion with HTC Global on their time schedule
- 2012-01-05: Conference call with HTC Global
- 2012-01-02: Public disclosure ? postponed
- 2011-12-05: Discussed public disclosure time frames with HTC and Google
- 2011-10-11: Updated all individuals and groups that are aware of the issue
- 2011-10-11: Follow-up conference call with HTC Global and Google
- 2011-09-19: Updated all individuals and groups that were aware of the issue
- 2011-09-19: Conference call with HTC Global and Google
- 2011-09-08: HTC and Google verified exploit
- 2011-09-07: Notified key government agencies and CERT under non-public disclosure
- 2011-09-07: Initial email and phone call with HTC Global and Google
Vulnerability Details
There is an issue in certain HTC builds of Android that can expose the user's 802.1X password to any program with the "android.permission.ACCESS_WIFI_STATE" permission. When paired with the "android.permission.INTERNET" permission, an app could easily send user names and passwords to a remote server for collection. In addition, if the SSID is an identifiable SSID ("Sample University" or "Enterprise XYZ"), this issue exposes enterprise-privileged credentials in a manner that allows targeted exploitation.
Although the published Android APIs don't provide access to the 802.1X settings, it is possible to view the settings with the .toString() member of the WifiConfiguration class. The resulting output will look something like this:
* ID: 2 SSID: "ct" BSSID: null PRIO: 16
KeyMgmt: WPA_EAP IEEE8021X Protocols: WPA RSN
AuthAlgorithms:
PairwiseCiphers: CCMP
GroupCiphers: WEP40 WEP104 TKIP CCMP
PSK:
eap: PEAP
phase2: auth=MSCHAPV2
identity: [Your User Name]
anonymous_identity:
password:
client_cert:
private_key:
ca_cert: keystore://CACERT_ct
On most Android devices, the password field is either left blank, or simply populated with a "*" to indicate that a password is present. However, on affected HTC devices, the password field contains the actual user password in clear text.
This is sample output from a Sprint EVO running Android 2.3.3:
* ID: 0 SSID: "wpa2eap" BSSID: null PRIO: 21
KeyMgmt: WPA_EAP IEEE8021X Protocols: WPA RSN
AuthAlgorithms:
PairwiseCiphers: CCMP
GroupCiphers: WEP40 WEP104 TKIP CCMP
PSK:
eap: TTLS
phase2: auth=PAP
identity: test
anonymous_identity:
password: test
client_cert:
private_key:
ca_cert: keystore://CACERT_wpa2eap
Vendor Response
Google and HTC have been very responsive and good to work with on this issue. Google has made changes to the Android code to help better protect the credential store and HTC has released updates for all currently supported phone and side-loads for all non-supported phone.
Customer with affected versions can find information from HTC about updating their phone at: http://www.htc.com/www/help/
Google has also done a code scan of every application currently in the Android Market and there are no applications currently exploiting this vulnerability.
Credit
Chris Hessing from The Open1X Group (http://www.open1x.org) who is currently working on Android, iOS, Windows, Mac OSX, and Linux 802.1X tools for Cloudpath Networks (http://www.cloudpath.net/) discovered this password exploit.
Contact Information
Chris Hessing
Senior Engineer, Cloudpath Networks (chris.hessing@cloudpath.net)
Chief Architect, Open1X Group (chris@open1x.org)
Bret Jordan CISSP
Senior Security Architect, Open1X Group (jordan@open1x.org)
About
Cloudpath Networks
Cloudpath Networks provides software solutions that allow diverse environments to operate WPA2-Enterprise and 802.1X networks in a scalable, sustainable manner.ˇ From Bring Your Own Device (BYOD) in enterprise to student-owned devices in education, Cloudpath's XpressConnect Wizard has been proven to provide unmatched simplicity on millions of devices around the globe.
XpressConnect is an automated, self-service wizard for connecting users to WPA2-Enterprise and 802.1X across a wide range of device types and authentication methods, including credential-based (PEAP and TTLS) and certificate-based (TLS).ˇ For certificate-based environments, XpressConnect?s integration technology seamlessly connects to existing Microsoft CA servers to extend automated certificate issuance to non-domain devices, including iOS (iPhone, iPad, iPod Touch), Android, Windows, Mac OS X, and Linux.
The Open1X Group
The Open1X Group is a strategic research and development group established in 2001 to support the creation and adoption of secure authentication systems over traditionally insecure network connection.
The Open1X Group performs active and ongoing research and analysis in to the IEEE 802.1X protocol, the IETF EAP Methods, emerging authentication technologies, and various cryptographic implementations. The Open1X Group has had the support of major Universities, enterprise companies, major Hi-Tech companies, and non-profit organizations. The Open1X Group also performs on-going analysis of business and academic interests in to secure authentication and single sign-on systems, and Government and non-Government regulations and mandates for compliance in secure authentication.
The Open1X Group leverages a distributed team of security architects, engineers, and research scientists with specializations in 802.1X, gird and high performance computing, wireless networking, federated authentication, black box testing, cryptography, large enterprise and University deployment experiences, and global project development.
The Open1X Group is a pioneer in the secure authentication space with the first major wide spread 802.1X federated deployment back in 1999/2000, and the development of a fully featured 802.1X supplicant, XSupplicant.
Sunday, January 8, 2012
Doxygen for Perl
A few weeks ago, on December 22, 2011 actually, I released a new filter for adding Perl support to Doxygen. This filter supports Doxygen style comments, POD style comments, and can perform some basic analysis of a Perl module and is called Doxygen::Filter::Perl. You can download this filter from CPAN or from Sourceforge at: http://perldoxygen.sourceforge.net/. For windows users or first time Doxygen users, please see the discussion thread on the Sourceforge project page. For those familiar with Doxygen, the documentation on CPAN should suffice.
Tuesday, December 6, 2011
How do I su to root on OSX
So you are tired of typing sudo before ever command and you would like root shell running bash. In OSX like Ubuntu the password for root is locked and you can not “su” or “sux” to root. The way you get around this is to first “sudo bash” to get a root bash shell and then “passwd” to set the root password. Make sure you set a really strong password for root if you are going to go this route. And if you allow inbound SSH, you should probably change the sshd_config to not allow root to SSH in. Make users SSH as a non-privileged user first and then su to root.
Once you have this done you will probably want to set the shell that root uses by default. Unfortunately you can not just edit /etc/passwd like in Linux. OSX uses OpenDirectory to store all of this. What I had to do is reboot/logout and then log back in as root. You can then use the actual GUI tools (System Preferences -> Users and Groups -> Control-Click the root user in the list and select advanced options) to change the shell for the root user.
Subscribe to:
Posts (Atom)
