rao

*posted by Gopal @ 8:25 PM* 0 comments

" Ophcrack is an open source (GPL license) program that cracks Windows LM hashes using rainbow tables. The program includes the ability to import the hashes from a variety of formats, including dumping directly from the SAM files of Windows. There is also a Live CD version which automates the retrieval, decryption, and cracking of passwords from a Windows system. Rainbow tables for LM hashes of alphanumeric passwords are provided for free by the developers. These tables can crack 99.9% of alphanumeric passwords of up to 14 characters in usually a few seconds, and at most a few minutes. Larger rainbow tables (for LM hashes of passwords with all printable characters, including symbols and space) are available for purchase from Objectif Securité. Starting with version 2.3, Ophcrack also cracks NT hashes. This is necessary if generation of the LM hash is disabled (this is default on Windows Vista), or if the password is longer than 14 characters (in which case the LM hash is not stored)." read more...

Website: http://ophcrack.sourceforge.net

More information

*posted by Gopal @ 11:57 AM* 0 comments

Automating the automation is still a challenge, but in some cases it's possible under certain situations.

In 2017 I created logic-evolver, one of my experiments for creating logic automatically or better said evolving logic automatically.

In some way, the computer create its own program that satisfies a set of tests defined by a human.

https://github.com/sha0coder/logic-evolver

This implementation in rust, contains a fast cpu emulator than can execute one million instructions in less than two seconds. And a simple genetic algorithm to do the evolution.

Here we create the genetic algorithm, and configure a population of 1000 individuals, and the top 5 to crossover. We run the genetic algorithm with 500 cycles maximum.
Note that in this case the population are programs initially random until take the correct shape.

An evaluation function is provided in the run method as well, and looks like this:

The evaluation function receives a CPU object, to compute a test you need to set the initial parameters, run the program and set a scoring regarding the return value.

More info

*posted by Gopal @ 3:20 AM* 0 comments

TL;DR: Don't build a burner device. Probably this is not the risk you are looking for.

Introduction

Every year before DEF CON people starts to give advice to attendees to bring "burner devices" to DEF CON. Some people also start to create long lists on how to build burner devices, especially laptops. But the deeper we look into the topic, the more confusing it gets. Why are we doing this? Why are we recommending this? Are we focusing on the right things?

What is a "burner device" used for?

For starters, the whole "burner device" concept is totally misunderstood, even within the ITSEC community. A "burner device" is used for non-attribution. You know, for example, you are a spy and you don't want the country where you live to know that you are communicating with someone else. I believe this is not the situation for most attendees at DEF CON. More info about the meaning of "burner" https://twitter.com/Viss/status/877400669669306369

Burner phone means it has a throwaway SIM card with a throwaway phone, used for one specific operation only. You don't use the "burner device" to log in to your e-mail account or to VPN to your work or home.

But let's forget this word misuse issue for a moment, and focus on the real problem.

The bad advice

The Internet is full of articles focusing on the wrong things, especially when it comes to "burner devices". Like how to build a burner laptop, without explaining why you need it or how to use it.

The problem with this approach is that people end up "burning" (lame wordplay, sorry) significant resources for building a secure "burner device". But people are not educated about how they should use these devices.

The threats

I believe the followings are some real threats which are higher when you travel:

1. The laptop getting lost or stolen.

2. The laptop getting inspected/copied at the border.

These two risks have nothing to do with DEF CON, this is true for every travel.

Some other risks which are usually mentioned when it comes to "burner devices" and DEF CON:

3. Device getting owned via physical access while in a hotel room.

4. Network traffic Man-in-the-middle attacked. Your password displayed on a Wall of Sheep. Or having fun with Shellshock with DHCP. Information leak of NTLM hashes or similar.

5. Pwning the device via some nasty things like WiFi/TCP/Bluetooth/LTE/3G/GSM stack. These are unicorn attacks.

6. Pwning your device by pwning a service on your device. Like leaving your upload.php file in the root folder you use at CTFs and Nginx is set to autostart. The author of this article cannot comment on this incident whether it happened in real life or is just an imaginary example.

How to mitigate these risks?

Laptop getting stolen/lost/inspected at the border?

1. Bring a cheap, empty device with you. Or set up a fake OS/fake account to log in if you really need your day-to-day laptop. This dummy account should not decrypt the real files in the real account.

Device getting owned while in a hotel room with physical access

1. Don't bring any device with you.

2. If you bring any, make it tamper-resistant. How to do that depends on your enemy, but you can start by using nail glitter and Full Disk Encryption. Tools like Do Not Disturb help. It also helps if your OS supports suspending DMA devices before the user logs in.

3. If you can't make the device tamper-resistant, use a device that has a good defense against physical attackers, like iOS.

4. Probably you are not that important anyway that anyone will spend time and resources on you. If they do, probably you will only make your life miserable with all the hardening, but still, get pwned.

Network traffic Man-in-the-middle attacked

1. Don't bring any device with you.

2. Use services that are protected against MiTM. Like TLS.

3. Update your OS to the latest and greatest versions. Not everyone at DEF CON has a 0dayz worth of 100K USD, and even the ones who have won't waste it on you.

4. Use fail-safe VPN. Unfortunately, not many people talk about this or have proper solutions for the most popular operating systems.

5. For specific attacks like Responder, disable LLMNR, NBT-NS, WPAD, and IPv6 and use a non-work account on the machine. If you don't have the privileges to do so on your machine, you probably should not bring this device with you. Or ask your local IT to disable these services and set up a new account for you.

Pwning the device via some nasty thing like WiFi/TCP/Bluetooth/LTE/3G/GSM stack

1. Don't bring any device with you.

2. If you bring any, do not use this device to log in to work, personal email, social media, etc.

3. Don't worry, these things don't happen very often.

Pwning your device by pwning a service on your device

Just set up a firewall profile where all services are hidden from the outside. You rarely need any service accessible on your device at a hacker conference.

Conclusion

If you are still so afraid to go there, just don't go there. Watch the talks at home. But how is the hotel WiFi at a random place different from a hacker conference? Turns out, it is not much different, so you better spend time and resources on hardening your daily work devices for 365 days, instead of building a "burner device".

You probably need a "burner device" if you are a spy for a foreign government. Or you are the head of a criminal organization. Otherwise, you don't need a burner device. Maybe you need to bring a cheap replacement device.

Why vlang? V is a featured, productive, safe and confortable language highly compatible with c, that generates neat binaries with c-speed, the decompilation also seems quite clear as c code.
https://vlang.io/

After open the binary with radare in debug mode "-d" we proceed to do the binary recursive analysis with "aaaa" the more a's the more deep analys.

The function names are modified when the binary is crafted, if we have a function named hello in a module named main we will have the symbol main__hello, but we can locate them quicly thanks to radare's grep done with "~" token in this case applied to the "afl" command which lists all the symbols.

Being in debug mode we can use "d*" commands, for example "db" for breakpointing the function and then "dc" to start or continue execution.

Let's dissasemble the function with "pD" command, it also displays the function variables and arguments as well, note also the xref "call xref from main"

Let's take a look to the function arguments, radare detect's this three 64bits registers used on the function.

Actually the function parameter is rsi that contains a testing html to test the href extraction algorithm.

The string structure is quite simple and it's plenty of implemented methods.

With F8 we can step over the code as we were in ollydbg on linux.

Note the rip marker sliding into the code.

We can recognize the aray creations, and the s.index_after() function used to find substrings since a specific position.

If we take a look de dissasembly we sill see quite a few calls to tos3() functions.
Those functions are involved in string initialization, and implements safety checks.

tos(string, len)
tos2(byteptr)
tos3(charptr)

In this case I have a crash in my V code and I want to know what is crashing, just continue the execution with "dc" and see what poits the rip register.

In visual mode "V" we can see previous instructions to figure out the arguments and state.

We've located the crash on the substring operation which is something like "s2 := s1[a..b]" probably one of the arguments of the substring is out of bounds but luckily the V language has safety checks and is a controlled termination:

Switching the basic block view "space" we can see the execution flow, in this case we know the loops and branches because we have the code but this view also we can see the tos3 parameter "href=" which is useful to locate the position on the code.

When it reach the substr, we can see the parameters with "tab" command.

Looking the implementation the radare parameter calculation is quite exact.

Let's check the param values:

so the indexes are from 0x0e to 0x24 which are inside the buffer, lets continue to next iteration,
if we set a breakpoint and check every iteration, on latest iteration before the crash we have the values 0x2c to 0x70 with overflows the buffer and produces a controlled termination of the v compiled process.

Related articles

rao

Wednesday, May 31, 2023

Ophcrack

Evolving Logic Until Pass Tests Automatically

How To Build A "Burner Device" For DEF CON In One Easy Step

Introduction

What is a "burner device" used for?

The bad advice

The threats

How to mitigate these risks?

Device getting owned while in a hotel room with physical access

Network traffic Man-in-the-middle attacked

Pwning the device via some nasty thing like WiFi/TCP/Bluetooth/LTE/3G/GSM stack

Pwning your device by pwning a service on your device

Conclusion

Related posts

Tuesday, May 30, 2023

Vlang Binary Debugging

About Me

Links

Previous Posts

Archives