Friday, September 24, 2010

Remedy Password Obfuscation

Recently I was checking around for possible sites that were sending plaintext passwords in the clear. One such application I tested was BMC remedy 7.x. Although it doesn't send completely clear passwords, it might as well. Here is the javascript code on the login form for password handling prior to a POST operation.

function getScrambledPassword(pwd) {
   var cipher = ['k', 's', 'z', 'h', 'x', 'b', 'p', 'j', 'v', 'c', 'g', 'f', 'q', 'n', 't', 'm'];
   var result="";
   if (pwd == null)
       pwd = "";
   pwd = encodeURIComponent(pwd);
   //alert("encoded password: " + pwd);
   for(var i=0;i < pwd.length;i++) 
       var cc="pwd.charCodeAt(i);
       result += cipher[Math.floor(cc/16)] + cipher[cc%16];
   return result

The login page uses this function to "Scramble" the password using a fixed set of constants in the array. If you search around google for remedy pages "inurl:arsys inurl:login.jsp", you will find the same set of ciphers on every page you check. Some sites have https pages, while others do not. In case, the scrambled password above uses a simple operation to convert to numeric values, and creates to characters for every one character of original password. Lets assume our password is "Password". When you post the form, the value sent is bkpsjhjhjjpmjzpx. Since we have 2 characters of cipher text for each one of non-cipher, lets take the first letter: bk

From the calculations, first we have a divide by 16 which equals 5 according to our array. X/16 = 5 -> 5*16 = X = 80. This is rounded down, so we have a original value of anything from 80 to (80 + 16 -1 = 95). Now the second value k is a 0. This is a modulus of the original number and 16. This value is added to our first character to get the original. 80 + 0 = 80, which our handy ASCII table says is a P.

Keep going with the remaining characters and you get the full original password. So, always use https. If you can come up with a better authentication method, do it.

Wednesday, September 22, 2010

Simple powershell Hijra date converter

I was recently looking for something to display Hijra calendar format in windows. If you have the system set up with specific locales then it should be an option to display on your system time. But if you want the gregorian date displayed as standard, but want to do quick Hijra date conversions, there is a .NET object to assist in that. System.Globalization.HijraCalendar assists with converting the dates, but of course the day value may not always be accurate, or agreed upon. I wanted to put together a simple powershell script for converting the current date, or any date provided to its appropriate day/month/year, including a text display of the name. So I have thrown together this very basic script for this:


if ($args[0] -eq $null) {
$mydt = [datetime]::Now
} else {
if ($args[0].gettype() -eq [datetime]) {
$mydt = $args[0]
} else {
$mydt = [datetime]::Now

$hjdt = New-Object System.Globalization.HijriCalendar

$hjday = $hjdt.getdayofmonth($mydt)
$hjmonth = $hjdt.getmonth($mydt)
$hjyear = $hjdt.getyear($mydt)
$hj_day_of_week = $hjdt.getdayofweek($mydt)

switch ($hjmonth) {
"1" {$hjmontxt = "Muharram"}
"2" {$hjmontxt = "Safar"}
"3" {$hjmontxt = "Rabi I"}
"4" {$hjmontxt = "Rabi II"}
"5" {$hjmontxt = "Jumada I"}
"6" {$hjmontxt = "Jumada II"}
"7" {$hjmontxt = "Rajab"}
"8" {$hjmontxt = "Shaban"}
"9" {$hjmontxt = "Ramadan"}
"10" {$hjmontxt = "Shawwal"}
"11" {$hjmontxt = "Zulkadah"}
"12" {$hjmontxt = "Zulhijjah"}
switch ($hj_day_of_week) {
"Monday" { $hjdaytxt = "Yawm al-Ithnayn"}
"Tuesday" { $hjdaytxt = "Yawm ath-Thalaathaa'"}
"Wednesday" { $hjdaytxt = "Yawm al-Arba'aa" }
"Thursday" { $hjdaytxt = "Yawm al-Khamīs"}
"Friday" {$hjdaytxt = "Yawm al-Jumu'ah"}
"Saturday" { $hjdaytxt = "Yawm as-Sabt"}
"Sunday" { $hjdaytxt = "Yawm al-Aḥad"}

$hjdisplay = [string]$hjday + " " + $hjmontxt + " " + [string]$hjyear
$result = New-Object PSObject
Add-Member -InputObject $result NoteProperty Day $hjday
Add-Member -InputObject $result NoteProperty Month $hjmonth
Add-Member -InputObject $result NoteProperty Year $hjyear
Add-Member -InputObject $result NoteProperty DayName $hjdaytxt
Add-Member -InputObject $result Noteproperty Display $hjdisplay
return $result

PS C:\> .\get-hijradate.ps1
Day Month     Year DayName             Display
--- -----     ---- -------             -------
16   10       1431 Yawm Al-Jumu'ah     14 Shawwal 1431

Tuesday, September 14, 2010

SPN attribute limits

In cases where a lot of ServicePrincipalNames are tied to a commonly used service account (yes I know there's no good reason to do this), I thought it may be a good idea to check what the maximum number of SPN's on a single account was. The method used for this was adding random generated strings of 10 characters with the parent domain dns suffix added as a HOST/ SPN record. I did try the same test with longer random generated strings, but I came up with the same results.

I have not yet tested in 2008 functional levels, but I was able to test 2000 and 2003 Native.

The numbers I am getting are:

2000 Native: 831 spn's
2003 Native: 1249 spn's