09/12/2019

New Linux Bug Lets Attackers Hijack Encrypted VPN Connections


A team of cybersecurity researchers has disclosed a new severe vulnerability affecting most Linux and Unix-like operating systems, including FreeBSD, OpenBSD, macOS, iOS, and Android, that could allow remote 'network adjacent attackers' to spy on and tamper with encrypted VPN connections.
The vulnerability, tracked as CVE-2019-14899, resides in the networking stack of various operating systems and can be exploited against both IPv4 and IPv6 TCP streams.

Since the vulnerability does not rely on the VPN technology used, the attack works against widely implemented virtual private network protocols like OpenVPN, WireGuard, IKEv2/IPSec, and more, the researchers confirmed.

This vulnerability can be exploited by a network attacker — controlling an access point or connected to the victim's network — just by sending unsolicited network packets to a targeted device and observing replies, even if they are encrypted.

As explained by the researchers, though there are variations for each of the impacted operating systems, the vulnerability allows attackers to:

  • determine the virtual IP address of a victim assigned by the VPN server,
  • determine if there is an active connection to a given website,
  • determine the exact seq and ack numbers by counting encrypted packets and/or examining their size, and
  • inject data into the TCP stream and hijack connections.

"The access point can then determine the virtual IP of the victim by sending SYN-ACK packets to the victim device across the entire virtual IP space," the team said in its advisory.

"When a SYN-ACK is sent to the correct virtual IP on the victim device, the device responds with a RST; when the SYN-ACK is sent to the incorrect virtual IP, nothing is received by the attacker."

While explaining variations in the behavior of different operating systems, as an example, researchers said the attack does not work against macOS/iOS devices as described.

Instead, an attacker needs to "use an open port on the Apple machine to determine the virtual IP address." In their testing, the researchers use "port 5223, which is used for iCloud, iMessage, FaceTime, Game Center, Photo Stream, and push notifications, etc."

The researchers tested and successfully exploited the vulnerability against the following operating systems and the init systems, but they believe this list could go long as researchers test the flaw on more systems.
  • Ubuntu 19.10 (systemd)
  • Fedora (systemd)
  • Debian 10.2 (systemd)
  • Arch 2019.05 (systemd)
  • Manjaro 18.1.1 (systemd)
  • Devuan (sysV init)
  • MX Linux 19 (Mepis+antiX)
  • Void Linux (runit)
  • Slackware 14.2 (rc.d)
  • Deepin (rc.d)
  • FreeBSD (rc.d)
  • OpenBSD (rc.d)
"Most of the Linux distributions we tested were vulnerable, especially Linux distributions that use a version of systemd pulled after November 28th of last year, which turned reverse path filtering off," the researchers said.

"However, we recently discovered that the attack also works against IPv6, so turning reverse path filtering on isn't a reasonable solution."

As possible mitigation, researchers suggested to turn on reverse path filtering, implement bogon filtering, and encrypt packet size and timing to prevent attackers from making any inference.
While the researchers have not yet revealed technical details of the vulnerability, they are planning to publish an in-depth analysis of this flaw and its related implications, after affected vendors, including Systemd, Google, Apple, OpenVPN, WireGuard, and different Linux distros issue satisfactory workarounds and patches.

Source: THN

29/10/2019

So sánh giấy phép mã nguồn mở Apache, MIT, GPL

Mã nguồn mở ngày nay đã và đang trở nên phổ biến hơn bao giờ hết, những dự án mã nguồn mở có thể được tìm thấy hầu như ở bất kì đâu trên không gian mạng rộng lớn này. Tuy nhiên dù có “mở” đi chăng nữa thì những phần mềm mã nguồn mở phải tuân theo những giấy phép nhất định. Điển hình là 3 loại giấy phép phổ biến nhất là Apache, MIT và GPL. Vậy, giữa chúng có gì khác nhau.


Trước hết, giấy phép mã nguồn mở là một loại giấy phép được sử dụng cho các phần mềm mã nguồn mở. Giấy phép này cho phép bất kì cá nhân hay tổ chức nào cũng có thể nghiên cứu, thay đổi, chỉnh sửa và cải tiến phần mềm, và phân phối ở các dạng khác nhau như thay đổi hoặc chưa thay đổi.

Giấy phép Apache
Giấy phép Apache ra đời bởi Quỹ Phần mềm Apache (Apache Software Foundation - ASF). Đây là một giấy phép phần mềm tự do, không có copyleft, bắt buộc trong việc thông báo bản quyển và lời phủ nhận. Giấy phép này hoạt động như các giấy phép phần mềm mã nguồn mở khác, trao cho người sử dụng phần mềm quyền tự do trong bất kỳ mục đích nào, từ chỉnh sửa, thay đổi, phân phối hoặc phân phối bản có sửa đổi của phần mềm theo các điều khoản đã ghi của giấy phép mà không lo lắng tới phí bản quyền.
Được phần đông người dùng đánh giá là giấy phép không có nhiều ràng buộc nên Apache là một giấy phép được sử dụng rộng rãi. Theo số liệu đã được thống kê, đến tháng 10 năm 2012, đã có đến 8708 dự án đặt tại SourceForge.net được cấp phép theo các điều khoản của Giấy phép Apache. Sự phổ biến này đã được trình bày rõ ràng trong một bài viết trên blog vào tháng 5 năm 2008, Google đã liệt kê đến hơn 25000 trong tổng số 100000 dự án đặt trên Google Code đang sử dụng giấy phép này. 

Các điều khoản giấy phép Apache
Trong mỗi tập tin được cấp phép, bất kỳ bản quyền, bằng sáng chế hay thương hiệu và thông báo ghi công phải được giữ nguyên trong các đoạn mã khi phát hành và phải thông báo các tập tin đã thay đổi trong source code.

Nếu có một tập tin NOTICE trong bản phân phối gốc thì các phiên bản sau chỉnh sửa phải kèm theo nội dung của tập tin nêu trên bên trong phần mềm, hoặc tài liệu hướng dẫn sử dụng, hoặc trong một giao diện của phiên bản hiện hành. 
Trừ khi có thông báo đặc biệt nào khác từ ASF thì bất kỳ đóng góp chỉnh sửa nào gửi cho người cấp phép đều sẽ tuân theo các điều khoản của giấy phép mà không cần thông qua bất cứ điều kiện gì nhưng vẫn giữ được sự hợp tác thỏa thuận giữa các bên trong phần đóng góp này.

Giấy phép MIT
Giấy phép MIT được tạo ra bởi Viện Công nghệ Massachusetts (MIT) danh tiếng. Là một loại giấy phép cấp phép, không có copyleft và c rất ít hạn chế trong việc sử dụng, trở thành một trong những giấy phép lý tưởng trong việc phát triển phần mềm. Sự phổ biến của giấy phép này đã được minh chứng bằng việc GitHub, trang web lưu trữ source code nổi tiếng, đã xác nhận rằng đây là giấy phép phổ biến nhất trên dịch vụ của họ, vượt xa các biến thể giấy phép GPL( sẽ đề cập sau) và các giấy phép phần mềm tự do nguồn mở (FOSS) khác. MIT đã tạo tiền để cho các dự án mà ắt hẳn bạn đã nghe qua một lần như: Ruby on Rails, Node.js, jQuery và X11 hay X.

Các điều khoản giấy phép MIT
Các điều khoản của giấy phép MIT được gói gọn rằng: "Quyền hạn sử dụng được trao cho người sử dụng với không hạn chế nào, kể cả quyền sử dụng, sao chép, chỉnh sửa, kết hợp, xuất bản, phân phối, hay phân phối dưới các dạng phiên bản sửa đổi khác nhau, và bán bản sao chép của phần mềm nhưng với điều kiện như: những file ghi về tác giả, người có công (như file NOTICE), file ghi về quyền hạn sử dụng phải được bao gồm trong các phiên bản sử dụng giấy phép này".

Giấy phép GPL
Giấy phép GPL hay còn được biết đến với cái tên GNU General Public License (GNU GPL/GPL) là một giấy phép mã nguồn mở có copyleft được sử dụng rộng rãi, đảm bảo cho người dùng khả năng chạy, nghiên cứu, tùy biển về phần mềm, là sản phẩm trí tuệ của Richard Stallman của Quỹ Phần mềm Tự do (FSF) cho dự án GNU, hỗ trợ cấp cho người nhận chương trình máy tính quyền của Định nghĩa Phần mềm Tự do.

Nhờ có copyleft mà GPL đã trở thành Giấy phép mã nguồn mở phổ biến nhất trong lĩnh vực phầm mềm tự do và nguồn mở. Các sản phẩm tiêu biểu được tạo ra theo giấy phép GPL có thể kể đến như nhân Linux và Bộ biên dịch GNU hay GCC. Nhờ giấy phép này mà nhân Linux đã có những thành công rực rỡ trên con đường phát triển của mình. 

Các điều khoản của giấy phép GPL
GNU GPL cho đến nay đã trải qua 3 phiên bản gồm 17 điều khoản như được tự do chạy chương trình dưới bất cứ mục đích nào, tự do tìm hiểu các hoạt động của chương trình và tự do thực hiện các thay đổi, chỉnh sửa lên nó và quyền truy cập mã nguồn là điều kiện bắt buộc cho quyền tự do này, tự do tái phân phối bản sao, tự do trong việc cải tiến, phát hành cải tiến ra công cộng, tạo điều kiện thuận lợi cho kỹ thuật phân tích ngược (reverse engineeing).

Kết luận
Có thể thấy rằng nhờ có các giấy phép mã nguồn mở mà ngành phần mềm đã và đang trở nên phát triển mạnh hơn bao giờ hết. Các giấy phép tuy khác nhau nhưng đều có điểm chung trong việc tạo điều kiện chỉnh sửa cho nhà phát triển, tạo cơ hội cải tiến chương trình, làm đa dạng hóa chương trình gốc, giúp từng byte, từng bit người sử dụng tương tác trở nên hoàn hảo hơn bao giờ hết.

Theo: TKT

28/10/2019

New Cache Poisoning Attack Lets Attackers Target CDN Protected Sites


A team of German cybersecurity researchers has discovered a new cache poisoning attack against web caching systems that could be used by an attacker to force a targeted website into delivering error pages to most of its visitors instead of legitimate content or resources.

The issue could affect sites running behind reverse proxy cache systems like Varnish and some widely-used Content Distribution Networks (CDNs) services, including Amazon CloudFront, Cloudflare, Fastly, Akamai, and CDN77.

In brief, a Content Distribution Network (CDN) is a geographically distributed group of servers that sit between the origin server of a website and its visitors to optimize the performance of the website.

A CDN service simply stores/caches static files—including HTML pages, JavaScript files, stylesheets, images, and videos—from the origin server and delivers them to visitors more quickly without going back to the originating server again and again.

Each of the geographically distributed CDN server, known as edge nodes, then also shares the exact copy of the cache files and serve them to visitors based on their locations.

Generally, after a defined time or when manually purged, the CDN servers refresh the cache by retrieving a new updated copy of each web page from the origin server and store them for future requests.

How Does CPDoS Attack Work Against CDNs?

Dubbed CPDoS, short for Cache Poisoned Denial of Service, the attack resides in the way intermediate CDN servers are incorrectly configured to cache web resources or pages with error responses returned by the origin server.

The CPDoS attack threatens the availability of the web resources of a website just by sending a single HTTP request containing a malformed header, according to three German academics, Hoai Viet Nguyen, Luigi Lo Iacono, and Hannes Federrath.

"The problem arises when an attacker can generate an HTTP request for a cacheable resource where the request contains inaccurate fields that are ignored by the caching system but raise an error while processed by the origin server."

Here's how the CPDoS attack works:
- A remote attacker requests a web page of a target website by sending an HTTP request containing a malformed header.
- If the intermediate CDN server doesn't have a copy of the requested resource, it will forward the request to the origin web server, which will get crash due to the malformed header.
- As a consequence, the origin server then returns an error page, which eventually gets stored by the caching server instead of the requested resource.
- Now, whenever legitimate visitors try to obtain the target resource, they will be served the cached error page instead of the original content.
- The CDN server will also spread the same error page to other edge nodes of the CDN's network as well, rendering targeted resources of the victim's website unavailable.

"It is worth noting that one simple request is sufficient to replace the genuine content in the cache by an error page. This means that such a request remains below the detection threshold of web application firewalls (WAFs) and DDoS protection means, in particular, as they scan for large amounts of irregular network traffic."

"Moreover, CPDoS can be exploited to block, e.g., patches or firmware updates distributed via caches, preventing vulnerabilities in devices and software from being fixed. Attackers can also disable important security alerts or messages on mission-critical websites such as online banking or official governmental websites."

3 Ways to Launch CPDoS Attacks

CDN Services Vulnerable to CPDoS Attacks
Researchers carried out three attacks against different combinations of web caching systems and HTTP implementations and found that Amazon's CloudFront CDN is the most vulnerable to the CPDoS attack.

"We analyze the caching behavior of error pages of fifteen web caching solutions and contrast them to the HTTP specifications. We identify one proxy cache product and five CDN services that are vulnerable to CPDoS."

The complete results of their tests are as follows:

To be noted, sites running behind some of the listed CDN services are vulnerable because of their own misconfiguration that doesn’t prevent caching servers from storing error pages, and due any weakness in the respective CDN service.

Theo: THN

23/10/2019

Website giả mạo Cổng thông tin điện tử của Bộ Công an, phát tán mã độc

Trang web có địa chỉ http://113113vn.com không thuộc hệ thống tên miền của các tổ chức Chính phủ tại Việt Nam, giả mạo Cổng thông tin điện tử của Bộ Công an.

Sáng 23-10, Công an Đà Nẵng vừa phát cảnh báo về website mạo danh http://113113vn.com, địa chỉ IP 45.76.234.141, được các đối tượng lập nên để phát tán mã độc.


Cụ thể, khi truy cập "Phần mềm giám sát an toàn" tại website mạo danh trên, người dùng có nguy cơ tải về tệp "vn.apk". Đây là tệp chứa mã độc, có thể chiếm quyền điều khiển thiết bị của người truy cập, đánh cắp toàn bộ thông tin, dữ liệu quan trọng như định vị, giám sát cuộc gọi, đọc trộm tin nhắn, kết nối internet…cũng như các dữ liệu lưu trữ trong thiết bị.

Quan sát nhanh, website được thiết kế theo giao diện cho thiết bị cầm tay, phần dưới cùng ghi địa chỉ của Công an TP Đà Nẵng (80 Lê Lợi, phường Thạch Thang, quận Hải Châu), máy chủ của website đặt tại Mỹ.

Công an Đà Nẵng khuyến cáo người dân, tổ chức không truy cập vào trang web này. Trường hợp đã tải tệp tin "vn.apk" trên thiết bị di động thì nhanh chóng gỡ bỏ, xóa tệp tin để tránh bị cài mã độc.

Theo: NLĐ

18/10/2019

Khi Cookie Hijacking + HTML Injection trở nên nguy hiểm


Hôm nay mình sẽ chỉ với các bạn cách mà mình gặp một lỗi html injection, và cách mình biến nó thành lỗi nghiêm trọng với kĩ thuật cookie hijacking.


Đôi điều về HTML Injection và Cookie Hijacking:

HTML injection là một lỗi giúp hacker có thể chèn được mã HTML vào website và thực thi đoạn mã đó trên trình duyệt của người dùng. Lỗi này có thể dẫn tới rất nhiều hệ lụy kể cả việc đánh cắp cookie.


Session Hijacking là hình thức tấn công vào phiên làm việc giữa client và server cách đánh cắp cookie của người sử dụng sau khi họ đã qua bước xác thực với máy chủ, sau đó sẽ chiếm quyền điều khiển của phiên làm việc này


Giai đoạn 1: Khám phá

Lần này mình đã thực hiện test lần lượt trên từng input ở trang người dùng. Nhận thấy rằng các đoạn input đã không được validate như mong đợi. Tuy nhiên làm sao để có thể khai thác lỗi này khi mà cần phải đăng nhập thì mới hiện ra những thông tin này?

Lần 1: Thử khai thác bằng lỗi CSRF, gửi một đoạn code để đăng nhập vào tài khoản cho victim

Ex:


Không quá khó để đoán trước kết quả, cách thực hiện này không thành công vì server đã thực hiện validate login bằng token.

Lần 2:

Cookie Hijacking! Tới cách này thì mình đã thành công vì cookie quản lí phiên đăng nhập không hề hết hạn sau khi mình bấm Logout. Cookie chỉ được xóa khi mình xóa nó bằng tay:I logged in with a test account and then I clicked "logout". Note in the screenshot below that cookies were still stored in the browser after the logout:

Cookie not expired when click logout.

Mình copy cookie bằng Edit This Cookie (edit this cookie - Chrome), sửa lại và nhanh chóng được chuyển tới trang người dùng:


Như vậy là xong! Giờ đã đến lúc khai thác lỗi HTML Injection.

Như mình đã nói ở trên, trường "customer_name" dính lỗi không validate input. Để xác thực việc này, mình đã intercept request bằng burp suite và dán 1 thẻ H1 vào ô name:


Như vậy là đã xong!

Bài viết mang tính chất tham khảo với mục đích học tập!

Chúc bạn thành công <3

Source: Medium

19/09/2019

200.000 máy chủ cài Jenkins gặp lỗi

Một lỗ hổng được phát hiện trên Jenkins, ứng dụng nguồn mở tự động hóa nhiều công đoạn phát triển phần mềm, giúp hacker chiếm quyền điều khiển máy tính.

Theo chuyên gia bảo mật người Hà Lan Francesco Soncina, thông qua lỗ hổng này, hacker sẽ chiếm được quyền điều khiển máy chủ, kiểm soát toàn bộ hệ thống thông tin của doanh nghiệp và thực hiện các hoạt động trái phép như đánh cắp thông tin, phát tán dữ liệu mật...

Hiện có hơn 200.000 máy chủ cài đặt Jenkins chứa lỗ hổng được công khai trên Internet.


Công ty An ninh mạng Việt Nam VSEC đánh giá lỗ hổng ở mức nghiêm trọng đối với hệ thống máy tính của doanh nghiệp Việt. Cụ thể, hiện nay, CI (Continuous Integration) là một trong những hệ thống phổ biến nhất tại các doanh nghiệp công nghệ Việt Nam, và 80% doanh nghiệp sử dụng hệ thống CI đều dùng Jenkins để tự động hoá trong nhiều công đoạn phát triển phần mềm và sản phẩm có nhiều người dùng như các trang thương mại điện tử, mạng xã hội, ứng dụng chat...

Lỗ hổng xuất hiện trên Git Client Plugin của Jenkins từ bản 2.8.4 trở về trước. Việc không kiểm soát giá trị đầu vào tại tham số Repository URL trong Git Client Plugin là mấu chốt giúp hacker thực thi mã lệnh trái phép trên máy chủ.

VSEC khuyến cáo các tổ chức, doanh nghiệp cập nhật bản mới nhất của Git Client Plugin. Ngoài ra, doanh nghiệp cần hạn chế công khai các hệ thống đang sử dụng trong mạng nội bộ, cấu hình Whitelist các IP được truy cập vào các hệ thống quan trọng, đồng thời cài đặt mật khẩu mạnh đối với tài khoản hệ thống kể cả tài khoản có quyền hạn thấp.

Nguồn: VnExpress

23/07/2019

Tại sao KHÔNG nên sử dụng MongoDB cho ứng dụng của bạn

Tại sao KHÔNG nên sử dụng MongoDB cho ứng dụng của bạn
Bài viết được dịch từ trang web Cloud Boost
Lời nói đầu: Tôi là một hacker và tôi đang làm việc tại CloudBoost.io. Chúng tôi làm việc với rất nhiều database NoSQL và SQL. MongoDB quả là một database tuyệt vời và bài viết này dành để nói về ở đâu và trong trường hợp nào thì bạn nên và KHÔNG nên sử dụng MongoDB và nơi nào thì MongoDB phù hợp nhất. Quan điểm của tôi có thể chưa đúng, mong nhận được thêm ý kiến phản hồi từ các bạn.
Các cơ sở dữ liệu dạng document như MongoDB thì rất tuyệt vời để lưu trữ JSON vào trong một 'collection'. Bạn có thể lưu trữ bất kỳ JSON Document nào mà bạn thích và phân loại chúng vào trong bất kỳ collection nào bạn muốn. JSON được lưu vào trong MongoDB được gọi là Binary JSON hoặc BSON và chúng cũng giống như bất kỳ JSON nào đều là schema-less. Vì vậy không giống như các cơ sở dữ liệu SQL truyền thống, bạn có thể lưu trữ bất cứ thứ gì bạn thích trong bất kỳ collection nào mà bạn muốn - Vâng, chính cái điểm tự do đó kết hợp với khả năng mở rộng theo chiều ngang của MongoDB là điều khiến cho các nhà phát triển hào hứng sử dụng nó. Điều này nghe thật tuyệt! Oh, nhưng đợi đã...
Cơ sở dữ liệu MongoDB rất tuyệt vời, nhưng không phải trong trường hợp nào nó cũng mang lại hiệu quả.
Cơ sở dữ liệu MongoDB rất tuyệt vời, nhưng không phải trong trường hợp nào nó cũng mang lại hiệu quả.

Tại sao không sử dụng nó nếu nó là một cơ sở dữ liệu "tuyệt vời"

Cơ sở dữ liệu mà bạn dùng cho ứng dụng của mình phụ thuộc vào kiểu ứng dụng mà bạn đang xây dựng. Bạn không phải là người chọn cơ sở dữ liệu, mà ứng dụng của bạn mới quyết định việc đó. Sau đây tôi sẽ đưa ra một số ví dụ:
Nếu bạn đang xây dựng một ứng dụng chứa dữ liệu có khái niệm giống như "documents" thì MongoDB là một sự lựa chọn tốt. Ví dụ, nếu bạn đang xây dựng một blog engine, trong đó mỗi tác giả có nhiều blog và mỗi blog có nhiều comment, và nếu bạn nghĩ blog engine của mình sẽ mở rộng để chứa được HÀNG TẤN blog thì vâng, MongoDB là một sự lựa chọn rất tốt.
MongoDB không có mối quan hệ giữa các document và collection (Bạn có thể có một Database Reference, nhưng chúng thì không đủ).
Hãy thử suy nghĩ về document như là một "document" thực sự, bạn có những mẩu dữ liệu mà chúng không liên kết với bất kỳ dữ liệu nào khác và không có cách nào có thể làm một phép join dễ dàng như bạn thường làm trong SQL.
Vâng, nếu không có mối quan hệ nào và bạn không thể join các table - thì tại sao người ta lại lao đầu vào sử dụng nó? Bởi vì nó có ưu điểm là khả năng mở rộng cực lớn và có một độ trễ bé trong việc đọc/ghi khi so sánh với SQL. Đối với những ứng dụng mà dữ liệu phần lớn là không có mối liên hệ và cần khả năng mở rộng thì MongoDB là một sự lựa chọn hoàn hảo. Hầu hết các lập trình viên cũng sử dụng MongoDB để lưu trữ dữ liệu quan hệ và thực hiện phép join thủ công trong code của họ, điều này có thể hoạt động tốt trong một số trường hợp nào đó chỉ có join một cấp (one level join) / và có ít mối liên quan giữa dữ liệu nhưng không phải trường hợp nào cũng sử dụng được.

Tôi nên sử dụng cơ sở dữ liệu nào?

Có rất nhiều kiểu cơ sở dữ liệu ở ngoài kia, và mỗi cơ sở dữ liệu phù hợp cho một tập các yêu cầu xác định mà bạn có trong ứng dụng của mình. Một số loại cơ sở dữ liệu phổ biến là:
Document Databases (ví dụ: MongoDB): Các cơ sở dữ liệu dạng document thường được sử dụng để lưu trữ các JSON document trong các collection và truy vấn các trường liên quan. Bạn có thể sử dụng cơ sở dữ liệu này để xây dựng các ứng dụng không có quá nhiều mối quan hệ giữa các document. Một ví dụ tốt của dạng ứng dụng này là - Blog Engine / Nếu bạn muốn lưu trữ một danh mục sản phẩm.
Graph Databases (ví dụ: Neo4j): Các cơ sở dữ liệu dạng đồ thị (graph) thường được sử dụng để lưu trữ mối quan hệ giữa các thực thể, trong đó các node là các thực thể và cạnh nối là mối quan hệ giữa chúng. Ví dụ: nếu bạn đang xây dựng một mạng xã hội và nếu Người A follow Người B. Thì Người A và Người B có thể là các node và "follow" là cạnh nối giữa chúng. Đồ thị (graph) là cách tuyệt vời để làm công việc join giữa các node thậm chí trong trường hợp chiều sâu của liên kết đến 100 cấp.
Cache (ví dụ: Redis): Cache thường được sử dụng khi bạn cần truy cập cực nhanh đến dữ liệu của mình. Ví dụ, nếu bạn đang xây dựng một ứng dụng thương mại điện tử. Bạn có các danh mục sản phẩm phải load trên mỗi sự kiện page load. Thay vì việc cứ phải truy cập cơ sở dữ liệu cho mỗi hoạt động đọc đó (cho mỗi lần page load) thường tốn nhiều thời gian, bạn có thể lưu trữ nó trong cache sẽ giúp cho công việc đọc/ghi có tốc độ cực nhanh. Cache giống như Redis sẽ là một bộ đệm cho cơ sở dữ liệu của bạn phục vụ cho những truy xuất dữ liệu thường xuyên. Bạn có thể lưu trữ dữ liệu trong cache và không phải truy xuất cơ sở dữ liệu trong toàn bộ quá trình.
Search Databases (ví dụ: ElasticSearch): Nếu bạn muốn thực hiện một full text search trên dữ liệu của mình (ví dụ: các sản phẩm trong một ứng dụng thương mại điện tử) thì bạn cần một search database như ElasticSearch, nó có thể giúp bạn thực thi việc tìm kiếm trên một lượng dữ liệu lớn và mang lại cho bạn một tập các đặc trưng thú vị.
Row Store (ví dụ: Cassandra): Cassandra thường được sử dụng để lưu trữ dạng dữ liệu theo thời gian như các phân tích / logs/ dữ liệu số lượng lớn được thu về từ các bộ cảm biến sensor. Nếu bạn có một dạng ứng dụng kiểu đó mà có số lượng dữ liệu cần ghi rất lớn và ít phải đọc và dữ liệu là không có mối quan hệ (non-relational) thì Cassandra là một cơ sở dữ liệu mà bạn nên quan tâm tới.

Sử dụng nhiều cơ sở dữ liệu cùng lúc có được không?

Ngày nay nếu bạn đang xây dựng một ứng dụng, thì có thể cần phải sử dụng 2 hoặc nhiều cơ sở dữ liệu cùng một lúc. Ví dụ, nếu ứng dụng của bạn làm công việc search thì bạn có thể phải sử dụng ElasticSearch, cho việc lưu trữ dữ liệu không có quan hệ thì MongoDB là lựa chọn tốt nhất, và nếu bạn đang xây dựng một IoT (Internet of Things) có rất nhiều bộ cảm biến trả về hàng tấn dữ liệu thì tại sao lại không sử dụng Cassandra. Việc sử dụng nhiều cơ sở dữ liệu để xây dựng một ứng dụng được gọi là "Polyglot Persistence", tôi đã viết một bài blog nói về ưu và nhược điểm của việc sử dụng nhiều cơ sở dữ liệu. Bạn hãy thử đọc bài viết đó và để lại bình luận nếu bạn cảm thấy thú vị nhé!

05/04/2019

Hacker có thể biến ứng dụng chống virus được cài đặt sẵn trên điện thoại Xiaomi thành phần mềm độc hại

Hôm thứ Năm vừa qua, các nhà nghiên cứu bảo mật của Check Point đã phát hiện ra một lỗ hổng trên các điện thoại Xiaomi xuất phát từ một ứng dụng được cài đặt sẵn tên là Guard Provider.

Ứng dụng này là một tính năng bảo mật, với 3 chương trình antivirus được tích hợp bên trong nhằm phát hiện malware trong máy. Các chương trình antivirus này được phát triển bởi Avast, AVL và Tencent.

Nhưng trớ trêu thay, một tính năng bảo mật lại vô tình mở ra một lỗ hổng bảo mật. 

Guard Provider nhận cập nhật thông qua một kết nối HTTP không an toàn. Có nghĩa là nếu một hacker đang dùng cùng mạng Wi-Fi với nạn nhân, hắn có thể chèn malware vào các bản cập nhật thông qua phương thức tấn công gọi là "man-in-the-middle" - tức tạo ra một mạng Wi-Fi giả trông y hệt như mạng Wi-Fi bạn đã kết nối với và đánh lừa thiết bị của nạn nhân chuyển kết nối sang mạng Wi-Fi giả đó.

Check Point nói rằng họ đã thông báo về lỗ hổng này cho Xiaomi, và hãng điện thoại cũng đã tung ra một bản vá nhằm khắc phục lỗi.

"Xiaomi biết lỗi này và đã hợp tác với đối tác Avast để khắc phục nó" - một người phát ngôn của Xiaomi nói.

Điện thoại Xiaomi là một trong những thiết bị di động phổ biến nhất tại Trung Quốc, và công ty này thậm chí còn đang phát triển các mẫu điện thoại màn hình gập và điện thoại chơi game cao cấp của riêng mình. Xiaomi cũng là công ty có số thiết bị di động bán ra đứng thứ 4 trên thế giới; hãng cho biết đã bán khoảng 118,7 triệu điện thoại trong năm 2018.

Ngăn chặn các lỗ hổng trên điện thoại là một việc khá khó khăn, khi người dùng phải luôn thận trọng cân nhắc trước hàng trăm ngàn ứng dụng độc hại xuất hiện mỗi năm. Nhưng các lỗ hổng bảo mật được cài đặt sẵn như thế này lại là một thách thức mới khi đặt hàng triệu người dùng truowcs nguy cơ bị tấn công ngay từ khoảnh khắc họ khởi động thiết bị.

Điện thoại còn là một thiết bị rất hấp dẫn đối với các hacker, bởi chúng lưu giữ những thông tin nhạy cảm như vị trí, ảnh, tin nhắn và danh bạ của người dùng. Malware xuất hiện thường xuyên hơn trên điện thoại, và với lỗ hổng mới bị phát hiện trên các thiết bị Xiaomi, các hacker lại có thêm vô vàn các phương thức để tấn công.

Chúng có thể gây gián đoạn quá trình cập nhật của Guard Provider và đưa malware có thể đánh cắp dữ liệu, cài đặt các ứng dụng theo dõi, hay cài cắm ransomware vào thiết bị. Kẻ tấn công sẽ phải ước chừng thời điểm quá trình cập nhật diễn ra và còn phải nắm được tên của tập tin cập nhật - không hề khó bởi chúng đều tuân theo một khuôn mẫu.

"Nó lẽ ra phải bảo vệ bạn, và rồi nó lại làm điều ngược lại" - Giám đốc nghiên cứu của Check Point cho biết - "Nó mở một cửa hậu có thể khiến cả điện thoại bị can thiệp.

Check Point xác nhận rằng Xiaomi đã khắc phục vấn đề. Nhưng nếu bạn quan ngại về những lỗ hổng như thế này, bạn nên cẩn trọng hơn khi kết nối tới các mạng Wi-Fi công cộng, bởi một cuộc tấn công chỉ có thể xảy ra khi người dùng đang ở cùng mạng Wi-Fi với các hacker.

Tham khảo: CNET - Trans: GenK

01/04/2019

Hội thảo Việt Nam Security Summit 2019: An toàn, an ninh mạng trong hành trình chuyển đối số


Các nội dung chính được thảo luận tại Hội thảo Vietnam Security Summit 2019:
- Tổng quan tình hình an toàn, an ninh mạng Việt Nam và báo cáo đánh giá năng lực bảo mật thông tin của các tỉnh/thành phố
- Dự báo các xu hướng tấn công an ninh mạng và phương án phòng thủ
- Thách thức và giải pháp cho Bảo mật IoT tại Việt Nam
- Mô hình bảo mật tích hợp cho môi trường nhiều đám mây
- Phát hiện sớm và ngăn chặn các cuộc tấn công APT với công nghệ Machine learning/AI
- Phòng thủ chủ động trước các nguy cơ mất an toàn thông tin trên các thiết bị di động
- Nâng cao ứng phó sự cố bảo mật trong bối cảnh yêu cầu tuân thủ mới

Cũng trong khuôn khổ sự kiện Hội thảo Vietnam Security Summit 2019 còn diễn ra Triển lãm quốc tế Vietnam Security 2019 và chương trình Security Demo với các phần demo như sau:

Demo 1: Nhận dạng hiểm họa nhanh hơn. Giảm thiểu thời gian dừng. Phản hồi tự động
Đơn vị thực hiện: Chuyên gia kỹ thuật cấp cao của RSA khu vực Đông Nam Á
Demo 2: Phát hiện tự động và kịp thời các mối đe dọa
Đơn vị thực hiện: TECHDATA
Demo 3: Phát hiện và ngăn chặn mã độc trước khi lây lan
Đơn vị thực hiện: BKAV
Demo 4: Ngăn chặn các cuộc tấn công IoT (IoT Hacking)
Đơn vị thực hiện: VIETTEL
Demo 5: EagleEye malBot-BOT tự động phát hiện và ngănchặn máy tính vi phạm hệ thống mạng
Đơn vị thực hiện: Giám đốc phát triển sản phẩm từ FPT-IS
Demo 6: Kiểm thử xâm nhập cho các ứng dụng
Đơn vị thực hiện: VSEC
Nội dung trong Security Demo vẫn tiếp tục được update.

07/03/2019

Web Cache Poisoning


Web cache poisoning là một lỗi khá là khó tấn công, một mối nguy hại thường được mọi người coi là "mang tính lí thuyết". Tuy vậy, đã có những tấn công được thực hiện thành công. Nếu muốn thử, ta nên tìm hiểu xem làm thế nào để "đầu độc" web cache.

Web Cache
Web cache là một vùng nhớ được đặt giữa client và server trong hệ thống. Công việc của nó là liên tục xem xét các request được gửi đến và tìm kiếm trong các response đã được lưu lại, đồng thời nó cũng sẽ lưu những response "mới". Như vậy cache có tác dụng rút ngắn thời gian phản hồi khi cùng một request hoặc nhiều request "tương đương nhau" được gửi đi nhiều lần.

Sơ đồ sau sẽ nói rõ hơn về cách cache hoạt động:

Có thể thấy ở thời điểm ban đầu, user1 đã gửi đi 1 request và nó sẽ đi qua cache, cache sẽ xem xét request này, đối chiếu với dữ liệu của nó xem liệu có response đã được lưu lại cho request này chưa, và kết quả là chưa. Vì thế cache sẽ tiếp tục forward request đến cho server xử lí, server trả lại response, và cache cũng sẽ bắt được response này, lưu nó lại cho request trước đó. Và khi những người dùng tiếp theo gửi request tương tự, cache nhận request và tìm ra ngay được response cho request này và nó sẽ gửi lại response đó về cho phía client luôn.

Dựa vào vị trí mà cache được đặt, người ta chia web cache làm 3 loại chính :
- Browser Cache: Được đặt ở trên thiết bị của client, chính xác là 1 phần bộ nhớ của thiết bị. Chỉ phục vụ cho một người. Ví dụ phổ biến nhất là khi bấm nút back trên trình duyệt

- Proxy Cache: Làm việc giống Browser Cache, được đặt tại proxy server và cài đặt bởi nhà phân phối mạng. Proxy Cache có thể phục vụ 1 lượng người dùng lớn.

- Reverse Proxy Cache: Đặt gần với origin server nhất, được cài đặt bởi nhà quản trị, hoặc có thể mua cache từ bên thứ 3 (ví dụ như Content delivery networks (CDN))



Cache Key
Nói chung là cache sẽ nhận request và tìm trong dữ liệu của nó có response nào đáp ứng được request tương tự trên và trả về cho phía client. Vậy làm sao để cache biết rằng 2 request là tương tự, là giống nhau, và có thể đáp ứng bởi cùng 1 response ?

Lập trình viên có thể cài đặt cơ chế so sánh byte-to-byte cho cache. Tuy nhiên sử dụng cách này khá là kém hiệu quả. Thứ nhất, quá trình so sánh như vậy mất khá nhiều thời gian, tài nguyên. Thứ hai, trong một request có khá nhiều headers không quan trong và không ảnh hưởng nhiều tới response trả về như là User-Agent chẳng hạn.

Có một cách giải quyết khác cho vấn đề này đó chính là sử dụng cache key. Đó là một chuỗi các thành phần trong HTTP request mà cache sẽ chỉ dùng giá trị của chúng để so sánh giữa các request khác nhau để nhận biết được các request tương đương.
Phần in đỏ bao gồm phương thức (GET), URI (/hello/hello.php), Host header (example.com), chính là những cache key, và những request nào có 3 thông tin trên giống nhau sẽ được hệ thống cache trả lại những response giống nhau.

Tuy nhiên việc sử dụng cache key không hoàn toàn là tốt. Nó tiềm ẩn nhiều nguy cơ dẫn đến việc response trả về cho client có nội dung không chính xác như trong trường hợp sau:



Request đầu tiên được cache lại cùng response có nội dung tiếng Việt, request thứ 2 yêu cầu ngôn ngữ tiếng Anh nhưng sẽ lại được hệ thống cache trả về response có nội dung tiếng Việt.

Cache Poisoning
Bây giờ hãy tìm hiểu kĩ hơn về kĩ thuật tấn công Cache Poisoning.
Mục tiêu của tấn công này là hacker phải gửi một request tới server mà response của nó trở nên độc hại, đồng thời phải làm cho response này lưu được trên cache để nó được gửi đến nhiều người khác. Có một vài cách để làm cho response sau khi gửi request trở nên độc hại như là : ghi chèn vào HTTP headers, phương pháp HTTP Response Splitting, HTTP Request Smuggling.

Các bước tấn công:
Trước hết hacker cần xác định giá trị có thể ghi chèn trong request mà ảnh hưởng tới response trả về (gọi là unkeyed input), và đánh giá về tiềm năng của nó. Tiếp theo là gửi đi request đã được sủa đổi để response trả về đầu độc cache hay nói cách khác là cache sẽ lưu lại response độc hại. Tuy nhiên bước này không phải là dễ dàng, để response độc hại lưu lại trên cache, hacker cần phải nắm được nguyên tắc lưu đệm của hệ thống, cũng như xác định được phần web page có thể được lưu đệm. Sơ đồ sau cho ta cái nhìn tổng quan hơn:
Ở bước 1 có thể dùng tay, hoặc dùng tool. James Kettle có giới thiệu một công cụ trên Burp Suite đó là Param Miner ( 1 extension miễn phí). Công cụ này sẽ đưa ra một số header có thể là unkeyed input, và ta sẽ nhanh chóng tìm được unkeyed input "tiềm năng" hơn:

Tấn công
1. Ghi chèn thêm giá trị vào HTTP request
Cùng xem qua một số tấn cong trong thực tế của James Kettle: Anh đã thử tấn công vào trang redhat.com và sử dụng Param Miner tìm ra được unkeyed input X-Forwarded-Host
Và tấn công, nếu ressponse được lưu trên cache thành công, thì ai truy cập vào www.redhat.com/en?cb=1 cũng sẽ bị alert(1).

Vấn đề khác khó hơn, làm sao để cái response độc hại được cache lại? Hacker có thể spam gửi request liên tục, hoặc là bằng cách nào đó dịch ngược được hệ thống cache của mục tiêu. Nhìn chung thì spam thì lại quá tải băng thông, dịch ngược thì cũng khoai. Nhưng mà đôi khi server lại giúp hacker lưu được response độc hại lên cache 1 cách dễ dàng hơn. James đã tìm được trên website unity3d.com
 Để ý trên response, trong header Cache-Control có max-age=1800 , như vậy ta biết được thời gian mà response được lưu trên cache cho tới khi hết hạn (1800 giây). Ngoài ra có header Age :174 cho biết nội dung này đã được lưu trên cache 174 giây. Từ đó mà hacker biết thời điểm nào để gửi resquest sao cho response được cache lại.

2. HTTP Response Splitting
Trước hết hay xem qua về cơ chế hoạt động của cách thức tấn công này
Giả sử mình gửi 1 request đến URL sau:
http://www.example.com/welcome.php?lang=vi
Khi đó response trả về sẽ là:

Bây giờ mình sẽ thay đổi request đi một chút:
http://www.example.com/welcome.php?lang=Foo%0d%0aConnection:%20Keep-Alive%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.0%20200%20OK%0d%0aContent-Type:%20text/html%0a%0aContent-Length:%2020%0d%0a%0d%0a<html>Sorry:)</html>
Lúc này response trả về sẽ là:

Đúng như cái tên của nó, response đã bị chia ra làm đôi, tức là server sẽ trả lại 2 response trong khi chỉ có 1 request gửi tới.
Và trên lí thuyết, ta có thể tận dụng điều này để thực thi Cache Poisoning. Bây giờ ta sẽ biến trang http://www.example.com/welcom.php thành trang Sory:) nhé.



Về cơ bản là hacker sẽ gửi 2 request bao gồm : 1 HTTP response splitting request và 1 request bình thường tới trang http://www.example.com/welcom.php. Và cache được đặt trên proxy server sẽ gán response đầu tiên cho request đầu tiên, và request thứ 2 (tới /welcome.php) sẽ được gán với response thứ 2 (Sorry:)), và xong, cache bị đầu độc.

Tuy nhiên để thực hiện thành công thì hacker cần phải căn time chuẩn sao cho cái request thứ 2 tới được proxy trước cái response Sorry:). Nghĩa là hacker phải gửi request thứ 2 đi thật nhanh, chưa kể còn nhiều yếu tố ảnh hưởng như đường truyền mạng.

3. HTTP Request Smuggling
Request "lậu" là một kĩ thuật tấn công nhằm vào các server. Trong đường truyền mà request từ phía client được phân tích bởi nhiều hệ thống thì sẽ có nguy cơ bị dính tấn công này.
Ví dụ luôn cho dễ hiểu, ví dụ dưới đây cũng sẽ chỉ ra cách mà HTTP Request Smuggling đầu độc cache như thế nào
Trước hết hãy có nhìn qua 1 HTTP request như sau:

Ta thấy đây là một POST request có 2 header Content-Length. Một vài server sẽ loại bỏ những cái request kiểu này (như Apache). Tuy nhiên có những hệ thống chỉ loại bỏ 1 trong 2 cái header bị lặp kia. Có server thì loại bỏ cái thứ 2 dùng cái thứ nhất (SunONE web server 6.1), có server lại dùng cái thứ 2 loại cái thứ nhất (SunONE proxy server). Và đây chính là điểm mấu chốt để hacker có thể khai thác và tấn công.

Okey, giả sử www.example.com là trang web trên SunONE web server đước đặt sau SunONE proxy. Khi ta gửi request này, trước tiên, proxy sẽ phân tích POST request (màu xanh dương) và nhận thấy có 2 header Content-Length, và như đã nói, nó sẽ bỏ cái Content-Length : 0, nó sẽ cho rằng phần body của request này là 44 bytes, nên nó sẽ đọc tiếp 44 bytes sau dấu xuống dòng (màu xanh lá). Vậy proxy sẽ coi 2 vùng màu xanh là request đầu tiên, và màu đỏ là request thứ 2.

Giờ thì xem request trên khi gửi tới web server nó sẽ xử lí ra sao. Không như proxy, web server sẽ lấy cái Content-Length :0 và nó sẽ coi phần màu xanh dương là request đầu tiên, và phần còn lại (màu xanh lá và đỏ) là request thứ 2

Bây giờ, thử xem response nào sẽ được gửi lại cho client. Những request mà web server thấy là POST /welcome.html và GET /poison.html, do đó nó sẽ gửi lại 2 response với nội dung của welcome.html và poison.html. Còn proxy, 2 request của nó POST /welcom.html và GET /index.html. Và nếu poison.html có thể được cache lại, thì nội dung của trang poison.html sẽ được cache cho request GET /index.html và thế là xong, cache đã bị nhiễm độc.


Theo: Portswigger - Dịch: Cystack