Lets take a brief look at a few CVEs I along with my former co-worker and close friend Joe Cohen discovered.
- CVE-2024-32210
- Affected Product and Version: LoMag (Integrator/CE) WareHouse Management version 1.0.20.120
- Problem Type: Use of Hard-coded Credentials
- Description: The LoMag (Integrator/CE) WareHouse Inventory Management v1.0.20.120 and older were found to utilize hard-coded passwords by default for forms, SQL connections and APIs.
- CVE-2024-32211
- Affected Product and Version: LoMag (Integrator/CE) WareHouse Management version 1.0.20.120
- Problem Type: Use of Weak Hash
- Description: An issue in LOGINT LoMag (Integrator/CE) WareHouse Inventory Management v1.0.20.120 and before allows a local attacker to obtain sensitive information via the UserClass.cs and Settings.cs components.
- CVE-2024-32212
- Affected Product and Version: LoMag (Integrator/CE) WareHouse Management version 1.0.20.120
- Problem Type: SQLi
- Description: SQLi vulnerability in LOGINT LoMag (Integrator/CE) WareHouse Inventory Management v1.0.20.120 and before allows an attacker to execute arbitrary code via but not limited to the ArticleGetGroups, DocADdDocument, ClassClickShop and frmSettings components.
- CVE-2024-32213
- Affected Product and Version: LoMag (Integrator/CE) WareHouse Management version 1.0.20.120
- Problem Type: Use of Weak Credentials
- Description: The LoMag (Integrator/CE) WareHouse Inventory Management v1.0.20.120 and older were found to allow weak passwords. By default, hard-coded passwords of 10 characters with little or no complexity are allowed.
Originally Reached out to the LOGINT team: 02/16/24 (And then a few times after that).
Before we jump in, I just wanted to thank Joe Cohen again for exploring this app with me and confirming these issues as we found them. Additionally, I want to congratulate him on adding his first CVEs (of many to come!) under his belt!
So it has been a while since I discovered some reportable vulnerabilities in random applications so I decided to spend some time pursuing vulnerabilities.
A quick google search landed me onto the LoMag WareHouse Management application (Integrator and CE) which is developed by the LOGINT team located in Poland, although they do seem to have an English EU version of their site.
After the install, I started to do my standard software/program/thick client methodology that I rely on in my day to day job.
After fingerprinting the installer, doing some very light reverse engineering and extracting the installer I load up the standard tool suite, Wireshark, ProcMon, IO Ninja, etc and install the application.
I then load up the executable within dnSpy and find that the application more or less successfully decompiles (which is definitely something I’d normally report, given it’d be a informational [No Obfuscation]).
Lets look at CVE-2024-32210 which is due to hard-coded credentials. There were a bunch of instances of this which I’ll just show here:
Make sure to add those to your wordlists!
Next is CVE-2024-32211
This is just a result of utilizing weak hashing algorithms.
Pretty self explanatory, but always use strong algos and a salt+pepper!
Looking at CVE-2024-32212 which is an Structed Query Language (SQL) injection (SQLi). Although this is more of a lesson to practice secure coding in every instance, not just specific ones. Since most of these are unexploitable without local access as it sits, the severity imo should be very low.
I’m just going to show one or a few instances of the insecure coding practices utilized by the LOGINT developers which enable SQLi. I’m not going to go through on how to exploit these vulnerabilities and I’m definitely not going to list every single instance where SQLi is possible.
This is an issue across the application, so I’m sure there are other instances of this issue.
I then manually start to go through the codebase and find multiple instances of what I see as insecure SQL query build/execute functions.
Note how the Program.Warehouse.IdWarehouse is converted to string and then blindly inserted into the query. Converting to string is great, but it is definitely not the way to prevent malicious strings being leveraged.
After seeing that, I decided to export the decompiled code to a Visual Studio project and then scan the codebase with HoruSec (Standalone of course).
This output a bunch of interesting possible findings (Check the other CVE posts in this series) and other injection points.
There are multiple other instances across LoMagIntegrator and LoMagCE but I think this gets the point across. There are also many more instances where parameterization is used.
If we look at some resources such as Link 1, Link 2, Link 3
We can see that always utilizing @parameters is the way to go to properly parameterize queries.
And lastly, CVE-2024-32213 which is the result of the terrible password policy which can be seen in images of CVE-2024-32210.
Honestly, I’m not really stoked or proud on any of these, especially with the lackluster “SQLi.” However, it is always enjoyable to do research, hack stuff, and share an experience with a friend.
END TRANSMISSION