Verichains' analysis reveals that several Vietnamese banking apps improperly use private iOS APIs, potentially jeopardizing user security and app stability. These apps employ undocumented functions to gather device information, bypass sandbox restrictions, and manipulate UI elements, likely in pursuit of enhanced functionality or anti-fraud measures. However, reliance on these private APIs violates Apple's developer guidelines and creates risks, as these APIs can change without notice, leading to app crashes or malfunctions. Furthermore, this practice exposes users to potential security vulnerabilities that malicious actors could exploit. The report details specific examples of private API usage within these banking apps and emphasizes the need for developers to adhere to official guidelines for a safer and more reliable user experience.
The blog post "Entropy Attacks" argues against blindly trusting entropy sources, particularly in cryptographic contexts. It emphasizes that measuring entropy based solely on observed outputs, like those from /dev/random, is insufficient for security. An attacker might manipulate or partially control the supposedly random source, leading to predictable outputs despite seemingly high entropy. The post uses the example of an attacker influencing the timing of network packets to illustrate how seemingly unpredictable data can still be exploited. It concludes by advocating for robust key-derivation functions and avoiding reliance on potentially compromised entropy sources, suggesting deterministic random bit generators (DRBGs) seeded with a high-quality initial seed as a preferable alternative.
The Hacker News comments discuss the practicality and effectiveness of entropy-reduction attacks, particularly in the context of Bernstein's blog post. Some users debate the real-world impact, pointing out that while theoretically interesting, such attacks often rely on unrealistic assumptions like attackers having precise timing information or access to specific hardware. Others highlight the importance of considering these attacks when designing security systems, emphasizing defense-in-depth strategies. Several comments delve into the technical details of entropy estimation and the challenges of accurately measuring it. A few users also mention specific examples of vulnerabilities related to insufficient entropy, like Debian's OpenSSL bug. The overall sentiment suggests that while these attacks aren't always easily exploitable, understanding and mitigating them is crucial for robust security.
Nvidia's security team advocates shifting away from C/C++ due to its susceptibility to memory-related vulnerabilities, which account for a significant portion of their reported security issues. They propose embracing memory-safe languages like Rust, Go, and Java to improve the security posture of their products and reduce the time and resources spent on vulnerability remediation. While acknowledging the performance benefits often associated with C/C++, they argue that modern memory-safe languages offer comparable performance while significantly mitigating security risks. This shift requires overcoming challenges like retraining engineers and integrating new tools, but Nvidia believes the long-term security gains outweigh the transitional costs.
Hacker News commenters largely agree with the AdaCore blog post's premise that C is a major source of vulnerabilities. Many point to Rust as a viable alternative, highlighting its memory safety features and performance. Some discuss the practical challenges of transitioning away from C, citing legacy codebases, tooling, and the existing expertise surrounding C. Others explore alternative approaches like formal verification or stricter coding standards for C. A few commenters push back on the idea of abandoning C entirely, arguing that its performance benefits and low-level control are still necessary for certain applications, and that focusing on better developer training and tools might be a more effective solution. The trade-offs between safety and performance are a recurring theme.
A newly released U.S. government report reveals that 39 zero-day vulnerabilities were disclosed in 2023. This marks the first time the Cybersecurity and Infrastructure Security Agency (CISA) has publicly shared this data, which is gathered through its Vulnerability Disclosure Policy (VDP). The report covers vulnerabilities affecting a range of vendors, including Google, Apple, and Microsoft, and provides insights into the types of vulnerabilities reported, though specific details are withheld to prevent exploitation. The goal of this increased transparency is to improve vulnerability remediation efforts and bolster overall cybersecurity.
Hacker News users discussed the implications of the US government's first-ever report on zero-day vulnerability disclosures. Some questioned the low number of 39 vulnerabilities, speculating it represents only a small fraction of those actually discovered, with many likely being kept secret for offensive purposes. Others pointed out the inherent limitations in expecting complete transparency from intelligence agencies. Several comments highlighted the report's ambiguity regarding the definition of "zero-day," and whether it includes vulnerabilities actively exploited in the wild. There was also discussion around the value of such disclosures, with some arguing it benefits adversaries more than defenders. Finally, some commenters expressed concern about the potential for the government to hoard vulnerabilities for offensive capabilities, rather than prioritizing patching and defense.
Summary of Comments ( 7 )
https://news.ycombinator.com/item?id=43502385
Several Hacker News commenters discuss the implications of the Verichains blog post, focusing on the potential security risks of using private APIs. Some express surprise at the prevalence of this practice, while others point out that using private APIs is a common, though risky, way to achieve certain functionalities not readily available through public APIs. The discussion touches on the difficulty of Apple enforcing its private API rules, particularly in regions like Vietnam where regulatory oversight might be less stringent. Commenters also debate the ethics and pragmatism of this practice, acknowledging the pressure developers face to deliver features quickly while also highlighting the potential for instability and security vulnerabilities. The thread includes speculation about whether the use of private APIs is intentional or due to a lack of awareness among developers.
The Hacker News post titled "Technical Analysis – Improper Use of Private iOS APIs in Vietnamese Banking Apps" has generated several comments discussing the implications of the article's findings.
Several commenters focused on the security risks associated with using private APIs. One commenter highlights the potential for malicious apps to exploit these same private APIs, potentially bypassing security measures or accessing sensitive user data. They mention the "walled garden" approach of iOS and how circumventing it introduces vulnerabilities. Another commenter reinforces this by pointing out that Apple explicitly warns against using private APIs, and doing so can lead to app rejection from the App Store. They express concern that these banking apps were able to get through the review process despite this violation.
The discussion also touches on the motivations behind using private APIs. One commenter speculates that developers might resort to private APIs due to limitations or perceived deficiencies in the public APIs provided by Apple. They suggest that this situation highlights a potential gap in functionality offered by official means. Another commenter cynically suggests that the developers might be knowingly taking shortcuts to achieve desired functionality without going through proper channels or investing in more robust solutions.
A few commenters discuss the implications for users of these banking apps. One expresses concern about the potential for data breaches or other security compromises due to the use of these private APIs. Another commenter questions the overall security posture of these Vietnamese banks, suggesting a lack of due diligence in their app development practices.
The conversation also drifts towards the broader issue of private API usage and app store review processes. One commenter questions the effectiveness of Apple's app review process in catching these violations. Another commenter mentions the cat-and-mouse game between developers trying to use private APIs and Apple trying to prevent them. They note that this is an ongoing issue and that developers often find creative ways to circumvent the restrictions.
Finally, one commenter questions the severity of the issue, suggesting that the specific private APIs mentioned in the article might not pose a significant security risk. However, this is countered by another commenter who emphasizes that any use of private APIs is a violation of Apple's guidelines and opens the door to potential security vulnerabilities, regardless of the specific APIs used.