Tuesday, July 29, 2008

luôn có lỗi trong hệ thống

trong bài trước, tôi có nói, có nhiều trường hợp vì ràng buộc của các mục tiêu kinh doanh, chúng ta không thể vá lỗi, dù lỗi đó có nguy hiểm đến đâu đi chăng nữa. điều này thoạt nghe thì thấy hết sức nguy hiểm, nhưng nếu suy nghĩ kỹ, chúng ta sẽ thấy, sự thực là chúng ta đã, đang và sẽ sống với những hệ thống có lỗi nghiêm trọng.

khi một hệ thống nào đó bị tấn công, các *chuyên gia bảo mật* sẽ thường đổ lỗi sẽ cho đám sysadmin không chịu vá lỗi. "đã có bảng vá từ vài tháng trước, nhưng họ không chịu vá, để rồi bây giờ bị tấn công là phải rồi". đúng là việc vá lỗi là việc nên làm, nhưng lỗi không phải ở đám sysadmin.

một sự thật đáng buồn là có quá nhiều lỗ hổng bảo mật. mỗi tuần tôi nhận được một bản báo cáo từ US-CERT về số lỗ hổng bảo mật đã được phát hiện trong tuần. đây là danh sách trong tuần vừa rồi, chỉ tính riêng lỗi critical thôi là đã 25, còn tổng số là 52 lỗi tất cả.

để an toàn, sysadmin phải vá tất cả lỗi. để tấn công thành công, attacker chỉ cần khai thác thành công một lỗi. đó đã là một cuộc chiến quá có lợi cho attacker, vậy mà sự thật là sysadmin không có cách nào có thể vá hết lỗi được, bởi các điều kiện ràng buộc về mục tiêu kinh doanh như đã phân tích ở bài trước.


và dẫu cho sysadmin có vá hết lỗi, thì đó cũng chỉ là những lỗi đã biết và nhà sản xuất phần mềm đã cung cấp miếng vá rồi. còn những lỗi chưa có miếng vá thì sao? hay những lỗi đã được tìm thấy nhưng chưa được công bố rộng rãi (0-day)? hay những lỗi chưa được tìm thấy? hay những lỗi do lập trình viên cố tình tạo ra trong quá trình viết phần mềm, để trục lợi về sau (backdoor)?

nói cách khác, cái quy trình "có lỗi --> vá lỗi" không đem lại sự an toàn như mong đợi. dù muốn hay không, chúng ta phải thừa nhận rằng: luôn có lỗi trong hệ thống. vậy làm sao để bảo vệ an toàn cho một hệ thống luôn có lỗi?

tôi thấy có 3 giải pháp: theo dõi, theo dõi, và theo dõi.

phải theo dõi làm sao để có thể trả lời được câu hỏi: ai (who) làm thế nào (how) để gây ra chuyện gì (what) vào khi nào (when) trên hệ thống nào (where) của tôi?

theo dõi như thế nào? đó lại là một câu chuyện dài :-p.

Saturday, July 26, 2008

không phải cứ có lỗi là vá

trong vụ lỗi của máy chủ DNS, tôi thấy nhiều bạn cứ thắc mắc tại sao tôi nói tự vì kiểm tra là phải kiểm tra xem có người sử dụng dịch vụ của máy chủ DNS có được bảo vệ an toàn hay không, còn việc vá hay không vá là việc tính sau..

cái ý tưởng "có lỗi thì phải vá" thường xuất hiện ở một số bạn nghĩ là mình hiểu về bảo mật nhưng sự thật thì kô hiểu được bao nhiêu. bản thân tôi cũng đã phải mất một thời gian dài mới ngộ được ra vấn đề này, thôi thì hôm nay chia sẻ ở đây.

"có lỗi trong phần mềm tôi đang sử dụng, nên tôi cập nhật nó", một lý lẽ xem ra rất thuyết phục, nếu như không có các ràng buộc từ phía business.

mục tiêu cốt lõi và cuối cùng của một hệ thống không phải là để vá hết lỗi, mà là để phục vụ những yêu cầu của người sử dụng, như họ mong đợi, theo đúng thiết kế ban đầu của hệ thống.


đôi khi, chính cái ràng buộc, chính cái yêu cầu cốt lõi này, làm cho chúng ta phải chấp nhận vận hành một hệ thống, mà trong đó, chúng ta biết là có lỗi có thể bị khai thác. đối với nhiều bạn mới tìm hiểu về bảo mật, sẽ thấy luận điểm này khá là phản trực giác, chạy một hệ thống không an toàn là một điều không thể chấp nhận được đối với họ. rồi cuối cùng họ bị sa thải :-p, bởi hành động vá lỗi, mà họ nghĩ là tích cực, rốt cuộc lại làm tê liệt hoàn toàn hệ thống, làm thiệt hại hàng trăm nghìn, hàng triệu USD.

trở lại với vấn đề DNS. nếu bạn nào theo dõi kỹ sự kiện này, sẽ thấy những cảnh báo sau đây "the patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. Đây là một vấn đề không thể xem nhẹ, nhất là đối với các ISP lớn, bởi lẽ nếu DNS resolver của họ chết, thì toàn bộ cái mục tiêu cốt lõi của họ cũng sẽ đi tong.

ngoài ra, việc vá lỗi, dẫn đến source port sẽ bị ngẫu nhiên hóa, và sẽ có thể dẫn đến những thay đổi lớn trong cấu hình mạng của hệ thống. chẳng hạn như cấu hình firewall hay cấu hình của các thiết bị NAT. mà những thay đổi về cấu hình mạng đôi khi không phải cứ muốn làm là được.

hơn nữa, trong các doanh nghiệp hay ISP to, việc cập nhật phần mềm đối với một hệ thống critical như DNS không phải là việc các tay sysadmin muốn là có thể làm. tất cả những việc này đều có quy trình, và quy trình thì cần có thời gian. một số DNS resolver của AT&T cho đến nay vẫn chưa vá lỗi, bởi họ vẫn đang còn trong giai đoạn thử nghiệm, trước khi triển khai chính thức các miếng vá.

nói cách khác, biết là có lỗi, biết là có thể bị khai thác, biết là người dùng có thể bị ảnh hưởng nhưng vẫn không vá được ngay, thì tại sao phải vội vã hấp tấp vá, nếu như biết là có lỗi, nhưng không thể bị khai thác hay người dùng không bị ảnh hưởng?


đừng nghĩ tôi tự đặt ra những câu hỏi thế này. nếu bạn làm trong lĩnh vực này đủ lâu, sẽ có ngày một ông ở cấp C hỏi bạn câu hỏi này. không thể có chuyện vá chỉ để sướng :-p.

thành ra, nếu như DNS resolver của tôi có lỗi, nhưng do tôi đang forward toàn bộ recursive query đến một DNS forwarder đã vá lỗi, thì tôi chưa cần phải vá lỗi ngay tức thì, bởi lẽ người dùng của tôi vẫn an toàn, nghĩa là cái mục tiêu cốt lõi của hệ thống DNS vẫn được đáp ứng.

thực tế đây chính là một trong những giải pháp được rất nhiều chuyên gia trên thế giới đề nghị, kể cả Dan Kaminsky, và rất nhiều người đã áp dụng nó bằng cách forward các recursive query của họ đến cho OpenDNS, để có thêm thời gian đánh giá vấn đề.

điểm cốt yếu phân biệt giữa những tay nghĩ là họ làm về security với những người thực sự làm về security là mấy tay đầu luôn nghĩ security là một vấn đề kĩ thuật, có thể giải quyết bằng các giải pháp kỹ thuật; còn mấy tay sau, sau vài năm lăn lộn với đám làm business, biết rằng security là một vấn đề của business, không thể tách ra khỏi cái mục tiêu của business, chỉ có thể xem là được giải quyết thành công nếu vẫn đáp ứng được yêu cầu của business.

điều đáng buồn là đa số những người đi làm tư vấn bảo mật, và đa số các công ty tư vấn bảo mật chuyên nghiệp ở VN, mà công việc cho phép tôi gặp khá nhiều, thường chưa từng kinh qua công việc làm bảo mật cho các doanh nghiệp trước đó. mục tiêu của họ là làm sao cho hệ thống an toàn, trong khi mục tiêu cần phải đạt được của doanh nghiệp là các chỉ tiêu kinh doanh. khác mục tiêu, sẽ dẫn đến xung đột :-p.

tool kiểm tra dns của bkis có thể trả về kết quả sai

tranh luận một hồi với các bác ở bkis, tôi phát hiện ra được vài chỗ mà tool của các bác bkis sẽ làm sai, false negative hay false positive:

1. client --> A --> B --> Authorative DNS servers

* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình để forward recursive query đến B, một dns cache nằm ngoài tầm của sysadmin.

* false negative sẽ xảy ra khi A đã vá, nhưng B chưa vá. Công cụ của bkis sẽ báo là an toàn, nhưng thực tế tất cả client sử dụng A đều đứng trước nguy cơ bị tấn công.

* false positive sẽ xảy ra khi A không vá, nhưng B đã vá. Công cụ của bkis sẽ báo là không an toàn, yêu cầu vá (không phải lúc nào cũng muốn vá là vá :-p), nhưng thực tế tất cả client sử dụng A đều an toàn trước loại tấn công này.

Trong cả hai trường hợp, cách làm của tôi đưa ra đều thông báo chính xác là bạn có đang an toàn hay không an toàn (lưu ý là nó quan tâm đến người sử dụng, bất kể DNS có được vá hay chưa vá). Và nó áp dụng được cả cho người dùng bình thường lẫn sysadmin.

2. client --> A --> NAT device --> Authorative DNS servers

* A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình chấp nhận recursive query từ client.

* phía sau A (trước khi ra Internet) là một thiết bị NAT, làm thay đổi dest IP hoặc source port của các packet đi ra từ A

* false negative sẽ xảy ra khi A không vá, nghĩa là dùng fixed source port, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó ngẫu nhiên, nên tool của bkis sẽ báo là an toàn.

tuy gọi là false negative nhưng NAT device trong trường hợp này lại vô tình bảo vệ cái lỗ hổng của A, làm cho việc khai thác trở nên rất khó.

* false postivie sẽ xảy ra khi A đã vá, nghĩa là source port đã được randomized, nhưng khi đi ra đến NAT device, NAT device lại thay đổi source port, làm cho nó hết ngẫu nhiên, nên tool của bkis sẽ báo là không an toàn.

tuy gọi là false postive, nhưng NAT device trong trường hợp này lại vô tình làm cho việc A có vá hay không vá trở nên vô nghĩa.

trong hai trường hợp này, cái cách làm của tôi cho kết quả giống với cách làm của bkis.

tóm gọn lại: có ai cần một phần mềm trả về kết quả sai (và phải cấu hình lung tung mới dùng được, và chỉ dành cho sysadmin :-p), trong khi chỉ cần gõ một lệnh là được kết quả chính xác hơn, ngay cả người dùng bt cũng có thể kiểm tra được?

Thursday, July 24, 2008

Hindsight analysis of the infamous DNS bug

If you read Dan Kaminsky's researchs over the past few years, you'd probably know that Dan knows many DNS tricks. One of these is the CNAME trick that Dan mentioned in the Wired interview. He has talked about this trick back to 2007 as below:

1. CNAME Records: DNS Aliases

- Instead of returning an address, return what the "Canonical", or Official Name was, and then the address of that Canonical Name

- If you are allowed to be the resolver for that canonical name, your additional record overrides whatever's already in the cache, even if the TTL hasn't expired yet

* It's not a bug.

* Works against most, but not actually all name servers

2. Demo

$ dig 1.foo.notmallory.com
;; ANSWER SECTION:
1.foo.notmallory.com. 120 IN CNAME bar.foo.notmallory.com
bar.foo.notmallory.com. 120 IN A 10.0.0.0

$ dig bar.foo.notmallory.com
bar.foo.notmallory.com. 111 IN A 10.0.0.0

$ dig 2.foo.notmallory.com
2.foo.notmallory.com. 120 IN CNAME bar.foo.notmallory.com.
bar.foo.notmallory.com. 120 IN A 10.0.0.1

$ dig bar.foo.notmallory.com
bar.foo.notmallory.com. 118 IN A 10.0.0.1
As you can see, this trick, Dan called it "CNiping", can be used to overwrite whatever is www.yourwebsite.com. I guess when Dan talked to Paul Vixie, Paul told him that not only CNAME can be used to overwrite cached data but also NS, and probably other type of RRs as well. This is not new. RFC3833 has told us about this DNS *feature* for years.

Okie so now, we have some ways to overwrite cached data in a DNS resolver, the remained problem is how to force it to accept our packet. And you probably know this already, so I don't repeat here.

The rest of this post to to emphasize on how easy to guess the QID if we have a fast Internet connection. Much of the following part is derived from this study (http://www.faqs.org/ftp/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt).


Assume the following symbols are used:

I: Number distinct IDs available (maximum 65536)

P: Number of ports used (maximum around 64000, but often 1)

N: Number of authoritative nameservers for a domain (averages
around 2.5)

F: Number of 'fake' packets sent by the attacker

R: Number of packets sent per second by the attacker

W: Window of opportunity, in seconds. Bounded by the response
time of the authoritative servers (often 0.1s)

D: Average number of identical outstanding questions of a resolver
(typically 1, see Section 5)

A: Number of attempts, one for each window of opportunity

The probability of spoofing a resolver is equal to amount of fake packets that arrive within the window of opportunity, divided by the size of the problem space.

When the resolver has 'D' multiple identical outstanding questions, each fake packet has a proportionally higher chance of matching any of these questions. This assumption only holds for small values of 'D'.

In symbols, if the probability of being spoofed is denoted as P_s:

P_s = D*F/N*P*I

It is more useful to reason not in terms of aggregate packets but to convert to packet rate, which can easily be converted to bandwidth if needed.

If the Window of opportunity length is 'W' and the attacker can send 'R' packets per second, the number of fake packets 'F' that are candidates to be accepted is:

F= R * W ---> P_s = D*R*W/N*P*I

To calculate the combined chance of at least one success, the following formula holds:

P_cs = 1 - (1 - P_s)^A = 1 - (1 - D*R*W/N*P*I)^A

When common numbers (as listed above) for D, W, N, P and I are inserted, this formula reduces to:

P_cs = 1 - (1 -R/1638400)^A

The different between this attack and the one described in the original study (http://www.faqs.org/ftp/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt) is in the number A.

In the original study, A = T/TTL, where T is the time taken to successful poison target resolvers, and TTL is the number of seconds when the target hostname expires. In other words, each time we fail to poison, we must have to wait for TTL second before trying again.

In this case, A = N, which is the number of queries we send to target resolvers. This is because we don't have to wait any second even if we fail to poison in all previous attempts. Remember the CNAME trick above?

So all you must do now is to increase R and A. Suppose for each query, you send F = 30 fake responses to target resolvers in W = 0.1, hence your bandwidth should be R = F/W = 300 packet/s. If A = 4000, then you stand a 51% chance to be sucessful! It's that easy.

If you use Metasploit, you can use the following formula to calculate your probability:

P_cs = 1 - (1 - xids/2^16)^A

where xids is the number of fake responses you want to send for each query. Remember to consider your bandwidth capacity when choosing xids. If you choose the default value, i.e. xids=10, then you can expect to poison successful after A>4000.

One final note: this attack is not a birthday attack. because we have
only one opening query to guess its QID.

Tuesday, July 22, 2008

(Báo Động Đỏ) Lỗi bảo mật đặc biệt nghiêm trọng, mọi người chú ý

Gửi các bạn của tôi, mới đây một lỗ hổng bảo mật cực kỳ nghiêm trọng được phát hiện trong hệ thống DNS, xương sống của toàn bộ Internet.

Tận dụng lỗ hổng này, kẻ xấu có thể tấn công để đánh cắp tất cả thông tin trên Internet của bạn, chẳng hạn như chiếm quyền điều khiển blog của bạn, chôm mật khẩu để đọc trộm email hay giả danh bạn để chat trên Yahoo! Messenger. Tôi nhắc lại, khi khai thác thành công lỗ hổng này, kẻ xấu hoàn toàn có thể chiếm quyền điều khiển cuộc sống online của bạn.

Entry này được viết để cung cấp thêm cho các bạn những thông tin cần biết về lỗ hổng này, cũng như các phương pháp phòng chống tạm thời, cho đến khi có giải pháp triệt để từ phía các ISP ở VN.

---

Giới thiệu về DNS


DNS viết tắt của Domain Name System, là hệ thống quản lý việc ánh xạ giữa địa chỉ của máy tính trên Internet với tên của chúng. Trên Internet, mỗi máy tính đều được cấp một địa chỉ riêng biệt, thường được gọi là IP address, tạm dịch là địa chỉ IP (IP viết tắt của Internet Protocol, giao thức điều khiển việc trao đổi thông tin liên lạc giữa hai máy tính trên Internet).

Địa chỉ IP thường dài và khó nhớ, phù hợp với máy tính, không phù hợp với trí nhớ của con người (thường chỉ có khả năng nhớ được tối đa 7 số tại một thời điểm), do đó người ta mới đặt cho mỗi máy tính một cái tên dễ nhớ, chẳng hạn như www.vnexpress.net, www.yahoo.com, www.tuoitre.com.vn..., rồi sử dụng hệ thống DNS nói trên để ánh xạ những tên này vào các địa chỉ IP thực sự của chúng.

Khi bạn gõ www.vnexpress.net vào trình duyệt và nhấn enter, máy tính của bạn sẽ hỏi máy chủ DNS của bạn (thường là máy chủ do ISP của bạn quản lý) địa chỉ của www.vnexpress.net là bao nhiêu. Máy chủ DNS của bạn sẽ đi hỏi những máy chủ DNS khác trên Internet, để rồi cuối cùng trả lời cho máy tính của bạn rằng, www.vnexpress.net chính là tên miền của máy tính có địa chỉ IP là 210.245.0.22. Máy tính của bạn sẽ căn cứ vào địa chỉ này để liên lạc với www.vnexpress.net và lấy về nội dung mà bạn muốn xem.

Nếu bạn nào sống ở Mỹ hay các nước tiên tiến, thì có thể hiểu hệ thống DNS tương tự như hệ thống Postal/Zip Code, dùng để ánh xạ giữa zip code với địa chỉ nhà bạn.

Thông tin chi tiết về lỗi

Lỗi tấn công ở đây xảy ra khi máy chủ DNS của bạn bị kẻ xấu cố tình cung cấp thông tin sai lệch, khiến nó nhầm tưởng địa chỉ IP của www.vnexpress.net không phải là 210.245.0.22 mà lại là một địa chỉ IP của một máy tính nằm trong sự điều khiển của hắn. Thuật ngữ chuyên ngành gọi đây là DNS cache poisoning attack.

Khi đó, lúc bạn gõ www.vnexpress.net, thay vì nhận được nội dung từ trang VnExpress thật, bạn sẽ nhận được nội dung giả mạo từ phía kẻ xấu. Điều nay cực kỳ nguy hại, bởi lẽ áp dụng kỹ thuật này, kẻ xấu có thể mạo danh tất cả các website trên thế giới, từ Google, Yahoo, Microsoft, Paypal hay website của ngân hàng hay công ty chứng khoán của bạn. Khi đã mạo danh các website này rồi, kẻ xấu sẽ có thể đánh cắp được tất cả tài khoản cá nhân của bạn trên những website này.

Nếu bạn đọc kỹ, bạn sẽ thấy kẻ xấu không trực tiếp tấn công vào máy tính của bạn, mà tấn công vào máy chủ DNS của bạn (do ISP của bạn quản lý và cung cấp lại cho bạn sử dụng).

Thật tế dạng tấn công này đã được thực hiện từ khá lâu và cũng đã có nhiều cách phòng chống hiệu quả, nhưng những kết quả nghiên cứu của các chuyên gia trên thế giới gần đây cho thấy, kẻ xấu có thể thực hiện việc tấn công này một cách rất dễ dàng. Một số nguồn tin cho rằng chỉ cần dưới 10s là kẻ xấu có thể tấn công một máy chủ DNS chưa được sửa lỗi.

Tình trạng các máy chủ DNS ở VN

Ngay khi phát hiện ra lỗ hổng này, các chuyên gia trên thế giới đã làm việc với nhau để tìm ra các phương pháp sửa lỗi. Các hãng phần mềm đều đã có cung cấp bảng vá lỗi cho phần mềm máy chủ DNS của họ.

Tuy vậy, theo tìm hiểu của tôi, mặc dù các bảng vá đã được phát hành gần 2 tuần, nhưng tất cả các máy chủ DNS của các ISP VN như FPT, VDC, Vietel, SCTV...đều chưa được vá lỗi.

Điều này có nghĩa là tất cả những ai sử dụng dịch vụ Internet (dial-up, ADSL hay leased line) của các ISP này đều có thể bị tấn công như mô tả ở trên.

Theo thông tin từ VNCERT, Đội phản ứng nhanh về các sự cố máy tính VN, họ cũng đã có cung cấp thông tin cho các ISP từ vài tuần trước, nhưng không nhận được phản hồi. Theo tôi được biết, trong nay mai, sẽ có một thông cáo báo chí của VNCERT về vấn đề này, để yêu cầu sự hợp tác từ phía các ISP.

Giải pháp tạm thời

Giải pháp tạm thời là không sử dụng Internet nữa, cho đến khi nào có thông tin mới. Haha tôi nói đùa đó :D.

Giải pháp tạm thời là thay vì sử dụng máy chủ DNS của các ISP VN, các bạn hãy chuyển sang sử dụng máy chủ DNS của công ty OpenDNS. Các máy chủ của OpenDNS đã được vá lỗi và công ty này cũng cho biết họ đã sẵn sàng để phục vụ chúng ta.

Thông tin chi tiết về việc cấu hình máy tính sử dụng máy chủ DNS của OpenDNS, các bạn có thể xem ở đây. Nếu có khó khăn gì, cứ báo cho tôi biết, nếu tôi hỗ trợ được tôi sẽ hỗ trợ.


Thông tin tham khảo

http://www.kb.cert.org/vuls/id/800113


http://isc.sans.org/diary.html?storyid=4687

Trước khi kết thúc, tôi muốn nhấn mạnh lại lần nữa đây là một lỗ hổng cực kỳ nghiêm trọng và ảnh hưởng trực tiếp đến mỗi người trong chúng ta.

Wednesday, July 9, 2008

Patch your DNS resolver now!

See these links for details:

http://www.kb.cert.org/vuls/id/800113

http://isc.sans.org/diary.html?storyid=4687

Tuesday, July 1, 2008

loss vs gain

(entry được viết trong một đêm mưa gió bão bùng, sau khi khổ chủ đã bị rớt ví và mất hết tiền trong đó )

Nếu xem x là đơn vị đo cảm xúc của con người, cộng thêm x nghĩa là vui hơn, trừ đi x nghĩa là buồn hơn, thì mất một số tiền bao giờ cũng trừ nhiều x hơn số x được cộng khi tự nhiên được đúng số tiền đó.

Các nhà tâm lý học thấy rằng, với cùng một số tiền, nếu rớt mất, người ta sẽ buồn gấp 2 đến 2.5 lần niềm vui mà họ có được, nếu họ nhặt được số tiền đó. Nói cách khác, nếu làm rớt 10 triệu, thì để bù lại nỗi đau này, người ta phải lượm được 20-25 triệu.

Thực tế cũng cho thấy, đối với một người, việc làm ra được 1 tỉ sẽ hạnh phúc hơn rất nhiều so với làm ra 10 tỉ, rồi thua lỗ 9 tỉ, mặc dù tài sản cuối cùng của hai trường hợp là như nhau. Bởi lẽ cái hạnh phúc làm ra 9 tỉ chẳng thể bù lại được cho cái cảm giác đau đớn bị thua lỗ 9 tỉ.

Điều này cũng giải thích tại sao trong các trò đỏ đen, người thua bao giờ cũng *máu me* hơn người thắng. Người thua thường có xu hướng ngày càng đặt cược với số tiền lớn hơn số tiền trước đó, bởi lẽ họ muốn gỡ lại số tiền đã thua, vốn được họ đánh giá cao hơn giá trị thật của nó. Ngược lại, người thắng có xu hướng ngày càng đặt ít hơn, bởi lẽ họ không muốn mất đi số tiền đã thắng, vốn được họ đánh giá thấp hơn giá trị thật của nó.

Tâm lý này của con người được thể hiện khá rõ trong các thí nghiệm nổi tiếng của prospect theory.

Ví dụ như trong một thí nghiệm, các sinh viên được chia làm 2 nhóm. Một nhóm được chọn một trong hai lựa chọn:

* A: chắc chắn được 5 triệu

* B: 50% được 10 triệu, 50% không được đồng nào

Nhóm còn lại được chọn một trong hai lựa chọn:

* C: chắc chắn mất 5 triệu

* D: 50% mất 10 triệu, 50% không mất đồng nào

Nếu nhìn ở góc độ xác suất (và ở góc độ của kinh tế học cổ điển), thì hai lựa chọn A và B là như nhau, bởi cả hai đều có expected utility là +$500. Tương tự cho C và D, cả hai đều có expected utility là -$500. Nghĩa là theo lý thuyết, số người chọn A và C sẽ ngang bằng với số người chọn B và D.

Thật tế kết quả thí nghiệm cho thấy, khi đối diện với gain, hầu hết mọi người (84%) đều chọn A (sure gain) hơn là chọn B (risky larger gain). Nhưng khi đối diện với loss, hầu hết mọi người (70%) lại chọn D (risky larger loss) hơn là chọn C (sure loss).

Quay lại cái sòng bạc ở trên. Đối với người thua, họ đang có một cái sure loss (là số tiền đã thua), họ không muốn chọn giải pháp này, nên họ đặt cược thêm (nghĩa là chọn risky larger loss), chấp nhận sự thật là họ có thể thua thêm, để hi vọng là không bị thua gì hết. Đối với người thắng, họ đang có một cái sure gain (là số tiền họ đã thắng), họ muốn giữ nguyên tình trạng này, nên họ đặt cược ít đi, hay thậm chí là không đặt cược nữa (nghĩa là không chọn risky larger gain).

Tóm lại, người ta có xu hướng tránh rủi ro (risk averse) khi đối diện với gain, và chấp nhận rủi ro (risk seeking) khi đối diện với loss. Đây là hai cái heuristic đã chế ngự bộ não của con người trong quá trình tiến hóa.

Mục đích tối thượng của bất kỳ loài sinh vật nào, kể cả con người, là tồn tại để sinh sản và duy trì nồi giống. Nếu xem các chương trình thiên nhiên hoang dã, thể nào bạn cũng sẽ thấy cảnh một bầy sư tử rượt đuổi một đám bò nai dê ngựa chạy loạn xạ xì ngầu. Đám sư tử luôn chọn những con yếu, nhỏ nhất trong đàn mà rượt, mặc dù chắc chắn những con to khỏe hơn sẽ có nhiều dinh dưỡng hơn. Đơn giản vì chúng thích "smaller gain" hơn là "risky larger gain".

Ngược lại, bầy bò nai dê ngựa biết thể nào đi ra khu vực đó ăn cỏ hay uống nước thì cũng sẽ bị sư tử rượt, nhưng chúng vẫn làm, bất kể xung quanh toàn sư tử. Như đã nói ở trên, mục tiêu tối thượng của đám sinh vật này là tồn tại, là có cái ăn, là không bị chết đói, nên chúng sẵn sàng chấp nhận một cái risky larger loss (là bị sư tử ăn thịt), để hi vọng không bị mất gì cả (là được ăn, được uống mỗi ngày).

Đối với con người, hai cái heuristic này mạnh đến nỗi chúng dẫn đến các kết quả thí nghiệm trái với logic. Thí nghiệm nổi tiếng mang tên "dịch bệnh Châu Á" đã cho thấy điều này. Trong thí nghiệm này, các sinh viên được yêu cầu tưởng tượng rằng có một dịch bệnh có khả năng sẽ giết chết 600 người, rồi chọn một trong hai giải pháp để xử lý dịch bệnh này. Tiếp theo, tương tự như trên, các sinh viên được chia làm hai nhóm. Nhóm thứ nhất phải chọn một trong hai giải pháp:

* A: 200 người sẽ được cứu.

* B: 1/3 xác suất sẽ cứu được cả 600 người và 2/3 xác suất sẽ không cứu được ai cả.

Nhóm thứ hai phải chọn một trong hai giải pháp:

* C: 400 người sẽ chết.

* D: 1/3 xác suất sẽ không có ai chết, và 2/3 xác suất tất cả 600 người sẽ chết.

Như thí nghiệm ở trên, A và B có cùng expected utility là +200 người, còn expected utility của C và D là -400 người. Nhưng nếu bạn nhìn kỹ, bạn sẽ thấy thật ra A chính là C, còn B chính là D. Chúng chỉ khác nhau ở cách diễn đạt, A và B diễn đạt theo hình thức cứu được (gain), còn C và D diễn đạt theo hình thức chết chóc (loss).

Nhưng kỳ thực, hầu hết mọi người (72%) chọn A hơn là chọn B, và đồng thời hầu hết mọi người (78%) lại chọn D hơn là chọn C. Nghĩa là, trong cùng một tình huống, con người ta sẽ có những chọn lựa rất khác nhau tùy theo cách diễn đạt tình huống đó là gain hay loss.

Các nhà tâm lý học và kinh tế học hành vi gọi đây là framing effect: nếu các lựa chọn được diễn giải theo hình thức gain, con người ta sẽ có xu hướng tránh rủi ro (risk averse); ngược lại, nếu các lựa chọn được diễn giải theo hình thức loss, con người ta sẽ có xu hướng chấp nhận rủi ro (risk seeking).

Một cách giải thích khác cho những kết quả trái logic này là con người ta có xu hướng đánh giá cao những thay đổi gần với trạng thái hiện tại của họ hơn là những thay đổi cách xa trạng thái hiện tại của họ.

Quay lại với thí nghiệm đầu tiên. Trong cặp lựa chọn thứ nhất, cái gain từ 0 đồng lên 5 triệu giá trị hơn cái gain từ 5 triệu lên 10 triệu, nên không có lý gì người ta mạo hiểm đánh đổi 5 triệu đầu tiên để lấy được 5 triệu thứ hai. Tương tự như thế, trong cặp lựa chọn thứ hai, mất 5 triệu đầu tiên, từ 0 đồng xuống -5 triệu, được đánh giá là mất nhiều hơn 5 triệu thứ hai, từ -5 triệu xuống -10 triệu, nên sẽ là hợp lý nếu người ta chấp nhận mất 10 triệu để không phải bị mất 5 triệu.

Tâm lý này cũng giải thích tại sao một số người, khi tham gia đầu tư kinh doanh trên thị trường chứng khoán hay vàng hay bất động sản, thường có hai hành động: bán ra các tài sản đang tăng giá và ôm các tài sản đang tuột giá.

Khi bán ra tài sản đang tăng giá, nghĩa là họ muốn chốt lời, mặc dù cái lời (gain) này chỉ là cái smaller gain, so với một cái risky larger gain có thể đạt được, nếu họ giữ tài sản thêm một thời gian nữa.

Khi ôm tài sản đang tuột giá, nghĩa là họ không muốn cắt lỗ, họ không muốn chấp nhận cái sự thật là họ đang thua lỗ, nên họ ôm tài sản thêm một thời gian, chấp nhận có thể phải hứng chịu một cái risky larger loss, để không phải thua lỗ gì cả.

Sự thật là có rất nhiều người không xem sự thua lỗ trên giấy tờ có giá trị ngang với thua lỗ bằng tiền tươi thóc thật. Có bao nhiêu người vẫn khư khư giữ các cổ phiếu đã mua khi VnIndex ở mức 800, 900 hay 1000 cho đến tận bây giờ? Tôi nghĩ là rất nhiều. Đối với họ, trên giấy tờ, trong tâm tưởng của họ, các cổ phiếu này vẫn có giá trị như lúc VnINDEX ở mức 800, 900 hay 1000, họ không muốn chấp nhận cái sự thật, kèm theo cảm giác đau đớn, khi phải bán chúng ra với giá rẻ như bèo.

Đừng nghĩ những người hành động như thế là ngu nhen, trời ơi, mất tiền đau đớn lắm :((, chẳng ai muốn trải nghiệm cái cảm giác đó đâu.

Bài học rút ra từ entry này: không bao giờ để ví tiền trong cốp xe.