Jump to content
Clément

Security - How freaky can you get!

Recommended Posts

Happy new year!

 

By the end of 2020 I was surprised by a new customer who said he didn't want a "Delphi software", because Delphi was unsafe for his business. His software got hacked.
Since that was a first, I got more information about what happened and what that security breach was all about.

 

The hacker discovered the manager's password by tampering the application executable. I don't know what tool was used, but all password editors were showing the actual password instead of '*'.
Not only in editors, but in grids too. The application had a feature that requested a manager password to allow changes in some fields. That screen was gone! Any employee could modify, delete, or include data without restrictions. Even some restricted data were display for everyone.


I couldn't see the application source code, or get more information.
But have you ever heard of such a tool that could tamper resources as much as this ?

 

Clément

Edited by Clément

Share this post


Link to post

Tampering with executables is pretty routine, and can be done for pretty much any program irrespective of the language it is coded in.

 

The real question here is why the target was running a tampered executable in the first place. That seems like the real source of the problem, not that the original executable was written in Delphi. If your new customer thinks that the problem will be solved by writing programs in "safe" languages then he/she is delusional.

 

Once you let an attacker execute their code in your computer, the game is over.

  • Like 2

Share this post


Link to post

Displaying a replacement password character could be done by editing the form in the program resources, but would mean changing each TEdit component separately.  I guess developers should really set the replacement character before display to stop editing, to overcome that would mean a lot of debugging. 

 

Of course all executables should be code signed against tampering, and the hash should be checked by the program itself before it runs, ideally the certificate as well.  I have a little unit that does that. 

 

Angus

 

Share this post


Link to post
Guest

Even more...
If someone, unwanted and authorized, has access to a system, local security matters little. With skill and time, he will find a way to go deeper and deeper into the bits ...
We can see this in the famous Denuvo with its virtual layers and hard encryption ... it is not enough to stop a skilled hacker.
The hardest part is accessing the system, or the software in your case. Then it's a matter of time to get more depth into the damage.

The defense should be long before any access to the executable, dll, etc ... but this is also fallible !!!

 

A software very usual for this: SnadBoys Revelation (old times...)

https://snadboys-revelation.br.uptodown.com/windows

 

snadboys-revelation-001.thumb.jpg.29c497e433e59eb4bbc78dcad45d11c2.jpg

 

 

A code in Delph using SendMessage on Swiss Delphi -- old forum about Delphi

https://www.swissdelphicenter.ch/en/showcode.php?id=1208

Edited by Guest

Share this post


Link to post
Guest
40 minutes ago, Clément said:

But have you every heard of such a tool that could tamper resources as much as this ?

There isn't one tool but hundreds, not going to list links or anything, google can do better.

 

Cheat engine easily can modify at runtime and guess what ?, you can export the steps as stand alone application.

 

That why i use WinLicense to protected against runtime patching and any sort of modifications for the file on disk too, that what most binary protectors should do, also i just posted little more information here

https://en.delphipraxis.net/topic/4187-tserversocket-tclientsocket-issue-code-from-delphi-7-from-2010/?page=3&tab=comments#comment-36095

 

Share this post


Link to post
1 hour ago, Clément said:

The application had a feature that requested a manager password to allow changes in some fields. That screen was gone!

Delphi itself made it relatively easy for 3rd party tools to modify the UI as the DFM files were readable plain text resources within the .exe file.

 

One rather popular "hack" was to entirely remove the "Please consider buying" screen from the WinRAR interface. Sounds like this "screen" was removed from your tampered executable as well. This form probably checked the credentials and indicated success by the according TModalResult (mrOk, mrAbort, ...) instead of passing back the credentials so they can be used by the software backend.

Share this post


Link to post

This story is kinda strange.

First, tampering "the exe" to get the managers password, then "every employee" had a "modded" exe.

I think somebody played around with the user rights and don't want to admit.

Anyway, it's better to avoid such smart A customers.... "delphi software unsafe". muha

Share this post


Link to post
2 hours ago, emailx45 said:

Even more...

That's why nobody loads passwords into edit boxes even if it's just showing placeholders, but how the holy cow would one load any password back into anything as they are not even stored since decades, just its hashes. (Ok, this particular ftp client you showed has to store them, but it's quite different from a desktop application)

Edited by Attila Kovacs
  • Like 1

Share this post


Link to post

Hi,

 

Just want to point out this is a new customer that already has a running application written in Delphi.
I might be hired to fix/upgrade/replace it.


He bought the software to keep it in-house, and after a few months he got hacked.
He was using the latest version, and I was asked to recompiled the project and get rid of all those problems.

The company sold the application with sources to the application but no 3rd library sources are included.
I can't rebuild the project. He must buy a few libraries first. 

 

As far as I can tel, it seems he got a nasty virus that modified the program resources.

I explained it wasn't Delphi's fault, and that could happen to any software. In fact I found other applications that were crippled too. He seemed to understand...

I run several antivirus, nothing was detected. So the virus just crippled the software and destroyed itself.


As for the application. It is written in Delphi XE.
Some passwords are hard coded and disclosed to some managers. But that was not the issue.
The screen where that password should be entered is bypassed, and even if the screen was displayed, the editor where the password is typed in will display the password!

 

Holy cow!



Hopefully I managed to convince them to update to Delphi 10. Time will tell
 


 

  • Haha 1

Share this post


Link to post
Guest

a hacker consulter would can help these ghostvirus 😁

Share this post


Link to post
8 hours ago, Clément said:

I run several antivirus, nothing was detected. So the virus just crippled the software and destroyed itself.

After reading you messages, I think that the software has been hacked by someone inside the company, or by someone hired by an employee. That employee wanted to get access to the password protected resource and hacked the software (or asked some one to hack it). Search who benefit from the hack and you'll find the culprit.

 

It is very difficult to prevent software hacking. Hack can be detected by signing the executable with strong cryptography and having an external tool to check the signature. The signature can be checked by the executable itself, but then the hacker can bypass this code. If an external tool check the signature, then the hacker has to hack that tool as well. Having the tool running from another computer, thru a network share would help. The hacker need to hack that other computer.

  • Like 1

Share this post


Link to post

Signing the executable is the key here.
And also make a minimal security audit. A password should be hashed, and never stored in the executable itself.

It has nothing to do with Delphi. It was a poor security design of the application. 

 

About logic security, and reverse engeniering, Java or C# are much worse than Delphi.
You can easily decompile Java or C# executable.... unless it has been obfuscated explicitly.

I can tell you that I "hacked" so many C# dlls which we lost the source... 😉 

Whereas a Delphi exe is compiled, and lack a lot of RTTI, so it is much more difficult to get something about it.

Edited by Arnaud Bouchez
  • Like 1

Share this post


Link to post
1 hour ago, Arnaud Bouchez said:

About logic security, and reverse engeniering, Java or C# are much worth than Delphi.

I think you meant "worse" here.

  • Haha 1

Share this post


Link to post
1 hour ago, Arnaud Bouchez said:

About logic security, and reverse engeniering, Java or C# are much worth than Delphi.
You can easily decompile Java or C# executable.... unless it has been obfuscated explicitly.

I can tell you that I "hacked" so many C# dlls which we lost the source... 😉 

Whereas a Delphi exe is compiled, and lack a lot of RTTI, so it is much more difficult to get something about it.

Whilst this is true, one should not be complacent and rely on it. A skilled hacker will have absolutely no trouble hacking your Delphi app if it is poorly designed.

Share this post


Link to post
Guest

I have seen components during the decades that either stored something sensitive or gave the dev an option to store such things. Imagine upgrading a project from say 15 years ago. The concepts of security over all vectors were much different. Time to delivery might have "affected" even older 3rd party libs to expose something considered "folly" today, but not back then. So - i am for recoding a 15 year old app in stead of trying to upgrade all those pesky parts and pieces.

 

So to agree with the post above, equalizing Delphi with lesser security is complete folly. Like "you used the wrong hammer when you build our door, that is why the thief could steal from us".

 

Also, as an aside, Delphi is one of the best languages/RTL for creating viruses because of it's great span from machine code up to RAD components so the "hyped" users/procurators out there may be biased by false virus positives too.

Share this post


Link to post
On 1/5/2021 at 8:20 AM, FPiette said:

After reading you messages, I think that the software has been hacked by someone inside the company, or by someone hired by an employee. That employee wanted to get access to the password protected resource and hacked the software (or asked some one to hack it). Search who benefit from the hack and you'll find the culprit.

 

It is very difficult to prevent software hacking. Hack can be detected by signing the executable with strong cryptography and having an external tool to check the signature. The signature can be checked by the executable itself, but then the hacker can bypass this code. If an external tool check the signature, then the hacker has to hack that tool as well. Having the tool running from another computer, thru a network share would help. The hacker need to hack that other computer.

You know, you don`t have to be shocked because of hacking in 2020(2021). Even if man not a hacker, he can use apps like spyzie(here is the review for it  https://celltrackingapps.com/spyzie/ ) so what we get - 20$ for an opportunity to dive into another person devices, so you don`t even have to be a hacker, that is a real tech progress xd which immediately harms people, of course 

 

Edited by KeepTheHonesty

Share this post


Link to post
13 minutes ago, KeepTheHonesty said:

If an external tool check the signature, then the hacker has to hack that tool as well. Having the tool running from another computer, thru a network share would help. The hacker need to hack that other computer.

And if the remote server is in <random country> then the hacker has to fight the dragon in <random country> first.

It's stunning how many fairy tales are invented about hacking and security.

  • Haha 1

Share this post


Link to post
Guest
47 minutes ago, Attila Kovacs said:

It's stunning how many fairy tales are invented about hacking and security.

It is not that much imaginary or myth, it is life and technology.

 

Have a look about this one, the one called SolarWinds hack, either google it or start with following links, this one wasn't the worse and will not be but the scale of it is astonishing, and the victims list is shocking.

https://www.schneier.com/blog/archives/2020/12/russias-solarwinds-attack.html

https://www.schneier.com/blog/archives/2021/01/latest-on-the-svrs-solarwinds-hack.html

 

Share this post


Link to post
Guest
1 minute ago, Attila Kovacs said:

What do you want to say with that? Is there anything new? Did they sign the exes? 😉

No, a signature will help with that.

 

But understanding and using security measures and also spreading basic knowledge might help mitigating the impact.

 

ps: the above mentioned hack was done by Russia most likely government one, and this doesn't mean Russia is great in security on contrary, they failed and failing miserably in protecting any information of all Russian citizens, you can buy any information about any Russian citizen anytime. and by information i mean everything, from medical records to your phone record (calls and SMS) and its geolocation !, google bellingcat and navalny to read more about that.

Share this post


Link to post
12 minutes ago, Kas Ob. said:

No, a signature will help with that.

 

 

Yes, they were. And this is where the fairy tails are borning. It's also important to understand what digital signatures are for. Or intended to be. Anyway, 100 of 100 users would just click on "Execute, I know the risks". Not my f..ing job.

And there is also software cracking, where you can sign your app criss-cross, it's just matter of time to get rid of it, or spoof it.

Share this post


Link to post

Signed .exes helps a little with internal validation and can stop arbitrary (driveby) .exe files from being run, but - yes - they can be cracked and spoofed.

But - for such malevolent .exe files to propagate in your network, you already have had a bigger security breach.
 

  • Like 1

Share this post


Link to post

- Never keep passwords in strings (use raw bytes arrays coding them with hashes).
- Where possible I use Sentinel HASP Keys and related software protections.

- Reduce the amount of UI used in DFM (sometimes I prefer to create UI with code).
- Could help a little to use UPX packer compressor so not GURU can't have simple access to DFM contents with resource viewers.
- Some tools, as MadExpect, add CRC exe integrity test (you can add system custom system to check exe integrity).
- Deploy custom exe with final customer info encrypted (so you can know where start the fall).
- Don't place security checks in only a unit but be creative 🙂

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×