3 ms·

Google Play rolls out an "Independent security review" badge for apps

13 points by Terretta 3y ago

westurner 3y ago
https://www.bleepingcomputer.com/news/security/google-play-adds-security-audit-badges-for-android-vpn-apps/ https://www.bleepingcomputer.com/news/security/google-play-a... : > Specifically, that standard is MASA (Mobile App Security Assessment), which was introduced last year as an initiative of the App Defense Alliance (ADA) to define a concrete set of requirements for mobile app security. > The requirements concern data storage and data privacy practices, cryptography, authentication and session management, network communication, platform interaction, and code quality. App Defense Alliance > Mobile Application Security Assessment: https://appdefensealliance.dev/masa https://appdefensealliance.dev/masa OWASP Mobile Application Security: https://mas.owasp.org/ https://mas.owasp.org/ : > The OWASP Mobile Application Security (MAS) flagship project provides a security standard for mobile apps (OWASP MASVS) and a comprehensive testing guide (OWASP MASTG) that covers the processes, techniques, and tools used during a mobile app security test, as well as an exhaustive set of test cases OWASP MAS Checklist .xlsx: https://github.com/OWASP/owasp-mastg/releases/latest/download/OWASP_MAS_Checklist.xlsx https://github.com/OWASP/owasp-mastg/releases/latest/downloa... OWASP/owasp-mastg: https://github.com/OWASP/owasp-mastg https://github.com/OWASP/owasp-mastg : > The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS). OWASP/owasp-masvs: https://github.com/OWASP/owasp-masvs https://github.com/OWASP/owasp-masvs : > The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security.
creatonez 3y ago
> MSTG-CODE-3 > Debugging symbols have been removed from native binaries What's wrong with debugging symbols, from a security perspective? What if you desire maximum inspectability of the internals? Other than that, these guidelines seem great.
- creatonez 3y ago
  I found a more detailed explanation of it: https://github.com/julepka/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md#testing-for-debugging-symbols-mstg-code-3 https://github.com/julepka/owasp-mstg/blob/master/Document/0... > Generally, you should provide compiled code with as little explanation as possible. Some metadata, such as debugging information, line numbers, and descriptive function or method names, make the binary or bytecode easier for the reverse engineer to understand, but these aren't needed in a release build and can therefore be safely omitted without impacting the app's functionality. I'm not a big fan of the reasoning, as it's security through obscurity. Which is not the worst tradeoff, as many vulnerable systems hold up for years thanks to machine code obfsucation, but these days it just makes public bug bounties (and other public auditing) end up being less of an interesting prospect for improving security. Many bug bounties nowadays help participants by, for example, leaving an entire web API's documentation open to view. It's the same sort of thing as leaving source code public -- should that be a disqualifier under such guidelines?
- westurner 3y ago
  It could be that it's easier to reverse (closed source) apps (with unreviewed code after each DevSecOps Pull Request with Changelog entry) with debugging symbols. gdb on Fedora auto-installs signed debuginfo packages with debug symbols; Fedora hosts a debuginfod server for their packages (which are built by Koji) and sets `DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ https://debuginfod.fedoraproject.org/ ` : https://fedoraproject.org/wiki/Debuginfod https://fedoraproject.org/wiki/Debuginfod https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#Security_FAQ https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#S... Without debug symbols, a debugger has to read unlabeled ASM instructions (or VM opcodes (or an LL IR)). From "Show HN: Tetris, but the blocks are ARM instructions that execute in the browser" https://news.ycombinator.com/item?id=37086102 https://news.ycombinator.com/item?id=37086102 : > "Ask HN: How did you learn x86-64 assembly?" (2020) re: HLA, : https://news.ycombinator.com/item?id=23931373 https://news.ycombinator.com/item?id=23931373 re: the Diaphora bindiff tool and ghidra, which has GDB support now FWIU: https://news.ycombinator.com/item?id=36454485 https://news.ycombinator.com/item?id=36454485 "Show HN: Ghidra Plays Mario" the NES ROM. https://news.ycombinator.com/item?id=37475761 https://news.ycombinator.com/item?id=37475761

13 points by Terretta 3y ago

https://www.bleepingcomputer.com/news/security/google-play-adds-security-audit-badges-for-android-vpn-apps/ https://www.bleepingcomputer.com/news/security/google-play-a... : > Specifically, that standard is MASA (Mobile App Security Assessment), which was introduced last year as an initiative of the App Defense Alliance (ADA) to define a concrete set of requirements for mobile app security. > The requirements concern data storage and data privacy practices, cryptography, authentication and session management, network communication, platform interaction, and code quality. App Defense Alliance > Mobile Application Security Assessment: https://appdefensealliance.dev/masa https://appdefensealliance.dev/masa OWASP Mobile Application Security: https://mas.owasp.org/ https://mas.owasp.org/ : > The OWASP Mobile Application Security (MAS) flagship project provides a security standard for mobile apps (OWASP MASVS) and a comprehensive testing guide (OWASP MASTG) that covers the processes, techniques, and tools used during a mobile app security test, as well as an exhaustive set of test cases OWASP MAS Checklist .xlsx: https://github.com/OWASP/owasp-mastg/releases/latest/download/OWASP_MAS_Checklist.xlsx https://github.com/OWASP/owasp-mastg/releases/latest/downloa... OWASP/owasp-mastg: https://github.com/OWASP/owasp-mastg https://github.com/OWASP/owasp-mastg : > The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS). OWASP/owasp-masvs: https://github.com/OWASP/owasp-masvs https://github.com/OWASP/owasp-masvs : > The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security.

creatonez 3y ago

> MSTG-CODE-3 > Debugging symbols have been removed from native binaries What's wrong with debugging symbols, from a security perspective? What if you desire maximum inspectability of the internals? Other than that, these guidelines seem great.

creatonez 3y ago
I found a more detailed explanation of it: https://github.com/julepka/owasp-mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md#testing-for-debugging-symbols-mstg-code-3 https://github.com/julepka/owasp-mstg/blob/master/Document/0... > Generally, you should provide compiled code with as little explanation as possible. Some metadata, such as debugging information, line numbers, and descriptive function or method names, make the binary or bytecode easier for the reverse engineer to understand, but these aren't needed in a release build and can therefore be safely omitted without impacting the app's functionality. I'm not a big fan of the reasoning, as it's security through obscurity. Which is not the worst tradeoff, as many vulnerable systems hold up for years thanks to machine code obfsucation, but these days it just makes public bug bounties (and other public auditing) end up being less of an interesting prospect for improving security. Many bug bounties nowadays help participants by, for example, leaving an entire web API's documentation open to view. It's the same sort of thing as leaving source code public -- should that be a disqualifier under such guidelines?
westurner 3y ago
It could be that it's easier to reverse (closed source) apps (with unreviewed code after each DevSecOps Pull Request with Changelog entry) with debugging symbols. gdb on Fedora auto-installs signed debuginfo packages with debug symbols; Fedora hosts a debuginfod server for their packages (which are built by Koji) and sets `DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ https://debuginfod.fedoraproject.org/ ` : https://fedoraproject.org/wiki/Debuginfod https://fedoraproject.org/wiki/Debuginfod https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#Security_FAQ https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#S... Without debug symbols, a debugger has to read unlabeled ASM instructions (or VM opcodes (or an LL IR)). From "Show HN: Tetris, but the blocks are ARM instructions that execute in the browser" https://news.ycombinator.com/item?id=37086102 https://news.ycombinator.com/item?id=37086102 : > "Ask HN: How did you learn x86-64 assembly?" (2020) re: HLA, : https://news.ycombinator.com/item?id=23931373 https://news.ycombinator.com/item?id=23931373 re: the Diaphora bindiff tool and ghidra, which has GDB support now FWIU: https://news.ycombinator.com/item?id=36454485 https://news.ycombinator.com/item?id=36454485 "Show HN: Ghidra Plays Mario" the NES ROM. https://news.ycombinator.com/item?id=37475761 https://news.ycombinator.com/item?id=37475761