SEC Consult Vulnerability Lab Security Advisory < 20250908-0 > ======================================================================= title: NFC Card Vulnerability Exploitation Leading to Free Top-Up product: KioSoft "Stored Value" Unattended Payment Solution (Mifare) vulnerable version: Current firmware/hardware as of Q2/2025 fixed version: No version numbers available CVE number: CVE-2025-8699 impact: High homepage: https://kiosoft.com/ found: 2023-10-01 by: Steffen Robertz SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden business Europe | Asia https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "KioSoft – a technology leader in the Payments industry since 2002. We offer the best of the world in unattended payments with our global presence. The self-service industry is typically comprised of technology aggregators, as opposed to technology innovators. KioSoft is the latter. We believe that innovation comes from ownership and control of the products we design. This single source, customer- focused mentality is evident in everything we do. We never stop innovating. We continually push the boundaries to bring new ideas to life." Source: https://kiosoft.com/about-us/ Business recommendation: ------------------------ Some KioSoft customers currently use outdated MiFare Classic cards in "Stored Value" Unattended Payment Solutions from KioSoft. A new detection algorithm has been rolled out through firmware according to Kiosoft. As a long-term fix, hardware changes with a new reader and secure cards are planned as well. KioSoft understands that its customers continually take steps to track suspicious activity as routine. Mifare Classic cards have been found to be vulnerable to attacks in the past, allowing these cards to be modified or copied. A short-term solution may be to transition away from the Stored Value Payment System to the Online Payment System of KioSoft, which does not have this vulnerability according to the vendor. For further information regarding Mifare Classic security see: https://en.wikipedia.org/wiki/MIFARE#Security Contact the supplier for details about updated firmware and hardware solutions which address this issue. Vulnerability overview/description: ----------------------------------- 1) NFC Card Vulnerability Exploitation Leading to Free Top-Up (CVE-2025-8699) The account balance is stored on an insecure MiFare Classic NFC card in some KioSoft "Stored Value" Unattended Payment Solutions. This means the cards can be read and written back. By manipulating the right field, one can "create money out of thin air" and use it to pay for goods. Proof of concept: ----------------- 1) NFC Card Vulnerability Exploitation Leading to Free Top-Up (CVE-2025-8699) Some Kiosoft payment cards use a MiFare Classic card. This card type is inherently insecure due to its use of the insecure, proprietary Crypto1 algorithm developed by NXP (security statement: https://www.mifare.net/en/products/chip-card-ics/mifare-classic/security-statement-on-crypto1-implementations/). Thus, all contents can be read if one owns the correct hardware (e.g., a Proxmark). By carefully observing changes in card dumps, one can identify fields that store the cash value of the card. Additionally, a checksum can be identified, which is created by XOR-ing the cash and an unknown field with a certain value and [redacted]. By updating the fields accordingly, arbitrary amounts of money can be loaded onto the card (up to $655,35). In order to exploit this, a correct dump file has to be obtained first. This can be done by, e.g., running the following Proxmark command: "hf mf autopwn" This will generate a .bin file of the card's content and a file containing the keys per block. The dump file can then be modified using the following Python script: [ Proof of concept exploit removed ] After the modification, the file can then be written to a Chinese magic tag by issuing the following Proxmark command: "hf mf cload -f kiosoft_mod.bin" Further, the UID has to be modified to the UID of the original Kiosoft tag (displayed when running the script) by issuing following Proxmark command: "hf mf csetuid -u <uid>" Now, the card is topped-up to the amount provided to the script and can be used to pay at any Kiosoft terminal. Vulnerable / tested versions: ----------------------------- It was not possible to determine a software version. As of Q2/2025, all cards in use are affected. Vendor contact timeline: ------------------------ 2023-10-09: Contacting vendor through support () kiosoft com 2023-10-09: Auto-response, case is being tracked as # 00048266 2023-11-09: Asked about ticket status, as only an auto reply answer has been received. 2023-11-20: Contacted vendor again via support () kiosoft com and info () kiosoft com, Automated reply that case is being tracked as # 00051048 No further response. 2024-01-16: Contacting CERT/CC for coordination support via VINCE platform. VU#627613. No response from vendor. 2024-02-01: Asking for a status update via VINCE. 2024-02-02: CERT/CC asks Kiosoft about a response, CVE or if further assistance is needed 2024-02-02: Kiosoft, engineering team was informed, will respond shortly. Asking for an extension for the publication. 2024-02-23: Asking for a status update. No response. 2024-03-04: Asking CERT/CC how to proceed as vendor is once again unresponsive. 2024-03-05: Kiosoft engineering member joins VINCE, very detailed answer regarding their communication (+apologies), proposed measures, disclosure timelines, etc. 2024-03-07: We still plan to release advisory, but understand complexity of protecting end users, will extend deadline, asking whether customers will be informed. 2024-03-10: Kiosoft, informing customers is paramount, committed to keeping them informed. 2024-03-11: Giving feedback about the proposed solution. 2024-03-11: CERT/CC: Adding feedback, asking for recommended approaches. 2024-03-21: Providing feedback. 2024-03-25: Kiosoft, detailed response regarding potential fixes and feasibility. 2024-04-29: Asking for a status update/timeline. 2024-04-29: Kiosoft, issue is on development roadmap, but no assigned dates yet. Estimation is around Q4/24 until Q1/25. 2024-07-25: CERT/CC asks for a status update. 2024-07-29: Kiosoft, new algorithm will be part of major terminal FW rollout, planned for Q4/24. Also discussing long-term fix with HW changes to support more secure cards, tentative timeline of 2025. 2024-11-11: Asking for a status update; no response. 2025-02-03: Asking for a status update; no response. 2025-02-18: Contacting CERT/CC because of unresponsive vendor. CERT/CC asks Kiosoft for a status update. 2025-02-18: Kiosoft, working on new reader for better cards. Existing installations will be tracked for suspicious activity. Some portions of the code already released, further updates in 2025. 2025-02-19: Asking Kiosoft regarding timeline and clarification of current detection capabilities. No response. 2025-03-03: CERT/CC asks SEC Consult about our next steps. We respond that if detection capabilities are already adequate, we would release our advisory then. 2025-03-03: Kiosoft, their customers are tight on accounting and laundry cycles are monitored, no suspicious activity detected. Proactive detection code is postponed, will come Q3/Q4 2025, instead of Q4 2024. 2025-03-04: Asking CERT/CC for guidance to proceed with this case, as customers of Kiosoft are already tracking activity and a proper fix has been postponed again. 2025-03-04: CERT/CC concurs that a release of the advisory is fine now. 2025-03-05: Informing CERT/CC and vendor that a release will be planned in March, providing advisory draft via VINCE. 2025-03-07: Updating advisory with feedback from vendor. 2025-03-14: Vendor has more feedback regarding advisory and affected products. Asks for postponement of advisory release. 2025-03-17: Adjusting advisory, postponing for three weeks. 2025-03-18: Vendor requests further postponement because of necessary time for preparation of communication to their customers. 2025-03-18: Postponing to mid May. 2025-04-22: Vendor asks to delay the advisory until after the patch (end of June) 2025-07-28: Asking for a status update and the fixed version number. Vendor replies that a patch is out but they do not want to release version numbers. 2025-07-30: Recommending to publish version numbers. Vendor denies because of close relationship with their B2B customers who will be informed. 2025-08-07: Sent draft to vendor. 2025-08-12: Release of security advisory planned but postponed due to internal matters. 2025-09-08: Public release of security advisory. Solution: --------- Contact the supplier for details about updated firmware and hardware solutions which address this issue. Workaround: ----------- None Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden business Europe | Asia About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Eviden business. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: security-research at sec-consult dot com Web: https://www.sec-consult.com Blog: https://blog.sec-consult.com X: https://x.com/sec_consult EOF Steffen Robertz / @2025
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/