Tag: 移动安全

适用于iOS的“ Meitu”应用程序中有关Analytics Collection的技术信息

今天有一些骚动涉及到名为Meitu的移动应用程序。 这篇文章仅关注iOS版本(如果有兴趣,其他人已经初步了解了Android版本)。 评估内容(v6.1.1) “ 美图秀秀 ”(com.meitu.mtxx) “ MTXXFilterExtension”( com.meitu.mtxx.MTXXFilterExtension ) “ MTMosaicMessage ”(com.meitu.mtxx.MTMosaicMessage) 收集的分析信息 设备IMEI,IMSI和MAC地址似乎没有发送到Meitu的第一方或任何打包的第三方分析服务器。 无法在更新为最新固件版本的iOS设备上获取与无线电有关的敏感信息。 在初步测试过程中,Meitu应用程序确实向服务器发送了伪造的MAC地址“ 02:00:00:00:00:00”。 乔纳森·兹齐亚斯基(Jonathan Zdziarski)提到了Meitu应用程序对MAC地址的使用,因为二进制代码仍包含用于获取设备MAC地址的功能。 但是,如上所述,App Store沙箱中的iOS应用程序无法访问设备的真实MAC地址(与IMEI和IMSI一样)。 对于iOS 8或更高版本的设备,此功能没有风险。 以下信息似乎确实已发送到Meitu分析服务器(adui.tg.meitu.com):iOS版本(例如“ 10.2”),设备型号(例如“ iPhone7,2”),网络类型(例如“ WiFi”),设备语言,设备区域设置,移动国家/地区代码以及随机生成的唯一标识符。 正如乔纳森·兹齐亚斯基(Jonathan Zdziarski)指出的,由于使用了第三方分析库,Meitu应用程序确实获得了蜂窝提供商的名称。 蜂窝提供商名称将发送到第三方分析提供商Umeng / Youmi(alogs.umeng.com)的服务器。 “ channel_id”也发送到adui.tg.meitu.com服务器。 由于大量使用“辅助”或“辅助”工具在该地区旁加载应用程序,因此这在中国应用程序中很常见。 直接从App Store下载应用程序后,将在此参数下发送值“ App Store”。 Meitu应用程序收集GPS位置( 如果已授权 ),并将其发送到分析服务器。 我无法高度确定发送GPS位置的分析服务器,但我有一定的信心,认为该分析服务器是第三方分析服务器,并未由Meitu本身直接调用(旁注:Meitu确实请求访问权限位置带有模糊信息“开启后美图秀秀才可访问你的地理位置哦”,但直接归因于美图本身的唯一用例是为用户检查当地天气。 专用API的使用 正如Jonathan Zdziarski所指出的那样,该应用程序包含从私有框架加载两个功能的代码。 但是, 此代码不能按原样工作 。 这是因为该应用程序从路径“ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/System/Library/PrivateFrameworks/GraphicsServices.framework/ GraphicsServices”(此路径在iOS设备上不存在)。 Meitu应用程序中确实存在一些代码,可以允许在运行时动态加载私有框架。 但是,没有迹象表明已使用它。 […]

Apple iOS 12:有史以来最安全的iOS吗?

如果您碰巧看到了Apple在2018年6月4日发布的iOS 12初始版本,您可能已经注意到它缺少我们从其他iOS版本中看到的“大飞溅”。 部分原因是苹果公司忙于专注于新的iOS 12数据安全功能。 尽管将在2018年9月12日的Apple Keynote活动上发布更多功能,但已揭示的iOS 12的许多功能可能不会引起普通消费者的注意。 那是故意的。 良好的数据安全性功能对于大多数用户而言并不明显。 如果有的话,苹果最新的移动操作系统中的这些功能将使普通iPhone用户的生活更加轻松。 但是,如果您恰好是IT或安全专家,那么新的iOS 12可能会激起您的兴趣。 苹果公司对个人数据隐私和安全的强调引发了一个问题:iOS 12是苹果发布过的最安全的操作系统吗? 一言以蔽之。 让我们研究一下它为何如此安全。 更好的防黑客技术以保护数据隐私 苹果对新iOS安全所做的最大改变之一是USB受限模式的引入。 在iOS 11和更低版本的iOS上,基于USB的通信在手机锁定后最多可保持七天。 这意味着,如果iPhone被盗,则可能的黑客有7天的时间将强力设备(例如GrayKey)插入手机并强制其解锁。 纽约时报称此为期7天的窗口是iOS 11中的一个重大安全漏洞。 好消息是苹果正在关闭此窗口。 借助iOS 12上的USB受限模式,Apple将基于USB的通信时间缩短到手机锁定后仅一小时。 这使得在iOS 12上进行暴力攻击几乎是不可能的。 根据一位与我们交谈的应用程序开发人员的说法,“ USB受限模式本质上是在一小时后将手机变成电池供电的砖块。”除非该手机在该小时时间内被授权用户解锁,否则对黑客来说毫无用处。 为了进一步说明这一点,如果您公司的员工在iPhone上安装了iOS 11的iPhone被盗,那么窃贼很有可能在7天内获得对手机的访问权限。 但是,如果安装了iOS 12,则小偷将只有一个小时的时间来尝试暴力攻击。 在一个小时内实现这一目标的可能性很小。 新的操作系统会自动打开此数据隐私功能,但Apple确实提供了禁用它的选项: 图片来源 我们为提高个人数据安全性的实力和灵活性而感到兴奋。 密码重用审核 与任何数据安全系统一样,人是最薄弱的环节。 如果您开发了世界上最好的工具,但实际的操作人员没有使用它,那么它就一文不值。 这就是Apple试图在iOS 12中使密码管理尽可能简单的原因。使密码重用审核变得更加容易的功能之一。 此功能监视iPhone所有者用于不同服务的密码。 当它在不同的网站上捕获到使用相同密码的某人时,它会标记重复的密码,提供更安全的密码,然后将其保存到iCloud钥匙串。 图片来源 在不同网站上使用一个密码的问题已得到充分记录。 安全专家多年来一直在努力解决这些问题,Apple竭尽所能提供帮助。 Auth0使用基于令牌的无密码身份验证提供安全身份验证,该功能具有蛮力保护系统。 iCloud:房间里的大象 乍一看,此iOS 12安全功能似乎不太安全。 为了使用此功能,Apple必须记录您的当前密码并能够对其进行爬网以进行匹配。 同时,Apple将所有内容存储在iCloud中。 这种担忧导致苹果公司使该系统尽可能地安全。 […]

安全地将密码密钥存储在iOS钥匙串中

在我的安全系列#1中,移动安全。 我已经介绍了移动安全性的基本知识。 现在,让我们弄脏双手。 让我简要介绍一下如何在iOS钥匙串系统中创建和存储加密密钥。 开始使用 加密密钥应存放在安全的地方。 密钥存储不当会导致数据泄露。 在iOS中,有两个框架可确保加密密钥的安全性。 本地认证框架 安全框架 在本文中,我将介绍两者并解释它们如何通过结合使用这两个框架来保护加密密钥。 本地认证框架 本地身份验证框架用于管理生物识别,例如TouchID和FaceID。 本地身份验证框架不允许应用访问系统内部的生物特征数据。 它就像在应用程序和硬件支持的安全区域之间进行通信的代理一样。 本地身份验证框架使应用程序需要用户存在才能访问敏感信息,例如加密密钥。 LAContext是本地身份验证框架中的类,用于桥接应用程序和保护安全区域。 LAContext()。evaluatePolicy( LAPolicy.deviceOwnerAuthenticationWithBiometrics, localizedReason:“原因”){(成功,错误)在 //处理返回 } 但是,以上方法不足以保护敏感数据。 它只是提示您评估用户的指纹或面部。 为了保护敏感数据,我们应该通过安全框架将敏感数据存储到钥匙串中。 安全框架 安全框架提供了一些方法来生成加密密钥,将系统密钥链中的密钥存储和检索为Keychain Item 。 要生成密钥对,我们可以调用以下方法: // 1.创建密钥访问控制 守护让accessControl = SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, [.privateKeyUsage,.biometryCurrentSet], 零) 其他{ fatalError(“无法设置访问控制”) } // 2.创建关键属性 let属性:[String:任何] = [ kSecClass作为字符串:kSecClassKey, kSecAttrKeyType作为字符串:kSecAttrKeyTypeRSA kSecAttrKeySizeInBits作为字符串:2048, kSecPrivateKeyAttrs作为字符串:[ kSecAttrIsPermanent as String:true, kSecAttrApplicationTag作为字符串:“ […]

用Javascript转储iOS应用程序(第一部分)

最后, pkd将通过launch_add_external_service启动XPC服务。 在越狱设备上,我可以注入pkd并修补此方法以返回YES 。 现在所有的App Extensions都可以运行并且可以注入: 插件org.wordpress.WordPressNotificationContentExtension,pid = 1280 插件org.wordpress.WordPressShare,pid = 1281 插件org.wordpress.WordPressNotificationServiceExtension,pid = 1282 插件org.wordpress.WordPressTodayWidget,pid = 1283 插件org.wordpress.WordPressDraftAction,pid = 1284

iOS:减少漏洞和攻击的安全措施

简介 :iOS平台在硬件和软件上均提供了高级安全功能。 它是由Apple设计的,以安全为核心。 但是,iOS用户担心为iOS应用程序提供的安全级别。 Micro Focus静态代码分析器可以跟踪这些应用程序的主要威胁,从而确定安全漏洞。 开发人员可以通过确定这些漏洞的根本原因,关联它们并确定结果的优先级来安全地进行编码。 这是一份快速指南,它分析了一些常见漏洞(称为问题陈述)并提供了克服威胁的快速解决方案。 1. 问题陈述 :该应用程序有遭受中间人(MITM)攻击和其他基于网络的攻击的风险。 说明 :在iOS 9中,Apple引入了应用程序传输安全性(ATS),此安全性功能默认情况下要求使用SSL / TLS对应用程序的所有连接进行加密。 它阻止任何应用程序发起的“未保护”连接,其中包括不使用具有最强TLS版本和密码套件的HTTPS的连接。 部分或全部禁用ATS可能会使应用程序遭受网络攻击或MitM攻击。 统计数据显示,目前应用商店中约有63%的应用使用NSAllowsArbitraryLoads键选择退出ATS,如下所示: NSAllowsArbitraryLoads =真 解决方案 :如果应用程序的ATS策略将NSAllowsArbitraryLoads设置为YES ,则通过添加所需的豁免和域来修改策略,以便能够将NSAllowsArbitraryLoads设置为NO 。 如果没有,您的应用程序迟早会被阻止。 使用NSURLSession和NSURLConnection时,默认情况下启用ATS。 诸如NSAllowsArbitraryLoads — NSAllowsArbitraryLoadsForMedia — NSAllowsArbitraryLoadsInWebContent — NSExceptionMinimumTLSVersion之类的某些键会触发附加的App Store审查并要求理由。 ATS实施用于安全网络连接的最佳做法,例如TLS 1.2和转发保密性。 将来会进行更新以反映Apple的网络最佳做法。 2. 问题陈述: TLS / SSL的弱版本可能具有以下一个或多个属性: –无法抵御MITM攻击 –用于认证和加密的密钥相同 –弱消息身份验证控制 –无法防止TCP连接关闭 这些可能使攻击者可以拦截,修改或篡改敏感数据。 说明 :传输层安全性(TLS)和安全套接字层(SSL)协议提供了一种保护机制,以确保在客户端和Web服务器之间传输的数据的真实性,机密性和完整性。 TLS和SSL都经过了修订,导致定期的版本更新。 每个新修订版都旨在解决以前版本中发现的安全漏洞。 使用不安全版本的TLS / SSL会削弱数据保护的强度,并且可能使攻击者能够泄露,窃取或修改敏感信息。 […]

iOS移动应用程序安全性-第一部分:iOS移动开发人员的最佳实践。

根据OWASP Top 10,每个ios开发人员都必须注意代码安全性,数据存储安全性,数据通信安全性等。 由于iOS移动应用程序不像其他移动平台(如Android)和任何混合移动开发(在其清单,清单,JavaScript注入等第一阶段非常开放)那样脆弱,因此iOS仍然存在其自身的问题。 确保正确地保护代码,逻辑,数据及其通信是每个组织/开发人员的责任,以防止任何入侵者篡改和理解代码。 为谨慎起见,在开发人员端,以下是初步威胁的一些清单,每个ios开发人员都应注意这些清单。 那些是: 1.屏幕录制和屏幕捕获 风险: 1.攻击者可以记录登录名/任何敏感屏幕,并捕获输入的用户名和密码。 2.在像应用程序一样的视频流中,任何付费视频内容都可以流式传输和记录。 这些风险将导致银行应用程序中的重大泄漏,如果执行屏幕截图或屏幕记录,则安全交易细节将受到损害。 OWASP:不安全身份验证 固定: 观察userDidTakeScreenshotNotification并使用UIScreen.isCaptured()限制用户继续进行操作。 示例代码: NotificationCenter.default.addObserver(forName:.UIApplicationUserDidTakeScreenshot,object:nil,queue:OperationQueue.main){ 打印(“截屏!!)} 要检查是否在ios 11及更高版本上正在发生屏幕录像: -(BOOL)isRecording { 对于(UIScreen.screens中的UIScreen *屏幕){ 如果([屏幕responseToSelector:@selector(isCaptured)]){ // iOS 11+具有isCaptured方法。 如果([screen performSelector:@selector(isCaptured)]){ 返回是; //屏幕捕获处于活动状态 }否则,如果(screen.mirroredScreen){ 返回是; //镜像处于活动状态 } }其他{ // 11.0以下的iOS版本 如果(screen.mirroredScreen) 返回是; } } 返回否; } 2. KeyChain数据保护 风险: 使用易受攻击的访问性选项添加到KeyChain的钥匙串项可能会暴露于JailBroken设备上的其他应用程序或具有物理访问权的攻击者。 通常,开发人员可以选择以下操作: kSecAttrAccessibleWhenUnlocked, kSecAttrAccessibleAfterFirstUnlock, kSecAttrAccessibleAlways, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, […]

如何使用iOS应用反向工程创建自己的Snapchat API客户端

抽象 动机 去年,我不得不在Snapchat的移动应用程序上使流程自动化,以便与脚本中的其他帐户进行交互。 由于Snapchat不提供任何公共API,因此我决定创建自己的客户端。 这个想法是创建一个非常可扩展的客户端以直接与其API进行交互,而不仅仅是半自动化地使用该应用程序。 为什么这么复杂? 在我之前,许多优秀的程序员为Snapchat创建了开源客户端(可以在Github上轻松找到源代码)。 问题在于Snapchat安全团队做得很好。 该API使用许多非常复杂的令牌来检查客户端请求的完整性,没有人找到一种方法来重现这些令牌后面的算法以模拟真实应用。 诀窍是什么? 对我们来说幸运的是,Snapchat是一个移动应用程序,并且由于您拥有客户端,因此您可以使用逆向工程技术来了解该应用程序的工作原理,并找到一种可以利用它的方法,从而发挥自己的优势。 经过数天的研究以了解该应用程序,我能够编写一个调整并将iOS设备用作身份验证服务。 以下是其工作方式的简化方案。 最终结果 使用这项技术和一些优化措施,我每天每台设备能够向Snapchat的API发送超过1000万个请求。 由于最终的架构是多设备支持就绪,因此规模几乎是无限的。 直接使用Snapchat应用作为身份验证提供程序的好处在于,几乎所有更新(甚至是主要版本)都不会破坏您的客户端,而且比尝试解密高安全性令牌要简单得多。 实际上,该客户在没有任何维护的情况下工作了一年很好,并且现在仍在工作。