V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
LeeReamond
V2EX  ›  程序员

有关邮箱地址伪造,有没有大佬来个科普

  •  
  •   LeeReamond · 260 天前 · 3280 次点击
    这是一个创建于 260 天前的主题,其中的信息可能已经有所发展或是发生改变。

    以前是就知道邮箱地址可以伪造,但是也没太在意,反正邮箱诈骗骗不到我头上。不过最近公司退税相关要有转账操作,收到邮件时候倒是确实感觉有点不太好分辨,我是确认了一下账户是公司对公账户才转过去的。毕竟前一段时间香港出了个被骗几千万的新闻好像就是用邮箱诈骗+AI 收集了对方公司领导的公开照片,用 AI 打视频会议,让分公司误以为总公司确实有转账,这就诈骗成功了。

    几个问题:

    1. 既然伪造邮件发新地址和修改 http 的 headers 一样简单,邮箱系统有没有类似 SSL 一样的确认合法性的工具?
    2. 有合法性确认工具但是好像可以绕过?
    3. 主流邮箱系统好像都有可以绕过的问题?隔壁贴看说 163 和 gmail 都有问题。
    4. 应对网络诈骗,如果我收到自称是 A 发来的邮件,我回给 A 邮件的信息是不是只有真正的 A 知道,历史上有没有案例是信息被转发截胡的?

    主要真收到要求转账邮件以后不知道真假,很多时候都依靠微信确认。微信确认有两个问题,一个是都用微信那还要邮件干什么,二是很多时候其他部门的不一定有微信,都是按规章给你来个邮件通知,双方也只有邮件交流。

    26 条回复    2024-03-07 23:39:18 +08:00
    sNullp
        1
    sNullp  
       260 天前
    liuxyon
        2
    liuxyon  
       260 天前
    使用 DKIM 验证. 我邮箱自带自动验证并且邮件标识出来.
    Love4Taylor
        3
    Love4Taylor  
       260 天前 via iPhone
    DKIM + DMARC
    liuxyon
        4
    liuxyon  
       260 天前
    如果公司需要安全邮件服务可以用我的试试.
    busier
        5
    busier  
       260 天前 via iPhone
    正确的方法是使用 S/MIME 或 PGP 对邮件进行数字签名或者加密。
    ZE3kr
        6
    ZE3kr  
       260 天前 via iPhone
    > 应对网络诈骗,如果我收到自称是 A 发来的邮件,我回给 A 邮件的信息是不是只有真正的 A 知道

    是的,只要你在回的时候仔细确认收件人。小心来件里可能有 CC/Reply-To ,这样可能会被第三者知道

    就跟电话一样,来电号码可以伪造,但再打回去确认就没问题了。
    busier
        7
    busier  
       260 天前 via iPhone
    1 、有,S/MIME 或 PGP 。前者需要向 CA 申请证书。后者可以自行生成公钥。主流邮件客户端 Outlook 或 ios 自带客户端支持 S/MIME ,像 thunderbird 之类开源客户端同时支持两者。
    2 、无法绕过。
    3 、无法绕过。
    4 、完全解决此问题。数字签名解决身份确认问题。S/MIME 和 PGP 还可以加密。端到端的加密可以防止网络服务商和邮件服务商监控邮件内容。
    LeeReamond
        8
    LeeReamond  
    OP
       259 天前
    @ZE3kr 邮件还遇到过,我用客户端查看收件人栏位,收件人地址不是我但是我收到了(同时我也不是抄送地址),不知道是怎么做到的

    @busier 不用 outlook 客户端。我使用 outlook 网页版是否有自动验证功能?
    leoleoasd
        9
    leoleoasd  
       259 天前
    > 收件人地址不是我但是我收到了(同时我也不是抄送地址),不知道是怎么做到的

    你在密送 (BCC) 里
    leoleoasd
        10
    leoleoasd  
       259 天前   ❤️ 1
    一般用于群发给一大堆人一样的邮件,但是不让收件人知道收件人列表
    这个时候 收件人一栏一般空着或者写发件人的邮箱
    cnt2ex
        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 信息。
    busier
        12
    busier  
       259 天前 via iPhone
    @LeeReamond 端到端的加密必须由客户端软件支持。好在这两者都是行业标准,pc 端和移动端都能良好支持。

    目前尚未发现 web 界面的支持客户端。

    话说这是终端到终端的加密,你要是将私钥放在 web 服务器上解密并以 web 方式展现邮件的话,那就失去端到端加密的意义了。
    busier
        13
    busier  
       259 天前 via iPhone
    @cnt2ex 厉害👍
    邮件服务商对规范遵循程度参差不齐,作为用户,邮件服务商也不可能依着用户改,况且大家还五花八门用着不同的邮件服务商。所以说这个思路不太可能有效解决问题。
    lisxour
        14
    lisxour  
       259 天前
    @busier #13 对于用户来说,给邮件签名是最好的处理方法。
    limetw
        15
    limetw  
       259 天前 via Android
    感觉 xray-core 的 reality 既然可以偷证书上网
    那么是不是可以在邮箱上面做文章
    没读过源码 忘了哪次意淫出来的 就没了后续
    Hormazed
        16
    Hormazed  
       259 天前 via iPhone   ❤️ 1
    一、邮件传递参数逻辑:
    发送 ip 地址:垃圾检测
    mail from:垃圾检测
    rcpt to:垃圾检测
    from:无检测〔伪造部分〕
    to:无检测〔伪造部分〕

    二、没有垃圾邮件网关,简单的方法:
    1.入向接收邮件,出向发送邮件,一台服务器拆分为两台服务器
    2.入向接收邮件系统对来自 from 地址是内部域名的进行拦截

    三、有垃圾邮件防护网关:
    1.配置策略指定参数的邮件,进行隔离拦截

    说明:
    此处接收邮件,发送邮件,指的是服务器和服务器通讯比如,A 服务器—->B 服务器,不是客户端的发送接收邮件
    kris0502
        17
    kris0502  
       259 天前
    邮件伪造可以主要看一下
    1 、spf 伪造,通过配置 dkim 防御
    2 、代发,发件人声称自己是 [email protected] ,也就是发件人地址,其实是 [email protected] ,这种情况通过网页端查看提示该邮件是否为代发
    3 、形似域名:比如你公司是 aabbcc.com ,攻击者购买一个 aabbbcc.com 自建邮箱给你发,注意仔细验证后缀名就可以防御
    4 、攻击者拿到你单位内部后发起的钓鱼攻击,如果涉及到密码、资金等重要信息的,打电话确认。。
    julyclyde
        18
    julyclyde  
       258 天前   ❤️ 1
    邮件系统的主要问题是多方合作,很难强制所有参与方全都上统一的高级别安全措施
    所以一般都会比较宽容“别家”没上安全措施
    NewYear
        19
    NewYear  
       251 天前   ❤️ 1
    @limetw

    首先,不要怀疑现代加密体系,不会有什么“偷证书”这种技术,当你有这种理解的时候,说明你对传输技术和 TLS 技术不够了解,再多看几个科普文吧。

    你说的这个技术,只是一种伪装的方法,但是伪装的影响目标是中间人,而不是传输的两端,传输两端是伪造不了的,如果能伪造就是天大的漏洞,早都铺天盖地的修补了。
    limetw
        20
    limetw  
       250 天前 via Android
    limetw
        21
    limetw  
       250 天前 via Android   ❤️ 1
    @NewYear 的的确确可以拿别人的证书来用,实现 CDN 的效果。而且可以任意修改其内容~

    当然了,DNS 是动不了的,这也就跑题了。因为我没去读 r 佬的源码,所以邮件是不是也可以拿来用。邮件伪造无非就是绕过收件人信箱的验证,或许不能,关键得先假设再动手。

    哦,我还没动手去验证...
    仅供参考
    NewYear
        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 网站了,这说明旧的加密传输技术已经被业界认定为不安全,淘汰了。

    唉,说这么多,其实邮件要验证来源是及其简单的事情,根本就不可能绕过,除非个别服务器的实现上面很蠢,这个属于软件自己的安全漏洞了,举个例子,邮件服务器有安全漏洞,别人把他黑了,塞一个邮件进去,用户侧是看不出毛病的,你不可能真的一封一封邮件点开看源码自己去走一遍验证流程。

    “的的确确可以拿别人的证书来用”,你看,你一边不确定,一边又很确定一个错误的结论,这在技术社区绝对是不好的习惯,如果你懂开发技术,罚你去仔细看看这个技术的原理,回来欢迎我们好好讨论,如果你是吃瓜群众,真的不要传播错误的结论,这会浪费很多技术人的时间(因为这瓜太刺激了,大家都愿意去研究一下,但可能得到的是失望),错误的技术结论传播的越广,浪费的时间越多……
    NewYear
        23
    NewYear  
       250 天前   ❤️ 1
    @limetw

    “邮件伪造无非就是绕过收件人信箱的验证,或许不能,关键得先假设再动手。”

    我真的不想吐槽,对于一个开发者,验证来源是有多难的事情,整个互联网,不说远了,就说各银行的 API 接口,都是用很简单的技术验证的来源,至少二十年前就这样干了,即便传输过程不加密,你都伪造不了,你老人家一句“无非就是绕过 XXX 信箱的验证”,这要怎么绕过呢,你要假设也要有思路啊大哥,要不然别人哭笑不得呢。咱要不就绕过一下银行的简单验证机制嘛,直接走向人生巅峰。

    不过说真的,早期的时候,真的是有“伪造邮件地址”,不过都是利用邮件协议本身的特性,现在这些问题都有妥善解决办法啦。
    limetw
        24
    limetw  
       250 天前 via Android
    @NewYear

    我的假设只是一个偶然的意淫,仅此而已。或许有很多地方欠考虑(无法实现、很难实现),但我的第一条应该不难理解,你可以认为我是小白,本身就没有技术性讨论。

    我给出的观点,的的确确是一个伪造方法。它跟传输加密无关,我没质疑过。reality 本身也不是修改真实服务器的数据,你进行邮件攻击也和要伪造的邮局(域名)无关对吧?那么,就不存在篡改加密内容。

    “邮件伪造无非就是绕过收件人信箱的验证”,现在知名的邮箱系统用啥验证方案其实都无所谓。历史上发生过很多次,伪造邮件和真实的几乎没明显区别(对普通用户而言,专业用户也不一定每封邮件都严格证伪吧),无论是什么伪造方式,达到目的就行。本质上就是欺骗了收件人的邮箱系统,绕过了它的真实性验证。

    这个世界上有一个叫 0day 的东西。它可以是极少数人掌握,也可以是自己一个人掌握。虽然现代的加密十分可靠,但你不能说它绝对安全,无法破解(暴力破解也算破解)。还有,银行系统在我印象里是最脆弱的,都不如腾讯、阿里这样的公司安全。QQ 邮箱应该是国内最棒的了,伪造成功的案例也很多啊!

    回到臆想本身。reality 偷证书给你,你利用它实现了无证书白名单翻墙。中间人,也就是那个叫 gfw 的坏家伙,它用各种方法来审查你,gfw 最后认为你提供的证书是真实的,你的数据无异常。当然,它没办法审查加密数据,只能根据特征判断。

    既然,reality 可以“偷证书”,不要怀疑,它确实偷了,哪怕只是转发握手包。在你自己的服务器上,也可以用别人的域名架设 web 服务。然后内容你是可以修改的,如果你做不到那是你的问题,我没必要解释更多(域名是别人,内容是你自己,你不需要修改真实服务器上的数据!)。这样,我们有了一个以假乱真的 web 服务对吧?只要你 hosts 充当公网 DNS ,那么完全可以说我的站点和真实服务器没有差别。你、我、他访问这个站点,用别人的域名都是一样的。

    关于邮件伪造,我说了这只是一个臆想。能不能做到我不知道。因为我根本没研究过邮件系统,但是很久以前看过几篇关于伪造的文章。自己也确实成功发起了几次邮局欺骗,可能当时没 TLS 比较容易?

    所以我的这个意淫,没有说伪造邮局的难度,没有技术讨论的意愿,没有去验证任何东西。就没必要跟我普及那么多知识了。当然我也可以直接回一句,老子手里有 0day ,既能装逼又优雅,而且没后续。

    但我写这么多干嘛呢,因为你也给我写了很多。我尊重你。第一条我就写了是意淫~ 而且我的意淫还是有根据的。有想法是好事,你不能扼杀。

    但是你理解错了我的这个想法。我得指出来,它和我懂不懂没关系。因为你指出来的加密可靠性什么的,在我的想法里是无需考虑的。

    最后。不建议你再拿出什么来指点我。还是那句话,第一条我就明确了,这只是一个意淫。我不懂邮局系统,压根没兴趣。所以这套逻辑行不行得通我自己都不清楚!!!但是很多邮件伪造的漏洞咱又不是不知道,我认为不难。也别跟我抬杠,v2ex 如果能销号早销号了~ 你认为你对就对,你怎么认为就怎么认为。我就是来水贴的,恩。反正逼逼那么多,也不如去 exploit 翻一翻漏洞能解释清楚。
    limetw
        25
    limetw  
       250 天前 via Android
    @NewYear

    https://support.google.com/a/answer/10583557?sjid=18380727723177315276-NC&hl=en

    首先,我承认我的假设行不通。简单地了解了一下现在的身份验证措施,其实 11 楼也写了,我没看着。而且,SPF 和 DMARC 我自己的域名也早就启用了。

    我一直以为,这个验证是有效的。但没有此记录的域名就有被伪造的风险。而且,肯定有其他办法攻击,这也是我举一反三的思考方式。

    我其实忽略了最基本的。那就是发件方可以声明自己是任何地址,收件方更是简单粗暴。直接请求 DNS 去做验证。那么和“偷证书”完全无关。故,我的假设无效。

    但是,你也不要认为你就是对的、你并没有帮助我,更多的是误导。(你一个帖子跟我讲 HTTPS 加密,和邮件无关,和 reality 无关,咱是没看懂你想表达什么)

    那么,看来我说“邮件伪造无非就是绕过收件人信箱的验证”是正确的,也是错误的。这句话可以强行洗,但没必要。

    我一开始就是来水贴的,就没过脑子。而且这东西并不是很感兴趣,只是随便一写的想法。是的,连现在的邮件验证逻辑我都不知道,就胡思乱想。

    感谢我的胡思乱想,所以我举一反三,知错改错。我值得骄傲!这个假设行不通,我还有无数个假设,然后去证伪,最后去验证。反反复复,最终解决问题。

    到此为止吧。
    limetw
        26
    limetw  
       250 天前 via Android
    @NewYear 存不存在偷证书,你可以和 rprx 对线。
    收件方的验证就是去验证 DNS ,reality 解决不了这个问题。

    你有没有发现,其实就这么简单,我不懂现在邮件的验证逻辑,因为我没兴趣,我对邮箱系统的印象还停留在 0 几年。你从偷证书开始,再到跟我科普什么 HTTPS ,完全跑题。

    其实如果不去了解,按照我的理解还是很符合逻辑的。甚至每封邮件都是用证书加密出来的话,我都想到了解决方案。

    谁也不是天生的无所不知。说多无益,就那么简单的东西。再见
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1050 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 19:52 · PVG 03:52 · LAX 11:52 · JFK 14:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.