Published with CVE-ID: CVE-2019-14362
ERP systems are complex systems in charge of hosting companies critical data. Despite their central position in the company flows, those softwares are generally vulnerable to simple attacks:
- The functional complexity tends to generate a huge amount of code (core plus specific modules),
- They communicate with other parties through interfaces (EDI, reporting, payroll),
- There is a recent trend among editors which consists in selling the software as a SaaS (high quality recurring revenues). But they forget to hide those delicate pieces of engineering behind a private network, letting them publicly available.
I observed on several ERP softwares (closed and open source) that basic security issues were pretty common. Two very frequent and trivial issues:
- SQL injection in reports, in particular with custom reports created by the IT services,
- Directory traversal in attachments: the place where you can link external documents to an ERP object (for example, store an excel File to keep a trace when creating a sales order).
Openbravo ERP is a state-of-the-art open source project covering a large functional perimeter. I have to say it's very well designed and far more secure than some expensive private products I had to work with. Nevertheless, it was vulnerable to directory traversal since 2013 despite tests run while uploading a file.
I don't blame Openbravo as it's a great product, but it's a textbook case.
Description of the exploit
As many ERPs, Openbravo provides an attachments feature, letting the user save external files associated with a document.
The uploaded document is stored in a series of subdirectories like
Here, 318 is the document id for Sales Invoice and 9B3/CE1/.../346/F3 is the record ID of the underlying Attachment record in the DB, splitted in three letters subdirectories. This ID is passed by the upload request and can be modified by the user:
Others parameters are checked upon the user context and cannot be modified. In particular, the filename is protected from a directory traversal.
By modifying the request, you can:
- Gain informations on the installation, like the attachment directory path,
- Replace files on the subsystem.
There is a strong constraint, which is you can only replace files somewhere above the attachments directory in consecutive three letters directories trees.
Two significant issues may be possible:
- Update critical core files if attachments/ is located below the Openbravo main directory (which is the case on the Openbravo provided VM installation),
- Update .bashrc if attachments is located below $HOME.
Just provide an impossible path and you will obtain an error displaying crucial informations on the installation you can use later to know which files you can access and replace.
Replace files on the server
Same as above but with a valid path instead of the record ID. For example on the test appliance: ../../webjs which will be expanded to attachments/259/../../web/js.