以前是就知道邮箱地址可以伪造,但是也没太在意,反正邮箱诈骗骗不到我头上。不过最近公司退税相关要有转账操作,收到邮件时候倒是确实感觉有点不太好分辨,我是确认了一下账户是公司对公账户才转过去的。毕竟前一段时间香港出了个被骗几千万的新闻好像就是用邮箱诈骗+AI 收集了对方公司领导的公开照片,用 AI 打视频会议,让分公司误以为总公司确实有转账,这就诈骗成功了。
几个问题:
主要真收到要求转账邮件以后不知道真假,很多时候都依靠微信确认。微信确认有两个问题,一个是都用微信那还要邮件干什么,二是很多时候其他部门的不一定有微信,都是按规章给你来个邮件通知,双方也只有邮件交流。
1
sNullp 260 天前
|
2
liuxyon 260 天前
使用 DKIM 验证. 我邮箱自带自动验证并且邮件标识出来.
|
3
Love4Taylor 260 天前 via iPhone
DKIM + DMARC
|
4
liuxyon 260 天前
如果公司需要安全邮件服务可以用我的试试.
|
5
busier 260 天前 via iPhone
正确的方法是使用 S/MIME 或 PGP 对邮件进行数字签名或者加密。
|
6
ZE3kr 260 天前 via iPhone
> 应对网络诈骗,如果我收到自称是 A 发来的邮件,我回给 A 邮件的信息是不是只有真正的 A 知道
是的,只要你在回的时候仔细确认收件人。小心来件里可能有 CC/Reply-To ,这样可能会被第三者知道 就跟电话一样,来电号码可以伪造,但再打回去确认就没问题了。 |
7
busier 260 天前 via iPhone
1 、有,S/MIME 或 PGP 。前者需要向 CA 申请证书。后者可以自行生成公钥。主流邮件客户端 Outlook 或 ios 自带客户端支持 S/MIME ,像 thunderbird 之类开源客户端同时支持两者。
2 、无法绕过。 3 、无法绕过。 4 、完全解决此问题。数字签名解决身份确认问题。S/MIME 和 PGP 还可以加密。端到端的加密可以防止网络服务商和邮件服务商监控邮件内容。 |
8
LeeReamond OP |
9
leoleoasd 259 天前
> 收件人地址不是我但是我收到了(同时我也不是抄送地址),不知道是怎么做到的
你在密送 (BCC) 里 |
10
leoleoasd 259 天前 1
一般用于群发给一大堆人一样的邮件,但是不让收件人知道收件人列表
这个时候 收件人一栏一般空着或者写发件人的邮箱 |
11
cnt2ex 259 天前 2
了解一下 SPF/DKIM/DMARC 这几个机制是怎么工作的,然后手动检查邮件里一些重要的 header ,比如 Return-Path 、DKIM-Signature 、Authentication-Results 。如果这几个 Header 都没有,多半就是伪造的。
除了一些特殊情况,Return-Path 是表示邮件是从哪个邮件服务器发送过来的,这个地址有可能和 From 不是同一个地址。RFC 5321 要求 Return-Path 是最后一跳邮件服务器加上的,也就是你的邮件服务提供商。 一般来说,你的邮件服务提供商会通过 SPF 机制验证 Envelope From ,然后把 Envelope From 的地址填到 Return-Path 里。要注意的是,Envelope From ( SMTP 协议通信时使用的地址)和邮件里的 From header (邮件里的 header ,客户端显示的就是这个地址)是两个东西,因此一封信即使通过 SPF 验证,仅仅能保证 Return-Path 写的是真的,而不能保证 From 是真的。 DKIM-Signature 是这封邮件的签名,里面通常带有哪个域名给这封邮件签过名,来保证邮件的完整性。但也要注意的是,签名域名和 From 也可以是不同的。比如 DKIM-Signature 里签名的域名可以是 outlook.com ,而 From 的地址却是 [email protected] 这种毫不相关的地址,这种情况下,DKIM-Signature 只能保证邮件是由 outlook.com 这个域名签名过的,不能保证 From 就是真的。 SPF/DKIM 和 DMARC 结合一起使用,才能保证 From 的真实性。DMARC 有 Alignment 要求,要求 SPF 和 DKIM 里的域名和 From 对齐。 Authentication-Results 则包含了以上几种机制 spf 、dkim 、dmarc 的验证结果。 以上只是理论上,但实际上,我发现很多邮件服务提供商,都缺少相关的东西。比如 qq 邮件收到的邮件,偶尔就会少 Return-Path 这种重要的 header ,很多学校使用的 Coremail 邮件系统则是没有一封邮件会有 Return-Path 信息。 |
12
busier 259 天前 via iPhone
@LeeReamond 端到端的加密必须由客户端软件支持。好在这两者都是行业标准,pc 端和移动端都能良好支持。
目前尚未发现 web 界面的支持客户端。 话说这是终端到终端的加密,你要是将私钥放在 web 服务器上解密并以 web 方式展现邮件的话,那就失去端到端加密的意义了。 |
13
busier 259 天前 via iPhone
@cnt2ex 厉害👍
邮件服务商对规范遵循程度参差不齐,作为用户,邮件服务商也不可能依着用户改,况且大家还五花八门用着不同的邮件服务商。所以说这个思路不太可能有效解决问题。 |
15
limetw 259 天前 via Android
感觉 xray-core 的 reality 既然可以偷证书上网
那么是不是可以在邮箱上面做文章 没读过源码 忘了哪次意淫出来的 就没了后续 |
16
Hormazed 259 天前 via iPhone 1
一、邮件传递参数逻辑:
发送 ip 地址:垃圾检测 mail from:垃圾检测 rcpt to:垃圾检测 from:无检测〔伪造部分〕 to:无检测〔伪造部分〕 二、没有垃圾邮件网关,简单的方法: 1.入向接收邮件,出向发送邮件,一台服务器拆分为两台服务器 2.入向接收邮件系统对来自 from 地址是内部域名的进行拦截 三、有垃圾邮件防护网关: 1.配置策略指定参数的邮件,进行隔离拦截 说明: 此处接收邮件,发送邮件,指的是服务器和服务器通讯比如,A 服务器—->B 服务器,不是客户端的发送接收邮件 |
17
kris0502 259 天前
邮件伪造可以主要看一下
1 、spf 伪造,通过配置 dkim 防御 2 、代发,发件人声称自己是 [email protected] ,也就是发件人地址,其实是 [email protected] ,这种情况通过网页端查看提示该邮件是否为代发 3 、形似域名:比如你公司是 aabbcc.com ,攻击者购买一个 aabbbcc.com 自建邮箱给你发,注意仔细验证后缀名就可以防御 4 、攻击者拿到你单位内部后发起的钓鱼攻击,如果涉及到密码、资金等重要信息的,打电话确认。。 |
18
julyclyde 258 天前 1
邮件系统的主要问题是多方合作,很难强制所有参与方全都上统一的高级别安全措施
所以一般都会比较宽容“别家”没上安全措施 |
19
NewYear 251 天前 1
@limetw
首先,不要怀疑现代加密体系,不会有什么“偷证书”这种技术,当你有这种理解的时候,说明你对传输技术和 TLS 技术不够了解,再多看几个科普文吧。 你说的这个技术,只是一种伪装的方法,但是伪装的影响目标是中间人,而不是传输的两端,传输两端是伪造不了的,如果能伪造就是天大的漏洞,早都铺天盖地的修补了。 |
20
limetw 250 天前 via Android
|
21
limetw 250 天前 via Android 1
@NewYear 的的确确可以拿别人的证书来用,实现 CDN 的效果。而且可以任意修改其内容~
当然了,DNS 是动不了的,这也就跑题了。因为我没去读 r 佬的源码,所以邮件是不是也可以拿来用。邮件伪造无非就是绕过收件人信箱的验证,或许不能,关键得先假设再动手。 哦,我还没动手去验证... 仅供参考 |
22
NewYear 250 天前 1
@limetw
大哥,首先,你要有一定的知识储备(没有贬低的意思),否则,你的猜测没有价值,甚至我都没法和你解释你的问题点在哪,因为太费劲了。 HTTPS 的加密,目的是防止中间人窃听、篡改、重放,也就是说,中间人( A 端和 B 端中间的一切路由、交换设备)是可以得到传输过程中的所有数据,但都是被加密的。 换言之,就是 A 和 B 通讯的时候,确保真的是对方发过来的数据。 现代加密传输技术,连银行都不例外依赖这些技术,包括某付宝、某信支付。 解释这个的意思是啥呢,如果可以伪造,那么绝对是惊天大瓜(之前也有爆瓜,每一个都被历史记载),而且会有一系列攻击手段,并且造成一系列的损失,而且信任体系不说崩塌起码得震三震,然而业界震动了吗?并没有吧,这个叫透过现象看本质,咱不需要懂底层技术,只需要观察业界动态,就能知道这玩意是否可靠。 然后说原理,你指出的这个技术,从网络数据看,是 A 要连接 B ,但是用户侧指定了 C 的 IP 地址,所以 A 和 C 通讯经过了 B ,B 在 A 、C 收发数据时且在握手阶段时,只转达,不改变,所以此时 B 承担了交换机/路由器的作用,握手阶段只有部分是明文的,所以 B 也看不懂到底收发的细节是啥,但是,根据 TLS 协议,握手包的数量是确定的,例如是 5 个包,这 5 个包 B 原封不动的转发。 因此,其他的中间设备,即便对这 5 个包进行判断,也没有任何意义,因为它本质上就是正常的包。 5 个包之后,两端已经过握手阶段,后续就是互相发送加密数据了,这玩意没有任何明文信息,全是加密包,所有路由、交换设施都看不懂里面的任何数据,此时 B 不再将 A 的数据包转给 C ,而是与 A 通过自有协议进行握手或传输,但,所有数据加密,并对握手数据包的大小、随机率进行伪装,确保中间的路由、交换设施没有能力判断后续数据包特征。 这个技术的核心点在于“欺骗中间人和中间的一切设备”,在 A 和 B 之间,谁都没有欺骗谁。 回到这个主题,通讯方变成了邮件收发客户端和邮件服务器,你要做的是什么,本质上就是客户端要欺骗服务器,如何欺骗呢?不是大哥你说一句“邮件伪造无非就是绕过收件人信箱的验证”就搞定了,上面大家提到的这些技术,就是为了防止绕过,如果当今真有绕过的技术,那大家早就开始修补了,至少开源社区会震动并大范围通告。 其实我说了这么多,也不确定你是否能看懂,因为如果你不懂编程和网络传输技术的话,其实解释了也白解释,因为你只需要继续“怀疑”就可以了,如果不是我专门看过这个技术的文档和一些思考,还真就被你给忽悠了,可能这会都兴奋得不行。 但其实也还好,因为通过搜索引擎能很快的确定你说的猜测不存在,这种属于惊天漏洞,很容易确认是否存在甚至不需要懂技术,而且对于懂技术的开发者,对于自家的程序修复起来都不难,现在加密、传输技术已经非常成熟,“成熟”的意义是,经过不断的技术迭代,不会犯低级错误,同时因为开源思想的存在,后人不断完善机制。 其实这些东西都能侧面观察出来,比如 Windows XP 的 IE8 浏览器,虽然也能使用 HTTPS 技术,但是已经打不开大部分 HTTPS 网站了,这说明旧的加密传输技术已经被业界认定为不安全,淘汰了。 唉,说这么多,其实邮件要验证来源是及其简单的事情,根本就不可能绕过,除非个别服务器的实现上面很蠢,这个属于软件自己的安全漏洞了,举个例子,邮件服务器有安全漏洞,别人把他黑了,塞一个邮件进去,用户侧是看不出毛病的,你不可能真的一封一封邮件点开看源码自己去走一遍验证流程。 “的的确确可以拿别人的证书来用”,你看,你一边不确定,一边又很确定一个错误的结论,这在技术社区绝对是不好的习惯,如果你懂开发技术,罚你去仔细看看这个技术的原理,回来欢迎我们好好讨论,如果你是吃瓜群众,真的不要传播错误的结论,这会浪费很多技术人的时间(因为这瓜太刺激了,大家都愿意去研究一下,但可能得到的是失望),错误的技术结论传播的越广,浪费的时间越多…… |
23
NewYear 250 天前 1
@limetw
“邮件伪造无非就是绕过收件人信箱的验证,或许不能,关键得先假设再动手。” 我真的不想吐槽,对于一个开发者,验证来源是有多难的事情,整个互联网,不说远了,就说各银行的 API 接口,都是用很简单的技术验证的来源,至少二十年前就这样干了,即便传输过程不加密,你都伪造不了,你老人家一句“无非就是绕过 XXX 信箱的验证”,这要怎么绕过呢,你要假设也要有思路啊大哥,要不然别人哭笑不得呢。咱要不就绕过一下银行的简单验证机制嘛,直接走向人生巅峰。 不过说真的,早期的时候,真的是有“伪造邮件地址”,不过都是利用邮件协议本身的特性,现在这些问题都有妥善解决办法啦。 |
24
limetw 250 天前 via Android
@NewYear
我的假设只是一个偶然的意淫,仅此而已。或许有很多地方欠考虑(无法实现、很难实现),但我的第一条应该不难理解,你可以认为我是小白,本身就没有技术性讨论。 我给出的观点,的的确确是一个伪造方法。它跟传输加密无关,我没质疑过。reality 本身也不是修改真实服务器的数据,你进行邮件攻击也和要伪造的邮局(域名)无关对吧?那么,就不存在篡改加密内容。 “邮件伪造无非就是绕过收件人信箱的验证”,现在知名的邮箱系统用啥验证方案其实都无所谓。历史上发生过很多次,伪造邮件和真实的几乎没明显区别(对普通用户而言,专业用户也不一定每封邮件都严格证伪吧),无论是什么伪造方式,达到目的就行。本质上就是欺骗了收件人的邮箱系统,绕过了它的真实性验证。 这个世界上有一个叫 0day 的东西。它可以是极少数人掌握,也可以是自己一个人掌握。虽然现代的加密十分可靠,但你不能说它绝对安全,无法破解(暴力破解也算破解)。还有,银行系统在我印象里是最脆弱的,都不如腾讯、阿里这样的公司安全。QQ 邮箱应该是国内最棒的了,伪造成功的案例也很多啊! 回到臆想本身。reality 偷证书给你,你利用它实现了无证书白名单翻墙。中间人,也就是那个叫 gfw 的坏家伙,它用各种方法来审查你,gfw 最后认为你提供的证书是真实的,你的数据无异常。当然,它没办法审查加密数据,只能根据特征判断。 既然,reality 可以“偷证书”,不要怀疑,它确实偷了,哪怕只是转发握手包。在你自己的服务器上,也可以用别人的域名架设 web 服务。然后内容你是可以修改的,如果你做不到那是你的问题,我没必要解释更多(域名是别人,内容是你自己,你不需要修改真实服务器上的数据!)。这样,我们有了一个以假乱真的 web 服务对吧?只要你 hosts 充当公网 DNS ,那么完全可以说我的站点和真实服务器没有差别。你、我、他访问这个站点,用别人的域名都是一样的。 关于邮件伪造,我说了这只是一个臆想。能不能做到我不知道。因为我根本没研究过邮件系统,但是很久以前看过几篇关于伪造的文章。自己也确实成功发起了几次邮局欺骗,可能当时没 TLS 比较容易? 所以我的这个意淫,没有说伪造邮局的难度,没有技术讨论的意愿,没有去验证任何东西。就没必要跟我普及那么多知识了。当然我也可以直接回一句,老子手里有 0day ,既能装逼又优雅,而且没后续。 但我写这么多干嘛呢,因为你也给我写了很多。我尊重你。第一条我就写了是意淫~ 而且我的意淫还是有根据的。有想法是好事,你不能扼杀。 但是你理解错了我的这个想法。我得指出来,它和我懂不懂没关系。因为你指出来的加密可靠性什么的,在我的想法里是无需考虑的。 最后。不建议你再拿出什么来指点我。还是那句话,第一条我就明确了,这只是一个意淫。我不懂邮局系统,压根没兴趣。所以这套逻辑行不行得通我自己都不清楚!!!但是很多邮件伪造的漏洞咱又不是不知道,我认为不难。也别跟我抬杠,v2ex 如果能销号早销号了~ 你认为你对就对,你怎么认为就怎么认为。我就是来水贴的,恩。反正逼逼那么多,也不如去 exploit 翻一翻漏洞能解释清楚。 |
25
limetw 250 天前 via Android
@NewYear
https://support.google.com/a/answer/10583557?sjid=18380727723177315276-NC&hl=en 首先,我承认我的假设行不通。简单地了解了一下现在的身份验证措施,其实 11 楼也写了,我没看着。而且,SPF 和 DMARC 我自己的域名也早就启用了。 我一直以为,这个验证是有效的。但没有此记录的域名就有被伪造的风险。而且,肯定有其他办法攻击,这也是我举一反三的思考方式。 我其实忽略了最基本的。那就是发件方可以声明自己是任何地址,收件方更是简单粗暴。直接请求 DNS 去做验证。那么和“偷证书”完全无关。故,我的假设无效。 但是,你也不要认为你就是对的、你并没有帮助我,更多的是误导。(你一个帖子跟我讲 HTTPS 加密,和邮件无关,和 reality 无关,咱是没看懂你想表达什么) 那么,看来我说“邮件伪造无非就是绕过收件人信箱的验证”是正确的,也是错误的。这句话可以强行洗,但没必要。 我一开始就是来水贴的,就没过脑子。而且这东西并不是很感兴趣,只是随便一写的想法。是的,连现在的邮件验证逻辑我都不知道,就胡思乱想。 感谢我的胡思乱想,所以我举一反三,知错改错。我值得骄傲!这个假设行不通,我还有无数个假设,然后去证伪,最后去验证。反反复复,最终解决问题。 到此为止吧。 |