it-swarm-vi.com

Làm thế nào để Paypal giả mạo email dễ dàng để nói nó đến từ người khác?

Khi tôi nhận được một khoản thanh toán trong Paypal, nó sẽ gửi cho tôi một email về nó (hình dưới đây). Vấn đề là email được hiển thị đến từ địa chỉ email của người gửi tiền chứ không phải từ chính Paypal, mặc dù người gửi thực sự là Paypal.

Email from Paypal

Đây là văn bản xuất hiện khi tôi chọn "hiển thị bản gốc" trong Gmail:

From: "[email protected]" <[email protected]>  
Sender: [email protected]

Vì vậy, bạn có thể thấy rằng người gửi thực sự là Paypal.

Nếu Paypal có thể giả mạo người gửi email một cách dễ dàng và Gmail không nhận ra nó, điều đó có nghĩa là bất kỳ ai cũng có thể giả mạo địa chỉ người gửi email và Gmail sẽ không nhận ra?

Khi tôi tự gửi email đến Gmail bằng telnet, email sẽ kèm theo cảnh báo:

Tin nhắn này có thể chưa được gửi bởi: [email protected]

Đây có phải là một vấn đề bảo mật? Bởi vì nếu tôi quen với thực tế là các email thanh toán trong Paypal dường như đến từ email của người gửi tiền chứ không phải từ Paypal, thì người gửi chỉ có thể tự giả mạo thanh toán bằng cách gửi một tin nhắn như thế từ email của mình và tôi có thể nghĩ rằng đây là khoản thanh toán thực sự.

Đây có phải là một cái gì đó cụ thể đối với Paypal hoặc bất kỳ ai cũng có thể đánh lừa Gmail như vậy không? Và nếu ai cũng có thể, phương thức chính xác mà Paypal đang sử dụng để đánh lừa Gmail là gì?

147
Sunny88

Dưới đây là một tác phẩm kịch tính về cách thức giao tiếp, khi nhận được thư ở bất cứ đâu.


Bối cảnh: một máy chủ email, một mình trong một vịnh, một nơi nào đó ở Moscow. Máy chủ chỉ ngồi yên ở đó, với biểu hiện mong đợi.

Máy chủ :
[.__.] Ah, lâu là những ngày tôi phục vụ,
[.__.] Điều đó sẽ được chi tiêu trong sự cô độc,
[.__.] 'Ere đến từ những chiếc nhẫn bên ngoài
[.__.] The Swift người mang thông tin bên ngoài.

Một kết nối được mở.

Máy chủ :
[.__.] Một khách hàng đến! Nhận một thư
[.__.] Quyền giám hộ của tôi sẽ được giao phó
[.__.] Tôi có thể truyền đạt như một chiến mã công bằng nhất
[.__.] Và để người nhận mang đến câu chuyện đầy đủ.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Chào mừng đến với vương quốc của tôi, giang hồ ròng,
[.__.] Tìm hiểu rằng tôi là một máy chủ thư mạnh mẽ.
[.__.] Bạn sẽ được giải quyết như thế nào trong ngày này
[.__.] Sẽ tăng nhu cầu, để đoán tên của bạn?

Khách hàng :

HELO whitehouse.gov

Kính chào quý vị, người giữ mạng,
[.__.] Biết rằng tôi sinh ra từ tòa nhà nhạt.

Máy chủ :

250 mailserver.kremlin.ru

Địa chỉ IP đến sẽ phân giải thông qua DNS thành "Khó chịu".

Đặc phái viên, tôi là của bạn chỉ huy,
[.__.] Mặc dù giọng nói của bạn đến từ vùng đồng bằng nóng bỏng
[.__.] Của vùng đất bên kia dãy núi châu Á,
[.__.] Tôi sẽ tuân thủ nhu cầu mỏng manh nhất của bạn.

Khách hàng :

MAIL FROM: [email protected]
RCPT TO: [email protected]
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

Đây là tin nhắn của tôi, để bạn gửi,
[.__.] Và trung thành truyền trên ether;
[.__.] Hãy nhớ địa chỉ và tên người gửi
[.__.] Điều đó sẽ được hiển thị ở đầu kia.

Máy chủ :

250 Ok

Vì vậy, nó đã được viết, vì vậy nó sẽ được thực hiện.
[.__.] Tin nhắn được gửi đi và đến Nga.

Máy chủ sẽ gửi email, chỉ thêm tiêu đề "Đã nhận:" để đánh dấu tên mà khách hàng đưa ra trong lệnh đầu tiên. Rồi chiến tranh thế giới thứ ba bắt đầu. Sự kết thúc.


Bình luận : không có bảo mật nào trong email. Tất cả tên người gửi và người nhận là chỉ định và không có cách nào đáng tin cậy để phát hiện giả mạo (nếu không tôi sẽ có ít thư rác hơn).

390
Tom Leek

Bất kỳ địa chỉ email 'từ' nào cũng có thể bị giả mạo, vì bạn có thể thay đổi bất kỳ dữ liệu gửi nào bạn muốn. Bạn không cần phải đánh lừa gmail. Khi nói rằng, gmail có thể phát hiện ra các vấn đề rõ ràng khi một email được đánh dấu là được gửi từ một tổ chức đến với họ từ một tên miền khác.

Bạn cũng không thể chắc chắn email gốc là từ Paypal trong ví dụ của bạn - bit người gửi đó cũng có thể bị giả mạo!

Nếu bạn muốn một số loại xác thực để ngăn chặn điều này xảy ra, bạn cần một cách ký hoặc mã hóa email hoặc kiểm tra ngoài băng để xác nhận email đến từ bạn của bạn (như bạn đã đề cập trong nhận xét của mình)

Nghiêm túc - không tin tưởng bất kỳ email. Không nhấp vào bất kỳ liên kết nào trong email. Đặc biệt là từ các mục tiêu giá trị cao như Paypal. Thay vào đó, bạn nên đăng nhập như bình thường và kiểm tra xem họ đã gửi cho bạn thứ gì chưa.

52
Rory Alsop

Như những người khác đã đề cập, bất kỳ ai đều có thể giả mạo bất kỳ địa chỉ email , bao gồm cả Trường "Người gửi" - không có lý do kỹ thuật nào Paypal thậm chí phải đưa email của chính họ vào trường người gửi, họ chỉ làm điều đó vì họ là một công ty trung thực. Đừng hy vọng những kẻ gửi thư rác sẽ tốt đẹp như vậy.

Tuy nhiên, bên cạnh đó, tôi muốn đề cập rằng gmail có hỗ trợ cho DKIM , cho phép bạn xác minh email Paypal thực sự đến từ Paypal.

Để bật nó: Nhấp vào thiết bị ở phía trên bên phải -> cài đặt thư -> phòng thí nghiệm -> Bật "Biểu tượng xác thực cho người gửi đã xác minh"

(gmail labs image)

Các email Paypal đã ký sẽ hiển thị với một biểu tượng khóa nhỏ bên cạnh chúng:

(example image)

43

Nó rất giống như thư bưu chính. Bất cứ ai cũng có thể gửi cho bạn một lá thư với tiêu đề thư trông giống như chi nhánh địa phương của ngân hàng của bạn. Có một số điều bạn có thể làm để bắt những kẻ mạo danh như thế này - bạn có thể đảm bảo dấu bưu điện là từ đúng thành phố. Nếu ngân hàng của bạn luôn sử dụng thư hàng loạt thay vì tem riêng lẻ, bạn có thể nhận thấy điều đó, v.v. Nhưng bạn có thể không bao giờ bận tâm kiểm tra những điều này, và ngay cả khi bạn đã làm, điều đó sẽ không đủ để xác minh rằng thư đến từ ngân hàng của bạn.

Sự khác biệt chính giữa thư bưu chính và email, là với email, một sự giả mạo thực tế hơn - nó có thể được thiết kế một lần, và sau đó lặp đi lặp lại với chi phí gần như bằng không.

Điều này có nghĩa là tất cả các giả mạo và biện pháp đối phó ở quy mô lớn hơn, và (trừ khi bạn giống như tôi1) một số thư giả sẽ đến hộp thư đến của bạn và bạn phải lọc thủ công.

Tóm lại, giống như bạn sẽ không gọi một số điện thoại trong thư để "xác minh thông tin tài khoản của bạn" (như SSN và Thẻ tín dụng của bạn), bạn cũng không nên nhấp vào liên kết trong email và mong đợi màn hình đăng nhập hoặc bất kỳ hình thức nào để gửi an toàn thông tin cá nhân đến ngân hàng của bạn. Nếu bạn làm như vậy, bạn có thể thấy mình gửi thông tin đăng nhập của bạn cho một kẻ mạo danh, và không bao giờ nhận ra nó.


1. Tôi đã loại bỏ tất cả thư rác của tôi. Tôi có tên miền riêng của tôi. Tôi cung cấp cho mọi liên hệ địa chỉ email của riêng họ và tất cả đều nằm trong hộp thư đến của tôi. Bằng cách này, nếu Bob bị nhiễm vi-rút trên máy tính của anh ấy và tôi bắt đầu nhận được một số thư rác cấp thấp đó, thì tôi có thể bảo Bob thay đổi mật khẩu email của anh ấy và bắt đầu sử dụng địa chỉ email mới cho email của anh ấy cho tôi. Địa chỉ email mới sẽ không nhận được bất kỳ thư rác nào trên đó và tôi có thể xóa địa chỉ cũ, vì chỉ Bob mới sử dụng nó.

Tôi không phải nói với ngân hàng của mình và những người bạn khác, nhà cung cấp, đồng nghiệp của tôi, rằng địa chỉ email của tôi đã thay đổi, vì mỗi người có địa chỉ riêng. (Tôi thậm chí không phải cập nhật StackExchange và Gravater.) Điều này tốt cho tôi (không có thư rác), tốt cho Bob (anh ấy biết mình có "virus hoặc thứ gì đó" - đôi khi tôi có thể trực tiếp, nhưng người ta phải cẩn thận để không sai sau đó), tốt cho những người bạn khác của tôi (tôi không bao giờ phàn nàn về số lượng email tôi nhận được trong 24 giờ qua và giải thích lý do tại sao tôi không quay lại với họ)

25
Bryan Field

Tôi nghĩ rằng bạn đã bỏ qua một chi tiết nhỏ đã được đề cập trong bộ phim truyền hình ở trên, điều đó thực sự rất dễ kiểm tra:

Email giả mạo không đến từ một địa chỉ email hợp pháp thuộc về miền mà họ tuyên bố là có nguồn gốc. Một phần của giao thức SMTP bao gồm một bộ tiêu đề thư đầy đủ that luôn luôn bao gồm đường dẫn trả về của tin nhắn, đó là địa chỉ email mà = thực sự đã gửi tin nhắn. Không chỉ vậy, mà các địa chỉ IP cũng có một khu vực địa lý rõ ràng mà chúng được gán. Vì vậy, bạn có thể nắm bắt những khác biệt này với một chút đào.

Lấy ví dụ, nói kịch tính.

Nó đề cập rằng email đến từ Whitehouse.gov. Đây là địa chỉ IP của nó:

[email protected]:~ $ Dig +short whitehouse.gov
173.223.0.110

Bây giờ, giả sử rằng ughackerz.cn phân giải thành một địa chỉ IP ở đâu đó trong khối 1.0.32.0-1.0.63.255 (để tham khảo: http://www.nirsoft.net/countryip/cn.html khối đầu tiên trong danh sách). Địa chỉ IP đó sẽ nằm trong tiêu đề thư đầy đủ. Tất cả những gì bạn phải làm là lấy IP đó trực tuyến để theo dõi vị trí địa lý của nó (bạn có thể sử dụng http://www.geoiptool.com/ chẳng hạn)

IP cho whitehouse.gov (173.223.0.110) tại thời điểm viết bài đăng này định vị địa lý cho Boston, Massachusetts (vì một số lý do, hệ thống ngăn chặn thư rác sẽ không cho phép tôi đăng tìm kiếm của tôi trên Geoiptool do điểm danh tiếng, vì vậy bạn có thể đi tự tìm kiếm) khá gần nhà (Quận Columbia)! Chúng ta hãy giả sử rằng Whitehouse.gov được lưu trữ trong một trung tâm dữ liệu ở Boston chỉ để giải thích điều này dễ dàng hơn.

Miễn là địa chỉ IP và email mà email đó là thực sự được gửi từ không khớp với địa chỉ IP và email mà email khiếu nại là gửi từ, nó có thể được xác định là giả mạo. Bạn chỉ cần tìm trong đầy đủ tiêu đề thư.


Hãy xem các tiêu đề của email tôi đã gửi từ một trong các tên miền của riêng tôi (dragon-architect.com) đến địa chỉ email cá nhân của riêng tôi:

Delivered-To: [email protected]
Received: by 10.180.89.68 with SMTP id bm4csp105911wib;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
X-Received: by 10.60.30.38 with SMTP id p6mr1296792oeh.2.1359478487251;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
Return-Path: <[email protected]>
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35])
    by mx.google.com with ESMTP id m7si14056914oee.29.2013.01.29.08.54.45;
    Tue, 29 Jan 2013 08:54:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) client-ip=69.93.154.35;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) [email protected]
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007)
    id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST)
Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130])
    by gateway14.websitewelcome.com (Postfix) with ESMTP id EA7191DFDB314
    for <[email protected]>; Tue, 29 Jan 2013 10:54:42 -0600 (CST)
Received: from [127.0.0.1] (port=43458 helo=dragon-architect.com)
    by bentley.websitewelcome.com with esmtpa (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1U0ESK-0001KE-DP
    for [email protected]; Tue, 29 Jan 2013 10:54:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Jan 2013 10:54:44 -0600
From: [email protected]
To: <[email protected]>
Subject: Headers Test
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/0.8.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bentley.websitewelcome.com
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dragon-architect.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (dragon-architect.com) [127.0.0.1]:43458
X-Source-Auth: [email protected]
X-Email-Count: 1
X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20=

Testing testing!

Đó là rất nhiều dữ liệu ngẫu nhiên để sàng lọc, nhưng có hai dòng chúng ta đang xem xét ở đây: đường dẫn trở lại và từ. Vì tôi hợp pháp gửi email này cho chính mình, cả hai đều khớp. Đường dẫn trở lại không thể bị giả mạo. Hoặc nếu có thể, thật khó để giả mạo một cách hiệu quả và yêu cầu một số cấu hình có chủ ý của daemon SMTP được sử dụng để gửi thư. So sánh đường dẫn trở lại và từ các trường dữ liệu trong các tiêu đề đầy đủ là một cách mà tôi và đồng nghiệp nơi tôi làm việc có thể xác định giả mạo và xác định xem có cần phải gửi một vé hỗ trợ hay không.

Vì vậy, điều gì sẽ xảy ra nếu cả hai khớp nhau, nhưng email vẫn bị giả mạo? Tôi sẽ đến đó trong phần tiếp theo ...


Bây giờ, như đã đề cập trước đây, có những cách khác để xác định tính giả mạo của một email. Bản ghi SPF là một trong những cách đó, nhưng chúng không phải lúc nào cũng hoàn hảo. Lấy ví dụ: SPF của whitehouse.gov và so sánh nó với SPF của tên miền của riêng tôi:

[email protected]:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
[email protected]:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Thông thường, một bản ghi SPF tốt cũng bao gồm địa chỉ IP của máy chủ đã gửi thư, vì vậy bất cứ ai đã tạo bản ghi SPF cho whitehouse.gov có thể không biết điều này. Tôi sẽ coi bản ghi SPF của Whitehouse.gov quá chung chung để có hiệu quả trong việc xác định nguồn gốc thực sự của bất kỳ thư nào được cho là của Whitehouse.gov. Mặt khác, SPF cho tên miền của tôi, được tạo tự động bởi máy chủ lưu trữ tên miền của tôi (nhờ vào webhost của tôi), rất cụ thể và bao gồm địa chỉ IP của chính máy chủ.

Tôi sẽ thừa nhận không quen thuộc với cách định dạng các bản ghi SPF và cách chúng hoạt động, nhưng tôi đã học đủ về công việc của mình rằng ít nhất tôi có thể xác định các bản ghi SPF chung và cụ thể. Đoán đó là một cái gì đó tôi có lẽ nên đào vào một số ngày cuối tuần khi tôi chán và muốn một số tài liệu đọc kỹ thuật!

Dù sao, trở lại theo dõi ở đây. Nhìn vào các dòng đã nhận. Do đó, một trong số họ tuyên bố: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Đoán xem? Điều đó khớp với địa chỉ IP trong bản ghi SPF của miền tôi.

Nếu IP trong SPF không khớp với IP của máy chủ thực sự đã gửi email, thì đó là một dấu hiệu khác cho thấy bạn đã giả mạo trên tay. Do đó, một bản ghi SPF chung như "v=spf1 +mx ~all" Sẽ không cắt mù tạt bảo mật. Tôi thậm chí sẽ không tin tưởng các email đến từ a hợp pháp tên miền có SPF chung như thế này.

Có lẽ chúng ta nên nộp đơn yêu cầu kiến ​​nghị.whitehouse.gov để yêu cầu quản trị viên bảo mật của họ xem lại bản ghi SPF mà họ đã tạo cho tên miền! (Tôi nhóc, tôi nhóc.)

[~ # ~] chỉnh sửa [~ # ~]

Tôi thực sự phải [~ # ~] ồ ạt [~ # ~] tự sửa về bản ghi SPF! Tôi đã đưa ra một số giả định sai và đã học được một số điều ngày hôm nay sau khi hỏi một đồng nghiệp là người hiểu biết nhiều hơn tôi về các bản ghi SPF. Vì vậy, tôi sẽ sử dụng hai SPF cho whitehouse.gov và dragon-architect.com để tự điều chỉnh:

[email protected]:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
[email protected]:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

SPF cho tên miền của riêng tôi thực sự nhẹ nhàng hơn SPF cho Whitehouse.gov (điều tôi dự định sẽ sửa vào tối nay sau khi tôi hoàn thành chỉnh sửa này). Tôi sẽ giải thích tại sao:

"v=spf1 +mx ~all" Về cơ bản nói rằng các email từ whitehouse.gov được cho là xuất phát từ tên máy chủ được xác định trong hồ sơ MX cho Whitehouse.gov và bất kỳ email nào không đến từ các tên máy chủ đó đều được cho là giả mạo, nhưng liệu chúng có phải là giả mạo hay không Đánh dấu giả mạo hay không là tùy thuộc vào người nhận email.

[email protected]:~ $ Dig +short mx whitehouse.gov
110 mail6.eop.gov.
105 mail2.eop.gov.
110 mail5.eop.gov.
105 mail1.eop.gov.
105 mail4.eop.gov.
105 mail3.eop.gov.

"v=spf1 +a +mx +ip4:70.84.243.130 ?all" Nói rằng các email từ dragon-architect.com được cho là đến từ địa chỉ IP cho dragon-architect.com (67,18.28.78), tên máy chủ được xác định trong (các) bản ghi MX cho kiến ​​trúc sư rồng .com hoặc địa chỉ IP của máy chủ lưu trữ dragon-architect.com (70.84.243.130). Cuối cùng, bất kỳ email nào không đến từ những email đó, tất cả chỉ có nghĩa là không có lời khuyên nào về việc vượt qua hay từ chối các email.

Vì vậy, thịt và khoai tây của một bản ghi SPF là gì? "Tất cả" ở cuối. Để trích dẫn đồng nghiệp này về "tất cả":

+all basically means ALL pass -- the record is useless, sender domain doesn't care
?all indicates neutral and is advising to not pass or reject mail
~all indicates fail, and the server is considered invalid, but does not specifically suggest an action.
-all is a hard fail, anything else is invalid, reject or flag it.

Vì vậy, "tất cả" là nơi bạn xác định mức độ nghiêm ngặt của bản ghi SPF. Nhưng liệu bản ghi SPF có thực sự là đã sử dụng để xác định mức độ giả mạo của email là hoàn toàn cho đến khi nhận dịch vụ email.

Vì vậy, có bạn có nó. SPF trong một tóm tắt.


Vì vậy, vâng. TL; DR: kiểm tra các tiêu đề đầy đủ của bạn để xem liệu đường dẫn trở lại và từ các trường có khớp nhau không. Sau đó kiểm tra kỹ các bản ghi SPF của bạn nếu có bất kỳ để xem bạn có nhận được địa chỉ IP phù hợp hay không.

15
Calyo Delphi

SMTP (Đơn giản Giao thức chuyển thư) được đặt tên theo lý do rất chính đáng.

SMTP bắt nguồn từ năm 1982 trên ARPANET cũ, được sở hữu và kiểm soát bởi DoD Hoa Kỳ, và nhằm mục đích liên lạc giữa những người có giải phóng mặt bằng bảo mật làm việc trong các dự án của chính phủ, những người thường có thể tin tưởng không lạm dụng nó. "Bảo mật" của mạng này được thực hiện khá đơn giản bằng cách đặt các máy có thể kết nối với nó trong các khu vực được bảo mật vật lý của các cơ sở khác nhau, ngay bên cạnh công việc được phân loại mà các cơ sở này đang thực hiện. Do đó, việc bảo mật dữ liệu được gửi dọc mạng thường không được xem xét cho đến khi ARPANET ngừng hoạt động, với bước nhảy lượng tử đầu tiên vào năm 1993 với API lập trình mạng an toàn (đặt nền móng cho Lớp cổng bảo mật, hiện được biết đến như Bảo mật lớp vận chuyển). Mặc dù hầu hết các giao thức (bao gồm cả SMTP/POP/IMAP) hiện có thể thêm TLS cho kênh liên lạc an toàn, tất cả những gì cung cấp là bảo mật và tính xác thực của máy chủ; nó không cung cấp tính xác thực của người gửi hoặc tính toàn vẹn của tin nhắn và nó cũng không cung cấp sự từ chối.

Có một tùy chọn có sẵn cho bảo mật email, được gọi là PGP (Quyền riêng tư khá tốt; đó là sự hài hước trong miệng của Phil Zimmerman cho một hệ thống mà không máy tính nào trên hành tinh có thể phá vỡ nếu được thực hiện đúng cách). Nó có thể, với các tùy chọn khác nhau, cung cấp tất cả bốn nguyên lý cơ bản về bảo mật thông tin; bảo mật, tính toàn vẹn, tính xác thực và không thoái thác (người gửi, người đã ký e-mail bằng chứng chỉ của họ, không thể tuyên bố rằng họ không thực sự gửi nó; không ai có thể có, trừ khi chứng chỉ bị xâm phạm). Nó sử dụng một hệ thống chứng chỉ khóa công khai tương tự và trao đổi khóa an toàn như được thấy trong bắt tay TLS hai chiều, nhưng một số chi tiết được thay đổi để phản ánh bản chất không đồng bộ của vận chuyển e-mail và để phản ánh mong muốn phân cấp " web của niềm tin "không cần đến các cơ quan cấp chứng chỉ tin cậy toàn cầu.

Tuy nhiên, hệ thống này vẫn chưa thực sự cất cánh mặc dù đã hơn 25 tuổi và do đó, nó chỉ được yêu cầu bởi các cơ quan chính phủ và một số tập đoàn lớn. Hầu như tất cả các nhà cung cấp e-mail vẫn sẽ vui vẻ gửi e-mail lừa đảo qua các kết nối an toàn đến hộp thư đến của bạn. Trong nhiều trường hợp, bạn có thể khuyến khích bạn bè và những người khác mà bạn muốn nhận e-mail chấp nhận chương trình PGP và bất cứ điều gì không được ký hợp lệ đều đi vào "cách ly", nhưng đây thực sự chỉ là một cấp độ khác của "lọc thư rác ", Và tôi không biết về một nhà cung cấp e-mail công cộng duy nhất mà bạn có thể hướng dẫn từ chối e-mail mà không có chữ ký điện tử hoàn toàn; máy chủ email sẽ phải nằm dưới sự kiểm soát của bạn, chẳng hạn như máy chủ Exchange của công ty.

12
KeithS

tl; dr

  • Paypal có đang khai thác một vấn đề bảo mật ở đây không? ... Làm thế nào để Paypal giả mạo email dễ dàng như vậy?

Về mặt kỹ thuật, không phải là vấn đề bảo mật, email không an toàn để bắt đầu. Họ đang sử dụng một trong các tiêu đề SMTP sau nằm trong tiêu đề thư (không phải tiêu đề phong bì)

  1. Resent-From
  2. Resent-Sender
  3. Sender

Có một sự khác biệt về khái niệm giữa "nhắc nhở" và "giả mạo". Ứng dụng email nên hiển thị sự khác biệt này. Ứng dụng khách Gmail không làm điều này.

  • Paypal không giả mạo, họ đang sử dụng một trong những tiêu đề SMTP này: Resent-From, Resent-Send, hoặc Người gửi

  • Rất dễ giả mạo tên miền ... ngay cả khi bật điều khiển SPF

  • MUA (ứng dụng email) sẽ hiển thị Hiển thị từ, trạng thái xác minh SPF, DKIM và DMARC của nó.

  • Tiêu đề Resent- * nên được sử dụng theo cách làm cho thông báo này rõ ràng là "được gửi lại".

  • Nói chung, giải pháp tốt nhất là sử dụng DKIM + DMARC hoặc SPF + DMARC và MUA hiển thị kết quả xác minh.


Một số nền tảng

Nói chung, có hai địa chỉ "từ" và hai địa chỉ "đến" trong mỗi tin nhắn SMTP. Một cái được gọi là Phong bì RFC2821, cái còn lại là Thông điệp RFC2822. Họ phục vụ các mục đích khác nhau

Phong bì: (RFC2821)

  • Phong bì là siêu dữ liệu không xuất hiện trong tiêu đề SMTP. Nó biến mất khi tin nhắn đến MTA tiếp theo.

  • Các RCPT From: là nơi NDR sẽ đi. Nếu một tin nhắn đến từ Postmaster hoặc dịch vụ gửi lại thì đây thường là <> hoặc là [email protected]. Thật thú vị khi thấy rằng lực lượng bán hàng sử dụng điều này tương tự như ConstantContact làm khóa trong cơ sở dữ liệu như [email protected] để xem tin nhắn có bị trả lại không.

  • Các RCPT TO: là người mà tin nhắn thực sự được gửi đến. Nó được sử dụng cho người dùng "đến" và "bcc". Điều này thường không ảnh hưởng đến "hiển thị địa chỉ" trong ứng dụng thư khách, nhưng có những lần MTA sẽ hiển thị trường này (nếu các tiêu đề RFC2822 bị hỏng).

Tin nhắn (RFC2822)

  • Phần thông báo bắt đầu khi lệnh data được ban hành.

  • Thông tin này bao gồm các tiêu đề SMTP mà bạn quen thuộc, tin nhắn và tệp đính kèm. Hãy tưởng tượng tất cả dữ liệu này được sao chép và dán từ mỗi MTA sang lần tiếp theo, liên tiếp cho đến khi tin nhắn đến hộp thư đến.

  • Theo thông lệ, mỗi MTA sẽ thêm tiền tố vào bản sao được đề cập ở trên và dán thông tin về MTA (IP nguồn, IP đích, v.v.). Nó cũng dán chi tiết kiểm tra SPF.

  • Đây là Display From được đặt. Điều này quan trọng. Người giả mạo có thể sửa đổi điều này.

  • Các Mail From: trong phong bì bị loại bỏ và thường được đặt ở đây là return-path: địa chỉ cho NDR

Vậy làm cách nào để ngăn mọi người sửa đổi Display From? Vâng DMARC định nghĩa lại ý nghĩa thứ hai cho bản ghi SPF. Nó nhận ra rằng có một sự khác biệt giữa Phong bì từHiển thị từ, và có những lý do chính đáng để chúng không khớp. Do SPF ban đầu được xác định là chỉ quan tâm đến Envel From, nếu Display From khác, DMARC sẽ yêu cầu kiểm tra DNS thứ hai để xem tin nhắn có được cho phép từ địa chỉ IP đó không.

Để cho phép chuyển tiếp các kịch bản, DMARC cũng cho phép Hiển thị từ được ký mã hóa bởi DKIM và nếu bất kỳ người gửi thư rác hoặc kẻ lừa đảo trái phép nào cố gắng nhận dạng danh tính đó, mã hóa sẽ thất bại.

DKIM là gì? DKIM là một công nghệ mã hóa nhẹ, ký kết dữ liệu cư trú trong tin nhắn. nếu bạn đã từng nhận được tin nhắn từ Gmail, Yahoo hoặc AOL thì tin nhắn của bạn đã được DKIM ký. Điểm đáng chú ý là sẽ không ai biết bạn đang sử dụng mã hóa và ký DKIM trừ khi bạn nhìn vào các tiêu đề. Nó trong suốt.

DKIM thường có thể tồn tại khi được chuyển tiếp và chuyển đến các MTA khác nhau. Điều mà SPF không thể làm được. Quản trị viên email có thể sử dụng điều này để lợi thế của chúng tôi để ngăn chặn giả mạo.


Vấn đề nằm ở việc chỉ kiểm tra SPF của phong bì RFC2821 chứ không phải Hiển thị từ. Vì hầu hết mọi người quan tâm đến Hiển thị từ được hiển thị trong thông báo email chứ không phải đường dẫn trả lại NDR, chúng tôi cần một giải pháp để bảo vệ và bảo mật phần này.

Đây là nơi DMARC xuất hiện. DMARC cho phép bạn sử dụng kết hợp kiểm tra SPF đã sửa đổi hoặc DKIM để xác minh Hiển thị từ. DKIM cho phép bạn ký mật mã vào Màn hình RFC2822 từ bất cứ khi nào SPF không khớp với Hiển thị từ (xảy ra thường xuyên).


Là giả mạo Hiển thị từ một vấn đề bảo mật?

Có, lừa đảo mặc dù email là một vấn đề bảo mật quan trọng mà nhiều nhà cung cấp đang xem xét. Cụ thể là Paypal, AOL, Google, Yahoo và các công ty khác đang triển khai DMARC để khắc phục vấn đề rất lừa đảo này.

Tại sao vẫn có thể giả mạo tiêu đề "Từ:" trong e-mail?

Một số quản trị viên máy chủ đã không triển khai các công nghệ mới nhất để ngăn chặn điều này xảy ra. Một trong những điều chính ngăn cản việc áp dụng các công nghệ này là "dịch vụ chuyển tiếp email", chẳng hạn như phần mềm danh sách gửi thư, chuyển tiếp tự động hoặc người gửi thư cho cựu sinh viên trường học (.forwarder). Cụ thể là:

  1. SPF hoặc DKIM không được cấu hình.

  2. Chính sách DMARC không được thiết lập.

  3. Ứng dụng email không hiển thị kết quả xác minh của Hiển thị từ và trường Resent- * hoặc Người gửi.

Paypal đang làm gì?

Paypal đang sử dụng tiêu đề Người gửi để cho biết nó đã được gửi lại. Đây là cách sử dụng đúng và dự định của tiêu đề này.

GMail đang làm gì sai?

Gmail không làm rõ rằng tiêu đề Người gửi đang được sử dụng, họ không xác thực địa chỉ Hiển thị Từ theo cách thân thiện với người dùng và không phân biệt giữa hiển thị từ và người gửi.

5
goodguys_activate