Bugtraq mailing list archives

Multiple unresolved vulnerabilities in Basware Banking/Maksuliikenne


From: Samuel Lavitt - CVE-2015-0942 <CVE-2015-0942 () precipice fi>
Date: Tue, 28 Jul 2015 05:00:39 +0000

English: Multiple vulnerabilities in Basware Banking/Maksuliikenne software that were reported already 08/2012 may 
still enable undetectable economic crimes against user organizations (companies)
Finnish: Basware Banking/Maksuliikenne -ohjelmiston haavoittuvuudet, joista raportoitiin jo 08/2012, saattavat edelleen 
mahdollistaa käyttäjäyrityksiin kohdistuvia ”näkymättömiä” talousrikoksia
Swedish: Sårbarheter i Basware Banking/Maksuliikenne programvaran, vilka rapporterades redan 08/2012, kan fortfarande 
möjliggöra “osynlig” ekonomisk kriminalitet mot användarföretag 

Security researcher, author: Samuel Lavitt <cve-2015-0942 () precipice fi>
Editor and translator: Ronja Addams-Moring <ronja () precipice fi>


English Summary:
Basware Banking/Maksuliikenne, a cash/bank account management software package for enterprises from software vendor 
Basware, has multiple critical vulnerabilities, which are described in this report. These vulnerabilities were first 
observed and reported to Basware by security researcher and author of this report, Samuel Lavitt, in August 2012. These 
vulnerabilities, and exploits to unlawfully gain economically from them in an undetectable manner, were demonstrated by 
the author to Basware and CERT-FI (part of the National Cyber Security Centre Finland) on 7 July 2014. The Finnish 
Financial Supervisory Authority was also informed in July 2014. At least one vulnerability has been partially fixed 
since.
Despite that fix it is still, to the best of the author’s knowledge, possible to:
-    Duplicate a user organization’s digital banking security keys, which are used to authenticate the banking 
transactions.
-    Modify all the records in the user organization’s Basware Banking software, including transaction records as well 
as pending transactions.
-    Bypass all permission restrictions (access controls) in the user organization’s client software.
These risks affect at least 1,500 user organizations (companies) in the Nordic and Baltic countries, mainly in Finland 
and Sweden. Protecting against these risks may require a complete reset of all affected digital banking keys, in 
addition to security fixes to the software, or discontinuing the use of the vulnerable software. To implement these 
changes and prevent possible fraud due to the vulnerabilities that allow the copying of banking keys, each user 
organization may require the assistance of banks where they have granted the Basware Banking/Maksuliikenne software 
access to their bank accounts. Depending on how processes are defined and technical controls implemented in each bank, 
making the required changes may or may not also have an impact on other bank customers who do not use the Basware 
Banking/Maksuliikenne software.

Yhteenveto suomeksi:
Basware Banking/Maksuliikenne, yritysten rahan ja pankkitilien hallintaan tarkoitettu ohjelmistopaketti 
ohjelmistotoimittaja Baswarelta, sisältää useita kriittisiä haavoittuvuuksia, jotka on kuvattu tässä raportissa. Tämän 
raportin kirjoittaja, turvallisuusasiantuntija Samuel Lavitt havaitsi nämä haavoittuvuudet ensimmäisen kerran ja 
ilmoitti niistä Baswarelle elokuussa 2012. Nämä haavoittuvuudet sekä sen, miten niitä hyödyntämällä on mahdollista 
saada oikeudetonta taloudellista etua ilman, että sitä voidaan havaita, kirjoittaja osoitti Baswaren ja CERT-FI:n (osa 
Viestintäviraston Kyberturvallisuuskeskusta) edustajille demonstraatiossa 7. heinäkuuta 2014. Myös Finanssivalvonnalle 
ilmoitettiin asiasta heinäkuussa 2014. Ainakin yksi haavoittuvuuksista on sittemmin osittain korjattu.
Raportin kirjoittajan parhaan tiedon mukaan korjauksesta huolimatta on edelleen mahdollista:
-    Monistaa käyttäjäorganisaation pankkitoimintaa turvaavia digitaalisia avaimia, joita käytetään pankkitapahtumien 
todentamiseen.
-    Muokata kaikkia käyttäjäorganisaation Basware Maksuliikenne -ohjelmiston sisältämiä tietoja, kuten tilitietoja 
sekä jonossa olevia (ajastettuja) pankkitapahtumia.
-    Ohittaa kaikki käyttöoikeusrajoitukset (pääsynvalvonta) käyttäjäorganisaation asiakasohjelmassa.
Nämä riskit vaikuttavat ainakin 1500 käyttäjäorganisaatioon (yritykseen) Pohjoismaissa ja Baltian maissa, pääasiassa 
Suomessa ja Ruotsissa. Näiltä riskeiltä suojautuminen saattaa edellyttää kaikkien haavoittuvuuden vaikutuspiirissä 
olevien digitaalisten pankkiavainten uusimista, sen lisäksi että ohjelmiston turva-aukot on korjattava tai on 
lopetettava haavoittuvan ohjelmiston käyttö. Jotta nämä muutokset voidaan toteuttaa ja mahdolliset petokset 
haavoittuvuuden kautta kopioitujen pankkiavainten avulla estää, kukin käyttäjäorganisaatio saattaa tarvita apua 
kaikilta niiltä pankeilta, joissa se on antanut Basware Maksuliikenne -ohjelmistolle oikeudet käsitellä pankkitilejään. 
Riippuen siitä, miten kussakin pankissa prosessit on määritelty ja turvaratkaisut toteutettu, tarvittavien muutosten 
tekeminen saattaa vaikuttaa tai olla vaikuttamatta myös muihin pankkiasiakkaisiin, jotka eivät käytä Basware 
Maksuliikenne -ohjelmistoa.

Sammanfattning på svenska:
Basware Banking/Maksuliikenne, ett programvarupaket för företag för penning- och bankkontohantering, utgivet av 
mjukvaruleverantören Basware, har flera kritiska sårbarheter som beskrivs i denna rapport. Dessa sårbarheter 
observerades och rapporterades till Basware av författaren till denna rapport, Samuel Lavitt, för första gången i 
augusti 2012. Dessa sårbarheter, och hur man med hjälp av dem kan få obehörig ekonomisk vinning på ett sätt som inte 
går att spåra, demonstrerades av författaren för Basware och CERT-FI (en del av Kommunikationsverkets 
Cybersäkerhetscenter i Finland) den 7e juli 2014. Även Finansinspektionen i Finland informerades i juli 2014. 
Åtminstone en av sårbarheterna har delvis korrigerats sedan dess.
Trots korrigeringen är det, enligt författarens bästa förståelse möjligt att:
-    Duplicera en användarorganisations digitala banksäkerhetsnycklar, som används för att autentisera 
banktransaktioner.
-    Ändra all information i användarorganisationens Basware Banking programvara, inklusive transaktionshistorik samt 
de transaktioner som väntar i kö.
-    Ta bort alla behörighetsbegränsningar (åtkomstkontroll) i användarorganisationens klientprogramvara.
Dessa risker påverkar minst 1500 användarorganisationer (företag) i de nordiska och baltiska länderna, främst i Finland 
och Sverige. För att skydda sig mot dessa risker, kan det vara nödvändigt att helt förnya de berörda digitala 
banksäkerhetsnycklarna, förutom att också korrigera sårbarheterna i programvaran, eller sluta använda den sårbara 
programvaran. En användarorganisation kan behöva hjälp av de banker, där de har givit Basware Banking programvaran rätt 
att använda sina bankonton, för att åstadkomma dessa förändringar och förhindra möjligt bedrägeri genom de sårbarheter 
som tillåter att banksäkerhetsnycklarna kopieras. Beroende på hur processerna är definierade och den tekniska 
säkerheten är förverkligad i en bank, kan förverkligande av de nödvändiga förändringarna antingen påverka eller inte 
påverka även andra bankkunder som inte använder Basware Banking programvaran.


Full report, English only


Description of the affected software:
The Basware Banking/Maksuliikenne software (henceforth “the software”) is a cash/bank account management software 
package for enterprises from software vendor Basware (henceforth “the vendor”).  According to the best information the 
author of this report has, it is used by between 1,500 and 2,000 customer organizations, primarily companies throughout 
the Nordic and Baltic regions.  The software operates as a thick client/server package, with both clients and servers 
running on the Windows platform.  The server component is primarily an IBM Solid database server.  It is possible to 
have the client and server components installed and operating on the same system. In that case, if the system has a 
properly configured firewall preventing unauthorized access, the CVE-2015-0943 vulnerability described below can be 
effectively mitigated.


Description of the vulnerabilities:
In August 2012 and June—July 2014, multiple vulnerabilities were found in the software by the author and reported to 
the vendor.  Because the vendor was unable to reproduce the issues described or to confirm the presence of any 
vulnerability, a demonstration was given to the vendor as well as to CERT-FI in July 2014.  The author was later 
informed by CERT-FI that the vendor stated all but one of these security issues had been fixed and that the fixes had 
been made available to affected customers. However, the author has not been provided with updated software to verify 
the resolutions himself.  This report is based on the author’s best knowledge on 27 July 2015. Affected version ranges 
and fixed version information are incomplete.  Two CVE numbers were provided to the author by CERT-FI for the 
vulnerabilities: one for the issue that was still considered unresolved, and one for all issues that the vendor stated 
were resolved.

CVE-2015-0942
CVSSv2 score: 10.0 – Critical
CVSS v2 Vector (AV:N/AC:L/Au:N/C:C/I:C/A:C)
The issues in CVE-2015-0942 are issues that the vendor has informed the author to be resolved, with fixes available to 
customers, but the latest update provided by the vendor to the author does not appear to adequately resolve them. 
Affected versions are at minimum 8.40.1.0 to 8.90.07.X (The latest provided to the author).

Issue #1: Hard-coded account used for account management
All instances of the software use the same hard-coded account with an identical password for account management.  This 
account, with the name "ANCO", is not only identical for all installations, but is also used for security-sensitive 
tasks.  This account has sufficient permissions to perform account management tasks on other accounts, such as locking 
or unlocking other user accounts, as well as updating the audit trails for other accounts.
As of version 8.90.07.X, a static account for account management tasks is still present. However, the account no longer 
has full database permissions.  The account name (and possibly password) is also different for each installation of the 
software, but can be found using information that can be accessed using an additional hard-coded account that was added 
to the server, which uses the same username and password for all installations.

Issue #2: Use of client-side access control/auditing only
The software performs login verification, audit trail creation, and even account locking via client-side functions.  By 
simply dropping network traffic related to these functions, it is possible to disrupt security-critical functions, such 
as audit-trail creation for failed login attempts and account locking to prevent brute force attacks. As of version 
8.90.07.X an attacker can even prevent the client from locking an account to prevent brute forcing by ending the 
software’s process via the Windows Task Manager; the account is only locked after acknowledging the notification.
In addition, the author discovered that as of version 8.90.07.X, possibly as part of the changes to prevent abuse of 
the account for account management described in issue #1 above, accounts are no longer locked/disabled at all in the 
server.  Instead, the account name is added to a table of locked accounts, and after a successful login as a user, a 
check of that table is made to see if the account is considered “locked”.  If the account is in the locked account 
table, the client software prompts that the user account is locked and logs the user out.  This is purely a client-side 
check and the users actually have full permissions to modify the contents of that table, which allows any user to 
delete their own account lock.

Issue #3: Unprotected storage of private keys used for banking transactions
The private keys that are used by the software to communicate with the customer organization's bank are available to 
users of the software in plain text (or trivially protected in later versions) in the SQL database.  As of version 
8.90.07.X  these keys are available to all users of the software, even if the access control policies provided to the 
system administrators are specifically set to restrict access from the users.  The usage of these keys allows an 
attacker to completely bypass the control mechanisms in place and impersonate the software or a valid authorized 
account holder to various online banking systems directly, enabling authentication of fraudulent requests.

Issue CVE-2015-0943
CVSSv2 Score: 8.3 – High
CVSS v2 Vector (AV:A/AC:L/Au:N/C:C/I:C/A:C)
The vendor has informed the author and customers in an email sent 13 October 2014 to all customers that this issue will 
be resolved in 2015 using native Solid DB encryption. Affected versions are at minimum 8.40.1.0 to 8.90.07.X.

Issue #4: Use of plain text for all SQL server communications
The communications between the thick client and the backend (SQL) server are done in plain text and without tamper 
protection.  Any hostile actor who is able to perform a man-in-the-middle attack on the communications can manipulate 
all information sent between the SQL server and the client. A man-in-the-middle attack would allow complete 
modification of all banking/payment information, access to bank account encryption keys, modification of all payment 
records, etc.  Even if an attacker is not able to perform a man-in-the-middle attack on the communications, access to 
packet captures can still reveal sensitive banking information, user credentials for the banking system, and possibly 
also encryption keys, which might allow direct impersonation of authorized users to the banks.  There is also no replay 
protection, so an attacker who has a copy of the messages sent from the client to the server during user login can 
reuse those same messages to gain full access to the banking server.
This issue was partially confirmed by the vendor in an announcement sent to their customers in October 2014, with an 
offer of a work-around using 3rd-party solutions provided by contacting vendor support.


Suggestions for organizations using the software:
Disclaimer: The suggestions below may assist your risk management or information security department in determining 
appropriate actions for your organization based on your environment and security posture.  These suggestions are in no 
way meant to be instructions or to provide protection against or detection of abuse.  Any response should be tailored 
to your organization by competent internal or external experts who understand the software vulnerabilities as well as 
your organization's policies, procedures, and operational environment.
-    Contact Basware and ensure that you are running the latest version of the Banking software.  Follow any 
recommendations applicable provided by Basware to reduce your security  risks.
-    Have the software evaluated in your environment by a skilled security engineer or penetration tester to validate 
that these security vulnerabilities have been resolved.
-    Move the Banking server to a location where it is only accessible from trusted networks.
-    Remove unneeded user accounts or accounts belonging to untrusted users from the Banking software.
-    Consider transferring money out of accounts managed by the Banking software to reduce the amount of financial 
damage in case of a breach, and keeping minimal operating expenses in the at-risk accounts.
-    Perform internal audit of bank account balances and transaction history, retrieving the account information 
directly from the bank. This is recommended because the records in the Banking software can be tampered with.
-    Consider blocking all network access to the Banking server and performing transactions using only clients 
installed on the same system as the server.
-    Investigate whether the security of your environment may have been compromised at any time, or whether the Banking 
software may have been accessible directly.  If so, contact all banks that have private keys stored in the software to 
revoke those keys as a fraud prevention measure. Securely replace those keys only after the risks have been addressed.
-    Use a third-party encryption solution that provides strong encryption and authentication of network communications 
for the Banking software to protect against tampering, and ensure that only encrypted and authenticated connections to 
the Banking server are possible.
-    Install current anti-virus and anti-malware software as well as all vendor-provided security updates on the 
Banking server and any computers where the Banking client is used. 
-    Consider using whitelisting to control the software allowed to execute on the Banking server as well as on any 
computers where the Banking client is used.
-    Establish procedures as part of the software acquisition process to verify vendor security claims as well as 
fitness for use.


Timeline
Dates are approximate and to the best of the author’s memory, as the author was not the primary person handling 
communications with the vendor.
August, 2012
    The author discovered plain-text unauthenticated communications and client-side account locking bypass in a 
previous version (8.40.1.0) and informed vendor support personnel when they were resolving another issue with the 
software. Vendor support said that the author was incorrect, as the software version in question was outdated, and had 
known security issues.  The author was told by the vendor’s support technician that the security issues were already 
resolved in an update, which would be installed by the vendor in the near future.
September, 2013
    The software was updated to version 8.70.0.0 as part of other updates.  The author did not verify at that time that 
the update resolved the security issues that had been found.
19 June, 2014
    The author encountered the software again and discovered that the same issues still existed. Further research was 
done by the author and the vendor was contacted with detailed findings. The author offered to provide a demo as the 
vendor reported that they were unable to reproduce the issues.
7 July, 2014
    The author provided a demo for the vendor and CERT-FI, showing the vulnerabilities and working proof-of-concept 
exploits, which gave the ability to change bank account balances and the records of banking transactions in the system, 
as well as copying the private banking keys used for communication with the banks.
Week of 7 July, 2014
    Confirmation was received from the vendor that they were able to reproduce the findings now that the issue was 
understood.  The author was informed that the vendor was working towards providing a fix and would keep the author 
updated.
Regularly from this point on, the author checked with the party handling communication with the vendor, but was not 
given any update on the issue or told anything about fixes being available.
14 January, 2015
    The author was informed that all security issues had been resolved by the vendor.   The author was asked to 
re-verify his findings in the software installation.
15 January, 2015
    The author confirmed that all security issues still applied and that the  software installation was not updated.  
Further updates were requested from the vendor.
Week of 23 February, 2015
    The author was informed that someone in the media had found out about the security vulnerabilities and was 
preparing to go public.  The author contacted CERT-FI to organize CVE numbers and was told that progress had been made 
and CERT-FI had been told by the vendor that all but one of the vulnerabilities were resolved.  CERT-FI was asked by 
the author to encourage the vendor to respond to communication attempts and to provide the security updates for review.
4 March, 2015
    The product manager for the vendor contacted the author, offering to provide installation of security updates.  
This was scheduled for 11 March.
6 March, 2015
    Helsingin Sanomat (HS) published an article on Basware security vulnerabilities.  Following this, CERT-FI published 
their statements in Finnish and in English.  The author was asked by CERT-FI not to disclose any more details until the 
author evaluated the security fixes, in case the fixes were inadequate.
-    The HS article “Paha tietoturva-aukko altistaa yritykset valemaksuille”: (Finnish only, English translation of the 
title is “Bad security vulnerability exposes companies to fraudulent payments”): http://www.hs.fi/talous/a1425539014674
-    CERT-FI publication “Vulnerabilities in Basware Banking“ (English): 
https://www.viestintavirasto.fi/en/cybersecurity/vulnerabilities/2015/haavoittuvuus-2015-018.html
-    CERT-FI publication “Haavoittuvuuksia Basware Maksuliikenne -ohjelmistossa “ (Finnish):
https://www.viestintavirasto.fi/kyberturvallisuus/haavoittuvuudet/2015/haavoittuvuus-2015-018.html
11 March, 2015
    The vendor provided updates, but it became apparent to the author during this process that issues still remained 
unresolved.  CERT-FI was contacted and it was agreed that they would send a technical expert to assist with a review.
13 March, 2015
    The author and a technical expert from CERT-FI thoroughly analyzed the software and determined that the findings 
described above were still valid.  The author was asked to give the vendor 42 days to resolve the issues before public 
disclosure.
28 July, 2015
    Full disclosure.

Current thread: