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/
- CERT-FI publication “Vulnerabilities in Basware Banking“ (English):https://www.viestintavirasto.
- CERT-FI publication “Haavoittuvuuksia Basware Maksuliikenne -ohjelmistossa “ (Finnish):
https://www.viestintavirasto.
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.
Komentarų nėra:
Rašyti komentarą