lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon May 29 06:15:41 2006
From: robert at misait.com (Robert Passlow)
Subject: Jiwa Financials - Reporting allows execution of
	arbitrary reports as SQL user with full permissions.

 

Date: 28/5/2006

 

Product: Jiwa Financials 6.4.14  - http://www.jiwa.com.au/

 

 

Vulnerability: Reporting allows execution of arbitrary reports as SQL user
with full SELECT, INSERT, UPDATE, DELETE SQL permissions.

 

 

Product Background

---------------------

 

On execution Jiwa Financials authenticates users against a username/password
database On a SQL server to access that users access level.

 

To do this it gets its SQL connection details from a .ini file located on
the users Application Data folder called Jiwalog.ini

 

The contents of the file are as follows:

 

[Connections]

Count=01

Connection01=<DatasourceName>,Z:\maininifile.ini

 

[Parameters]

LastSQLLogin=jiwauser

LastUserName=<last user>

LastConnectionODBC=<DatasourceName>

 

 

Within maininifile.ini it sets out the users menu amongst other things ie.

 

' Menu Start
'===========
ShowGST= 0

 

[Modules]
Count=09
Module001=Inventory,1
Module002=Debtors,2
Module003=Contacts,8
Module004=Sales Order Entry,3
Module005=Creditors,7
Module006=Purchase Orders,5
Module007=General Ledger,4
Module008=Monthly Reports,2
Module009=System,6

 

Ok so there's the main menu drawn for the user - note a standardized .ini
file for the entire site is common place

Placing all modules on the main menu and just restricting access per module
when one tries to access it.

 

 

 

Reporting

---------

 

When a user executes any menu option to run a report, it loads the report
module which is standard across the board and passes

To the reporting module, the report object that was listed on the menu the
user selected.

 

The report files are all Crystal Reports and are stored on a common mapped
network drive - generally J drive.

 

The full path and filename to the .rpt file is detailed on the screen in a
textbox with a command button to the right of it that

Allows the user to browse for another location or report - THIS INCLUDES ANY
OTHER MAPPABLE DRIVE AND THE LOCAL COMPUTER DRIVES 

ie.  The local My Documents for the evil user.

 

This is a feature apparently because it allows the users to specify
different report file versions etc

 

 

Ok now for the issue

--------------------

 

User logs into Jiwa Financials, goes into Sales Order Processing which is
standard for anyone that generates an invoice - ie. People working out on
the front desk selling products over the counter - not a staff level you
want to give access to your general ledger or anything else.

 

Create a blank crystal report file and point it at a Jiwa table called
HR_Staff for example.

 

Create the report using a dummy database.

 

The username, password and data source including database name is passed to
the report at runtime - all you need correct is the table name that you
could just get anyway from Systables...

 

Now because the guy that works at front counter - although having some
remote clue on how to use the Crystal Report Wizard - he doesn't have access
to save the .rpt file to the network drive with the other reports nor would
he want to because he may get caught that way so he either saves it to his
USB drive and it appears as a locally available drive.

 

He goes into his sales order report to look up a customers previous quote or
anything remotely using the reporting module - given the application does
pretty much everything output wise through different Crystal Reports, that's
pretty easy.

 

He then clicks the Command button to change the location of the .rpt file to
his USB Drive ie. E:\Evil_Jiwa_RPT\Userlist.rpt

 

He then selects "Print To Screen" to the left of the command button.

 

He then clicks the "Print Button" and waits for the few seconds it takes to
return EVERY JIWA USER'S USERNAME, CLEAR TEXT PASSWORD, FIRST NAME, SURNAME,
POSITION IN THE COMPANY AND OTHER DETAILS.

 

 

What has actually happened

--------------------------

 

Because the Jiwa application passes the username/password/data source
details directly to the .rpt file, it uses the same SQL user account that
the rest of the application uses that has full SELECT, INSERT, UPDATE,
DELETE AND DRI rights.

 

I could craft some SQL to select the table names out of the systables table
and then step through table by table and delete all.

 

Or I could simply add $10 to invoices, payments... I could even setup a new
creditor if I was determined enough to write the code, execute the report
once and just wait for the next cheque run!

 

 

Conclusion

----------

 

This applications technology leaves a lot to be desired.

 

When you execute the application, the login screen has "ActiveX Three Teir
Client Server" up the left hand side and "Client Server Accounting" written
horizontally above the username/password textbox's.

 

The only thing installed on the "SERVER" is Microsoft SQL Server and the
Jiwa Database plus a truckload of .rpt files which were obviously created
for remote exploitation.

 

In no way whatsoever is this application a three tier client server solution
and that is something the company refuses to accept.

 

All usernames and passwords are TRANSMITTED in clear text to the local SQL
Server ODBC driver from the application.

 

All usernames and passwords are STORED in clear text in the SQL Server
Database in the table HR_Staff

 

Not even simple base64 encoding has been used.

 

There is no administrative control over users menu options.

 

Far too many variables are available and changeable on the user end outside
the control of the network administrators.

 

There is no remote attempt to validate access to reports vs users seen in
any previous revisions I have seen and 6.4.14 is current.

 

Bottom line - if you have this application on your site - you are vulnerable
- at this stage there is no current patch.

 

Regards,

 

 

Robert Passlow

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060529/2d07eefe/attachment-0001.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ