IT Security Lab The Playground for IT Security Specialists and Pentesters

27Jul/100

Cyber Security Challenge UK Test Solved!

Good times! I have official confirmation that I successfully solved the first test of the Cyber Security Challenge UK

(https://cybersecuritychallenge.org.uk/) :)  Well, I was absolutely sure the solution was right, but what was not known - if I am the first one or not. Unfortunately not, but still I had a great fun! Later I will post detailed steps how puzzles were solved (there were several of them, covering security and cryptography areas), so stay tuned. Really exciting stuff!

Official confirmations goes below:

Dear Aleks

Congratulations on successfully solving the first test of the Cyber
Security Challenge UK. We can confirm your submission was correct!

Whilst we're afraid you were not the first to send in your win code,
very few people solved the cipher so well done on getting it right.

We intend to post a new cipher in about a month - something a bit
trickier to really push you to the limits. In the mean time, please keep
a watch on our website, our Twitter profile, or our Facebook page for
updates and news. For all those looking for a new way to test their
skills - why not sign up to one of the competitions that form part of
the full Cyber Security Challenge UK:
https://cybersecuritychallenge.org.uk/candidates/registration.html
We hope you enjoyed this first test - we can assure you there are many
more to come.

Congratulations again on solving our first puzzle.
The Cyber Security Challenge Team
Tagged as: , No Comments
23Jul/100

Password Hashes Without FGDump

Well, you can be quite frustrated when beloved FGdump just does not work without particular reason. Password hashes are so close, but yet not achievable. But it seems there is a kind of remedy (or call it: “alternative way”) for getting the password hashes. Here is the story.

All right, we know that password hashes are stored in the registry, in the key HKLM\Security\Sam. Normally you must have administrator privileges to access it. Even you are the local admin – you still have to assign manually full control permission for this subkey to yourself. Then you may see something like this:

The juicy stuff physically is stored in two files:
C:\windows\system32\config\sam
and
C:\windows\system32\config\system

So theoretically if we would be able to get the content of those files we may pass it to Cain and play a little with it… But unfortunately those files are locked, so they can’t be copied or accesses by any way. If you will try, you will immediately have a nice error like this:

So it looks like no chance. Well, note quite. There is an interesting approach called “Dumping File Sectors Directly from Disk using Logical Offsets”, which surprisingly allow you to copy files which are locked and currently used. There is nice tool called FDump which allows you to do this. More details here: http://www.codeproject.com/KB/files/FDump.aspx
If you don’t want to go to deep into the theory (which is recommended btw), - here is the practical solution.

The target:

We must have own separate copies of both files: C:\windows\system32\config\sam and C:\windows\system32\config\system in target system (the second one is needed because of the “boot key” is stored there) so then we may process it somewhere else with Cain & Abel.

Step 1:

Run the fdump.exe with the following parameters:

fdump.exe "C:\WINDOWS\system32\config\SAM" sam.dat
fdump.exe "C:\WINDOWS\system32\config\system" system.dat

Expected result:

Step 2:

Run cain.exe and do the following thing: Select “Cracker”, then “Add to list” and then “Import hashes from Sam database”.

Then:

So after all manipulations it should looks more or less like this:

Then click “Next”, and here we are!

The rest is up to you. Now you probably need a good rainbow tables and a bit of luck. :-)

Afterword:

You may be tempted to explore the copied registry manually and see what else is there (your curiosity is more then normal), so here is the quick "how to" browse downloaded registry files with regedit:

Open regedit, and make single click on HKLM branch (important!):

Then in the main menu select “File” and “Load Hive”, then select our file: C:\myfiles\sam

...and finally provide a key name. This is the key where a new hive will be attached to.

Do not forget to assign proper permissions to this branch:

Close the regedit and open it again. Now you can browse everything! :)

Tagged as: , , , , , , , , No Comments
22Jul/100

Secure Data Transfer Over USB Drive

Prelude

All right kids, how many of you have lost your USB drives with some sensitive data on it? Rise your hands. You feel the pain, don't you? Once you realized what happened and after the first "oh my God" you was sitting trembling and desperately thinking:

  • What exactly was on that damned pendrive?
  • Considering the point above: what is the potential impact of this loss?
  • Trying to imagine who is touching some parts your private life right now...

Perfect nightmare scenario, isn't it. And try to picture the situation when you are working in a certain organization (with-the-name-never-be-mentioned) where you must from time to time to hold on pendrive very private and very sensitive data, which (this is really bad) does not even belongs to you. And you may be sure: if this tiny thingy will occasionally be lost - you are literally (and very practically) toast. The question is: how to prevent such situation? Considering you are not CIA, NSA or any weird .gov, etc. this is what you can do:

  1. Do not use USB pendrives at all. I don't think it is possible in long-term perspective. Not this year yet, oh no...
  2. Buy an additionally strengthened pendrive: magnesium alloy body, high-quality on-board encryption, biometric reader, etc. In this case either you or your company have to spend additional couple of quids which would not make happy you, your boss and especially your company's accontant. So think twice.
  3. Use some of the closed-sourcecode tools you may find in Internet to create encrypted container on your pendrive. Well, this may be interesting option indeed, but ask yourself: do you really trust the vendor of this software? What do you know about their encryption techniques? How safe your data really is? Are there any backdoors? Is it a good value for money?
  4. Use some free and opensource tool you may find in Internet like well-known TrueCrypt. It is continuously tested by the community of some picky computer geeks, so you have some guarantee that it is safe. You'd rather not be expecting any backdoors intentionally placed there, for sure. Happy days?

Well, this solution, in my opinion, has some annoyances and complications.

  • You should manually mount encrypted container and dismount manually each time you want to use it.
  • You should manually dismount (eject) the pendrive after you dismounted the encrypted container and before pulling out the pendrive from the USB port, otherwise your precious data may be corrupted.

Let's face it: if you want quickly and efficiently (and often) transfer any data between several computers using such approach - of course this is doable, but... it will be classic "pain in the [...]". Hmm... So how the ideal scenario may looks like?

Light at the end of the tunnel

Scenario:

COMPUTER 1:

  1. I insert the pendrive into a USB port. And wait. After couple of seconds I have additional (fixed) drive letter appeared in my computer (e.g.: letter X:) , giving me access to the content of the encrypted container.
  2. I am copying my very secret data from the Computer 1 to the encrypted container .
  3. I press some magical "eject" button and a) the encrypted container is dismounted, then b) the USB device is automatically "ejected". Now it can be safely pulled out from the USB port.

...Now I go to the Computer 2...

COMPUTER 2:

  1. I insert the pendrive into USB port. And wait. After couple of seconds I have the same (fixed) drive letter appeared in my computer (X: drive again), giving me access to the content of the encrypted container.
  2. I am copying my very secret data from the encrypted container to the Computer 2.
  3. I press some magical "eject" button and the encrypted container is dismounted again, then the USB device is automatically "ejected". Now it can be safely pulled out from the USB port.

Keep in mind: we should meet one important requirement: never keep the key for the encrypted container on the pendrive, so if it's lost - your data are safe. And here comes the small magical application which does all of this!

Secured USB

Binaries: Secured USB
Status: Freeware.
Prerequisites: Latest TrueCrypt installed.
Installation: Just unzip the files to the target location.

So how this thing works.

1. Use the TrueCrypt and create encrypted container of any size you want directly on your pendrive. Read the TrueCrypt's manual if you don't know how to do it. After you have it done -unmount it and remove the pendrive from USB port.

2. Unpack the content of the ZIP file to any target folder on your Computer 1 (you repeat configuration steps on Computer 2 later). Double click the file "TrueCryptAutoMount.exe" and run it. See the new icon in your system tray. Right-click it and select "Settings" from the menu.

3. Configure the settings on the next screen. Positions are self-explanatory (I hope). Provide the name and path to your encrypted container (file) and the password.

Alternatively you may manually edit the file "TrueCryptAutoMount.ini" (do not touch "truecrypt_key" section, as the password will be stored here in encrypted form when you enter it on "Settings" screen).

[settings]

;-------------------------------------------------------------full path to the TrueCrypt.exe
truecrypt_exe_path=C:\Program Files\TrueCrypt\TrueCrypt.exe

;-------------------------------------------------------------filename or relative path of the encrypted container on a pendrive (WITHOUT a drive letter), example: encrypted_data\secured.dat
truecrypt_mobile_container_filename=secured.dat

;-------------------------------------------------------------target drive letter for the encrypted container to be mounted (without ":")
target_drive_letter=t

;-------------------------------------------------------------key needed to access encrypted container
truecrypt_key=h5xfTf36zdxV6NRrIfzA62fbYH8Pmy6z6D5suFaTW7+9efSjpnE04JIfE6/zwFJHieHesIwbfKIEGaCHP/j7xgMRmb/NdjTRpOc=

;-------------------------------------------------------------auto run windows explorer for the mounted Truecrypt drive (yes/no)
auto_run_explorer=no

4. Now insert the pendrive into USB port. If everything is configured correctly you will see the following icon blinking in the bottom-left area of your screen:

...and then...

When the icon disappeared - it means the TrueCrypt secured container is successfully mounted so you may copy everything you need to the drive T:.

5. Once you finished your work with the secured container - double-click the program's icon in the system tray and... do nothing :)

(well, wait couple of seconds when the TrueCrypt container will be unmounted and the pendrive will be automatically "ejected").

6. Now you can safely remove your pendrive from USB port.

Once everything is set up the same way on Computer 1 and Computer 2 (and Computer 3, Computer 4, etc.) you may easily transfer your files and after some time you can find this tool very very handy.

More good news: program may be executed without Admin privileges and still works. Program also correctly handles multiple pendrives used.

Additional credits: This program utilizes 3-rd pary module for fast USB drive ejection called USB Ejector http://quick.mixnmojo.com/usb-disk-ejector. IMHO this little tool is very good by itself, so highly recommended. USB Ejector is open-source, but I did not want unnecessarily duplicate the code and copy the functionality "one-to-one" to my application (ok, I am also too lazy). So my Secured USB has USB Ejector kind of embedded and calls it when needed. The USB Ejector can also be directly executed from the Secured USB menu:

Well, any feedback and impressions would be highly appreciated... :)

Tagged as: , , , , No Comments
21Jul/100

Playing With Cache Plan in MS SQL

Keeping sensitive data in database in plain text is extremely stupid and dangerous - everybody knows it. It's a sin. It should be prohibited, and all DBAs and developers who made such horrible mistake may be publicly crucified by mad IT crowd, and for sure will go to a very hot part of Hell in their afterlife. ;) That's why every programmer (ok,  every more-or-less smart programmer, able to use Google) which desires to avoid such horrible consequences knows the typical solution. Here it comes. Imagine: I need to have passwords stored for authentication purposes. I can't keep it in a plain text in database (see above why). So what I can do: I may keep the hash of the password instead of the password in plain text. Then, in authentication procedure, user provides his password which is hashed again and then two hashes are compared. If they are equal - user is authenticated. Simple, isn't it. Same approach may be used when we are storing any other sensitive information, e.g. credit card numbers, etc.

But life is not so simple. And it is quite easy to make a mistake, because of... a good intentions. If you design the IT system, which is dealing with the databases, ideally you want to separate all DB-related functionality from the rest as much as possible. You probably would be happy use the DB engine for majority of the DB-related tasks, which is absolutely ok. So if there is a chance to use hashing functionality on database side - why not to use it, right? Well, in this particular case this is wrong and I will tell you why.

In MS SQL there is a nice way to get the hash of the data: function called HashBytes(). So if you want to store the credit card number by secure way you may execute something like this:

SELECT HashBytes('SHA1', '4268-2268-1003-2943')

or

SELECT HashBytes('MD5', '4268-2268-1003-2943')

which gives you:

0xF6DAF921E622914D73BC65F235B5333E

Looks fine, isn't it? So considering everything above we should feel reasonably safe by executing something like this, right:

INSERT INTO credit_cards (card_number) VALUES (HashBytes('MD5', '4268-2268-1003-2943'))

So this is not safe, my friend. Because the DB engine compiles the query before execution, optimizes it etc. - it temporarily stores the plain text of the entire SQL  statement in its internal tables for a further processing, and well, this data can be happily retrieved from those tables.

Let's see this example. Ok, so we have stored credit card number this way:

INSERT INTO credit_cards (card_number) VALUES (HashBytes('MD5', '4268-2268-1003-2943'))

Let's imagine that some smart-ass just got unauthorised access to our database, enumerated tables and discovered some juicy stuff: the table called "credit_cards" (oh yea, baby!). Happy day for the attacker, indeed! So what the guy is doing? Of course:

SELECT top 10 card_number FROM credit_cards

What he sees (throwing curses, for sure):

So is everything tip-top? Well, not quite. Atttacker may try to execute the following query:

SELECT st.text, stat.creation_time, stat.last_execution_time
FROM sys.dm_exec_cached_plans AS plans
OUTER APPLY sys.dm_exec_sql_text(plan_handle) AS st
JOIN sys.dm_exec_query_stats AS stat ON stat.plan_handle = plans.plan_handle
WHERE cacheobjtype = 'Compiled Plan'
ORDER BY stat.last_execution_time DESC

This gives him a chance to access the text of the last SQL queries compiled by DB engine.

There are several limitations for such operation, but in this case the important thing is that attacker is still able to view something that he should not. Quick solution: you should store the data which is already hashed or encrypted:

INSERT INTO credit_cards (card_number) VALUES ('F6DAF921E622914D73BC65F235B5333E')

More information about it: MSDN: Plan Caching in SQL Server 2008. Have fun, boys-n-girls. :)

Tagged as: , , No Comments
7Jul/109

Read Skype Data: Chatsync and SQLite

Recently I made some research regarding the way Skype stores the conversation's log. I was nicely surprised that the chat data on the user's computer stored in a very simple form.

The data stored by Skype (I have version 4.2.0.169) seems to be stored in two places and in two completely different formats (btw: does anybody know why? kind of "backward compatibility"?):

  • .dat files in the \chatsync folder
  • SQLite database files (the interesting file: main.db)

So to access the data we need either to read it from the .dat binaries or open the database files with any SQL frontend. Simple.

1. Accessing data from the .dat files

There are plenty of Skype log readers around in Internet, but why not to try to write my own tool in such beautiful summer evening! :)

All right, so what kind of files and data we are dealing with? All conversations are stored in \chatsync folder where you have many subfolders with binary .dat files inside. Each .dat file basically is a new conversation.

So if we want to get all messages exchanged in between User 1 and User 2 we have to:

  • Create one big list of all files in all subfolders and sort them by timestamp.
  • Read conversation id from each .dat file (it is in a fixed offset 0x35 at the very beginning of each file).
  • Create sorted list of all conversations between the pair of users (User 1 <-> User 2) and (User 2 <-> User 1).
  • Read chat messages from every .dat file on such "dedicated list" and store it somewhere.

How to retrieve messages? Each chat message starts from the prefix (0x03 0x02) and ends with the null byte (0x00).

I am quite far from the idea to do a complete reverse engineering of the .dat files, but below you may find a small proof of concept (see the binary file and the source code in Delphi). When you run the application you have to provide the full path to your \chatsync folder. Here how it looks like:

The program can collect a data when the Skype is running. FYI: some of the .dat files may be locked by Skype, so the correct way to open it (in read only mode) is:

   fs := TFileStream.Create(chatSyncFName, fmOpenRead or fmShareDenyNone);

If you'd modify the source code a little and track the changes in those files (e.g.: by monitoring datetime stamp) - you can basically write a Skype conversations sniffer in an hour or so. ;)

2. Accessing SQLite database files

This is even more easy: locate the "main.db" file and open it with SQLite editor (e.g.: SQLIte Spy is good enough). Now you have very nice and elegant way to do whatever you want with the data by executing appropriate SQL query:

User 1 and User 2
Tagged as: , , , , , , , , 9 Comments
   Older Entries »

Recent Posts

Popular

Archives

Categories

Affiliated websites

Contact