Đọc hay không đọc: ấy mới là vấn đề

Lý Lan

Tựa bài này hiển nhiên nhái theo câu văn trích trong vở kịch Hamlet của Shakespeare: “To be or not to be, that is the question.” Động từ to be của tiếng Anh giống như chữ “Đạo” của Lão Tử, giải nghĩa thì không còn nghĩa nữa. Chẳng hạn nói “to be rich” có thể dịch “để giàu”, nói “to be alone” có thể hiểu “một mình”, còn “to be myself” có nghĩa “là chính tôi”.

Nguyên câu trích trên nếu dịch “là hay không là, đó là câu hỏi” nghe nôm na cạn nghĩa, giống như câu do máy dịch tự động của Google: “được hay không được, đó là câu hỏi”. Có người dịch “tồn tại hay không tồn tại, đó mới là vấn đề”, nghe có vẻ cao siêu, bác học. Càng cao siêu hơn khi người ta thay vế trước với những từ “hiện hữu hay không hiện hữu”, “hữu hay vô”, “hiện sinh hay phi hiện sinh”, “đạo hay bất đạo”,… Trải mấy trăm năm, câu tiếng Anh được trích nhiều nhất thế giới ấy, cũng bị nhái nhiều vô kể. “Yêu hay không yêu, đó mới là câu hỏi.” “Sống hay chết, đó mới là vấn đề.” Đại khái vậy. Khi người ta phân vân lưỡng lự như Hamlet.

Đọc hay không đọc? Đó không phải là câu hỏi khi tôi còn trẻ. Trong ngôn ngữ của cha tôi, đọc sách đồng nghĩa với học, là hành động hay ho nhất của con người, đặc biệt cần thiết nếu muốn làm người tử tế tốt đẹp, vì “kẻ sĩ ba ngày không đọc sách, soi gương mặt mũi khó coi”. Vì vậy mỗi lần thấy tôi cầm sách nhìn vào thì cha tôi để tôi yên, dù ông định rầy rà hay muốn sai bảo tôi làm gì đó. Tôi biết tận dụng điều đó, lúc nào cũng kè kè cuốn sách để trốn việc, đôi khi trốn cả thực tế. Từ tuổi nhỏ tôi thấy cái lợi trước mắt của việc đọc sách, rồi đinh ninh đến lớn là đọc sách có lợi, không bổ bề ngang cũng bổ bề dọc, không học được điều hay thì cũng trốn được việc nặng. Công bằng mà nói, giả bộ đọc riết rồi cũng đọc hiểu được chút đỉnh, gặp sách hay đọc cũng thích thú, đọc say sưa rồi thành thói quen đọc thực.

Nhớ ông Sơn Nam. Khi gặp ông lần đầu tôi còn là một sinh viên, đầy lòng ngưỡng mộ các bậc văn nhân lão thành, và rất hăm hở bộc lộ mình như một tài năng trẻ có triển vọng. Nên khi trò chuyện với ông tôi nói mình đã đọc sách này báo nọ, và mong ông có lời khuyên về việc đọc. Ông bảo “Bây giờ không nên đọc gì nữa, để giữ vệ sinh tinh thần.” Tôi đã phân vân lúc đó và ngẫm đi nghĩ lại câu hỏi ấy nhiều năm, đọc hay không đọc. Khi quen biết ông Sơn Nam nhiều hơn, tôi khẳng định điều mình nghi ngờ: Ông nói vậy, nhưng ông đọc rất nhiều. Cho đến tận lúc trên tám mươi tuổi, nằm liệt trên giường bệnh, ông vẫn đọc mỗi ngày, có thể như một thói quen, hay một nhu cầu. Chẳng lẽ ông là người già mà xúi dại người trẻ? Hay ông biết tỏng mấy đứa trẻ và hãnh tiến có xu hướng làm ngược lại hay làm quá đi lời khuyên của người già, nên “nói vậy mà không phải vậy”?

Nhưng đến giờ thì tôi ngẫm ra: ông nói vậy và ngụ ý đúng như vậy. Có những thời mà thông tin bị nhiễu đến nỗi, đối với những người chưa nhiều kinh nghiệm đọc, chưa đủ bản lĩnh phê phán gạn lọc, đọc ít tốt hơn đọc nhiều, đừng đọc còn tốt hơn đọc. Và “kỷ nguyên thông tin” chúng ta đang sống là một thời như vậy. Thì còn phân vân lưỡng lự gì nữa? Đừng đọc quách cho lành. Những gã sáng say chiều xỉn tối đánh bạc nhan nhản từ nông thôn đến thành thị đã bắt con bỏ học đi bán vé số chẳng hóa ra là những người sáng suốt thức thời? Cái khó là thông tin ngày nay không chỉ được truyền bằng chữ, mà còn bằng hình ảnh âm thanh sống động hấp dẫn. Người ta dầu bưng tai bịt mắt mà sống giữa đời này cũng không thể gạt bỏ hoàn toàn ảnh hưởng của các loại truyền thông, nhất là những thứ tuyên truyền hay quảng cáo thương mại trá hình gọi là PR chẳng hạn. Đọc hay không đọc đều có thể bị ô nhiễm tinh thần.

Phương tiện nghe nhìn ngày nay nhờ hỗ trợ của kỹ thuật tác động sâu và rộng hơn chữ nghĩa, mức độ gây ô nhiễm văn hóa đối với xã hội lớn hơn sách báo đơn thuần. Khổ một cái là “môi trường văn hóa” ở xứ phát triển và đang hăm hở phát triển hầu như được định dạng bằng các phương tiện truyền thông, chủ yếu bằng nghe nhìn. Một xã hội càng kém thông tin càng bị coi là tụt hậu, người thiếu thông tin dễ bị o ép, lợi dụng, bóc lột. Nên Nhà nước nào cũng phải dạy dân biết chữ để đọc và biết sử dụng các phương tiện truyền thông khác để gạn lọc thông tin, tích lũy tri thức, hình thành quan điểm, biết phê phán hay sử dụng cái mình đọc, nghe, nhìn. Thông tin ngày nay là hàng hóa, có thật có giả, và đủ loại chất lượng. Thông tin cũng là cơ hội, thậm chí là tư bản, và còn là vũ khí. Xông pha trong trận mạc thương trường, chính trị, khoa học, nghệ thuật, người không có vũ khí hay vũ khí kém, vũ khí dỏm, thì hậu quả chỉ có từ chết tới bị thương.

Vậy chẳng phải là cần đọc, nghe, nhìn càng nhiều càng tốt? Tôi vẫn còn đầy nghi vấn như Hamlet. Sản phẩm văn hóa cũng giống thực phẩm bây giờ, tiềm ẩn đủ thứ chất độc hại, thức ăn càng có vẻ ngon lành bổ dưỡng, quảng bá rầm rộ, càng chứa nhiều nguy cơ đối với sức khỏe. Nhưng chẳng lẽ không ăn? Mà không lẽ chỉ ăn gạo lức muối mè? Ăn cái gì, như thế nào, đến mức độ nào, là câu trả lời riêng của mỗi người. Chứ ăn hay không ăn, đó không phải là câu hỏi.

Đọc hay không đọc, ấy mới là câu hỏi. Trong xã hội nước ta ngày nay, chắc không khó cho mỗi người tìm thấy quanh mình tấm gương của kẻ “thành đạt” (nổi tiếng, giàu có) mà không đọc. Nhưng sao trong xã hội người ta (Nhật, Mỹ, Âu, Úc, Ấn, Hoa) những người có ảnh hưởng (không chỉ trong cộng đồng của họ, mà với cả thế giới, và có thể vượt ra ngoài Trái đất) đều làm sách?

 

Nguồn: http://tiasang.com.vn/Default.aspx?tabid=115&CategoryID=41&News=4305

Xin cám ơn!

Understanding Man-In-The-Middle Attacks - Part 4: SSL Hijacking

Introduction

So far we have discussed ARP cache poisoning, DNS spoofing, and session hijacking on our tour of common man-in-the-middle attacks. In this article we are going to examine SSL spoofing, which is inherently one of the most potent MITM attacks because it allows for exploitation of services that people assume to be secure. I will begin by discussing some theory behind SSL connections and what makes them secure, and then follow by showing how that can be exploited. As always, the last section of the article is reserved for detection and prevention tips.

SSL and HTTPS

Secure Socket Layers (SSL), or Transport Layer Security (TLS) in its more modern implementation, are protocols designed to provide security for network communication by means of encryption. This protocol is most commonly associated with other protocols to provide a secure implementation of the service that protocol provides. Examples of this include SMTPS, IMAPS, and most commonly HTTPS. The ultimate goal is to create secure channels over insecure networks.

In this article we will focus on attacking SSL over HTTP, known as HTTPS, because it is the most common use of SSL. You may not realize it but you probably use HTTPS daily. Most popular e-mail services and online banking applications rely on HTTPS to ensure that communications between your web browser and their servers in encrypted. If it weren’t for this technology then anybody with a packet sniffer on your network could intercept usernames, passwords, and anything else that would normally be hidden.

The process used by HTTPS to ensure data is secure centers around the distribution of certificates between the server, the client, and a trusted third party. As an example let’s say that a user is trying to connect to a Gmail e-mail account. This involves a few distinct steps, which are briefly simplified in Figure 1.

                                      Figure 1: The HTTPS Communication Process

The process outlined in Figure 1 is by no means detailed, but basically works out as follows:
    1. The client browser connects to http://mail.google.com on port 80 using HTTP.

    2. The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.

    3. The client connects to https://mail.google.com on port 443.

    4. The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.

    5. The client takes this certificate and verifies it against its list of trusted certificate authorities.

    6. Encrypted communication ensues.

If the certificate validation process fails then that means the website has failed to verify its identity. At that point the user is typically presented with a certificate validation error and they can choose to proceed at their own risk, because they may or may not actually be communicating with the website they think they are talking to.

Defeating HTTPS

This process was considered highly secure up until several years ago when an attack was published that allowed for successful hijacking of the communication process. This process doesn’t involve defeating SSL itself, but rather, defeating the “bridge” between non-encrypted and encrypted communications.

Moxie Marlinspike, a well known security researcher hypothesized that in most cases, SSL is never encountered directly. That is, most of the time an SSL connection is initiated through HTTPS it is because someone was redirected to an HTTPS via an HTTP 302 response code or they click on a link that directs them to an HTTPS site, such as a login button. The idea is that if you attack the transition from an unsecured connection to a secure one, in this case from HTTP to HTTPS, you are attacking the bridge and can man-in-the-middle an SSL connection before it even occurs. In order to do this effectively, Moxie created the SSLstrip tool, which we will use here.

The process is fairly straightforward and is reminiscent of some of the attacks we’ve completed in previous articles. It is outlined in Figure 2.

                                     Figure 2: Hijacking HTTPS Communication

The process outlined in Figure 2 works like this:

1. Traffic between the client and web server is intercepted.

2. When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a mapping of the changes.

3. The attacking machine supplies certificates to the web server and impersonates the client.

4. Traffic is received back from the secure website and provided back to the client.

The process works quite well and as far as the server is concerned it is still receiving the SSL traffic it wants to, it doesn’t know the difference. The only visible difference in the user experience is that the traffic will not be flagged as HTTPS in the browser, so a cognizant user will be able to notice that something is amiss.

Using SSLStrip

The program that makes all of this happen is called SSLstrip and is available from here. This program only runs on Linux so you can download and install it yourself, or if you don’t want to deal with the hassle of installing it yourself you can download and run Backtrack 4 which has it preinstalled.

Once you have access to SSLstrip there are a few perquisite tasks that must be done. First of all, the Linux distribution you are using must be configured for IP forwarding. To do this, enter the command echo "1" > /proc/sys/net/ipv4/ip_forward into a shell.

                              Figure 3: Enabling IP Forwarding

Once this has been done, we have to force all HTTP traffic that is intercepted to be routed to the port that SSLstrip will be listening on. This is done by modifying the iptables firewall configuration. This is done by using the command iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port .

                      Figure 4: Configuring IPTables to properly route HTTP traffic

Of course, you will replace with a random port of your choice. After these items have been configured we can run sslstrip and configure it to listen on the port specified with the command sslstrip -l .

                                              Figure 5: Using sslstrip

The last step in this process is to configure ARP spoofing to intercept the traffic of the target host. We did this using Cain and Abel in Windows previously, but in this case we will use the arpspoof utility, which is built into Backtrack 4. The command to do this is arpspoof -i -t .

                                           Figure 6: Configuring ARP Spoofing

Using this command you would substitute for the network interface you are performing these actions on (eth0, eth1, etc), for the IP address of the target client, and for the IP address of the gateway router the target is using.

Once completed you should be actively hijacking any SSL connections being established. From here you can fire up a packet sniffer and collect passwords, personally identifiable information, credit card numbers, etc from the traffic.

Defending Against SSL Hijacking

As discussed previously, SSL hijacking in this manner is virtually undetectable from there server side of the equation because as far as the server is concerned this is just normal communication with a client. It has no idea that it is communicating to a client by proxy. Luckily, there are a few things that can be done from the client’s perspective to detect and prevent these types of attacks.

* Ensure Secure Connections Use HTTPS - When you perform the attack described here it strips the secure aspect of the connection away, which is visible in the browser. This means that if you log into your online banking and notice that it is just a standard HTTP connection there is a good chance something is wrong. Whatever browser you choose to use, you should ensure you know how to distinguish secure connections from insecure ones.

* Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.

* Secure your internal machines - Not to beat a dead horse, but once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.


 Source: http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part4.html
thanks!!

Understanding Man-In-The-Middle Attacks - Part 3: Session Hijacking

Introduction

In the first two articles of this series on man-in-the-middle attacks we examined ARP cache poisoning and DNS spoofing. As we have demonstrated with those examples, MITM attacks are incredibly effective and increasingly hard to detect. In the third part of this article we will examine session hijacking, which is no different. As with the previous two articles I will describe the theory behind session hijacking, demonstrate the technique in practice, and discuss detection and prevention tips.

Session Hijacking

The term session hijacking is thrown around frequently and encompasses a variety of different attacks. In general, any attack that involves the exploitation of a session between devices is session hijacking. When we refer to a session, we are talking about a connection between devices in which there is state. That is, there is an established dialogue in which a connection has been formally set up, the connection is maintained, and a defined process must be used to terminate the connection. When we talk about sessions theoretically it’s a bit confusing, so it may help to think of a session in a more practical sense.

In this article we will be talking about session hijacking through cookie stealing, which involves HTTP sessions. If you think about some of the common websites you visit that require login credentials, those are great examples of session-oriented connections. You must be authenticated by the website with your username and password to formally set up the session, the website maintains some form of session tracking to ensure you are still logged in and are allowed to access resources (often done with a cookie), and when the session is ending the credentials are cleared and the session ends. This is a very specific example of a session and even though we do not always realize it, sessions are occurring constantly and most communications rely on some form of session or state-based activity.

                                              Figure 1: A normal session

As we have seen in previous attacks, nothing that goes across the network is safe and session data is no different. The principle behind most forms of session hijacking is that if you can intercept certain portions of the session establishment, you can use that data to impersonate one of the parties involved in the communication so that you may access session information. In the case of our earlier example, this means that if we were to capture the cookie that is used to maintain the session state between your browser and the website you are logging into, we could present that cookie to the web server and impersonate your connection. If that sounds too good to be true from an attackers standpoint, well….it is.

                                  Figure 2: Session Hijacking

Now that we have a little bit of theory in the books, let us delve into a practical example.

Stealing Cookies with Hamster and Ferret

In our practical scenario we will be performing a session hijacking attack by intercepting the communication of a user logging into his Gmail account. Using this intercepted communication we will impersonate that user and access the account from our attacking machine.

In order to perform this attack we will be using two tools straight out of the pet store, named Hamster and Ferret. Both tools can be downloaded from here. These are both command-line tools so the hamster folder can be extracted to an easy to get to location.

Alternatively, you can download and use Backtrack 4. BT4 is a Linux live-CD distribution designed specifically for hacking and penetration testing that comes with a myriad of preinstalled and precompiled tools, with Hamster/Ferret being two of them. You can download BT4 from here. You will then find Hamster in the /pentest/sniffers/hamster folder. The screenshot examples used in the rest of this tutorial are taken from BT4.

The first step involved in this form of session hijacking is to capture the traffic of the victim user as he browses Facebook. This traffic can actually be captured using any packet sniffing application such as TCPDump or Wireshark, but in order to capture the right packets you will need to employ a technique such as ARP cache poisoning (discussed in the first article in this series).

               Figure 3: Capturing traffic of the user browsing to Gmail

Once you have captured the traffic of the victim user browsing to Gmail you will need to save the captured file into the Hamster directory. For the purposes of this example, we have named our file victim_gmail.pcap. When that file is in place, we will use Ferret to process the file. This is done by browsing to the Hamster folder and running the command, ferret –r victim_gmail.pcap. Ferret will process the file and create a hamster.txt file that may be used by Hamster for the actual hijacking of the session.

                               Figure 4: Processing the capture file with Ferret

With our HTTP data intercepted and prepared for use, we can use Hamster to actually execute the attack. Hamster itself actually runs as a proxy that provides an interface for browsing and using stolen session cookies. In order to start the Hamster proxy you can simply execute Hamster with no command line options.

                                  Figure 5: Starting Hamster

Once executed, you will need to open your browser and configure its proxy settings to match those provided to you by the Hamster output. By default, this means that you would configure your proxy settings to use the local loopback address 127.0.0.1 on port 1234. You can access these settings in Internet Explorer by selecting Tools, Internet Options, Connections, LAN Settings, and placing a checkbox in the Use a proxy server for your LAN box.

                Figure 6: Configuring proxy settings for use with Hamster

Now that the proxy settings have been applied you can access the Hamster console in your browser by browsing to http://hamster. Hamster will use the file created by Ferret to produce a list of IP addresses for whom session information has be intercepted and display those IP address in the right pane of the browser. Our file we’ve created only contains a single IP address of the victim, so if we click that the left pane will be populated with the sessions available for hijacking.

                                          Figure 7: The Hamster GUI

We see that facebook.com is listed, and if you click that link you will be pleased to be presented with a new window that has you logged in to the victims Facebook account!

                   Figure 8: Successfully hijacked Gmail account!

Defending Against Session Hijacking

There are many different forms of session hijacking so the defenses for them can vary. Just like the other MITM attacks we’ve evaluated, session hijacking is difficult to detect and even more difficult to defend against because it’s a mostly passive attack. Unless the malicious user performs some type of obvious action when he accesses the session being hijacked, you may never know that they were there. Here are a few things you can do to better defend against session hijacking:
    *  Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
   *  Be Cognizant - Smart attackers will not leave any evidence that they have been in one of your secure accounts but even the most seasoned hackers make mistakes. Being aware when you are logged into session-based services can help you determine if somebody else is walking in your shadow. Keep an eye out for things that seem out of place, and pay attention to “Last Logon Time” fields to ensure everything matches up.
   *  Secure your internal machines - Once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.

Source: http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part3.html
thanks!!