Featured Post

Có một Biển Đông trên không gian mạng

Có một Biển Đông trên không gian mạng Thái Dương Mùa hè 2014, giữa lúc người Việt trong nước và hải ngoại đang sôi sục vì Trung Quốc đư...

Tuesday, December 29, 2015

Right now at Dreamplex


I feel old sitting next to these comrades. What was I doing when I was 20? Didn't really remember, but for sure I wasn't learning to hack Windows kernel.

Dreamplex looks like a nice place. They probably need to provide more comfortable chairs, but the offices look modern with fancy equipments and really fast WiFi, and the atmosphere is exciting with a lot of folks busily coding their dreams. I feel like at home.

Here come the winners

Whoa. Bruce and I have finally selected the winners of the memset challenge. We got 9 submissions, 5 of which came up with the same size, but only one person attempted to implement memcpy, and it's Manh Luat Nguyen. Congratulations!

The winning code is

global my_memset
my_memset:
pop edx ; return address
pop edi ; src String
pop eax ; char
pop ecx ; length
push edi
rep stosb
pop eax
sub esp,16
ret

The resulting shellcode is 12-byte: \x5a\x5f\x58\x59\x57\xf3\xaa\x58\x83\xec\x10\xc3. Instead of using movs, Luat was the first that creatively used one-byte pop instructions to save space.

The runner ups are
- Pham Hong Phi (12 bytes)
- Le Thanh Binh (12 bytes)
- Nguyen Vu Hoang (12 bytes)

There's actually one person that came up with a 10-byte implementation, it didn't pass my unit tests, but Bruce likes him enough that he wants to give him a special prize. Congratulations to Pham Viet Hoa!

Regarding scholarships I made a stupid mistake and booked a room too small (there were also some last minute registrations). Anyway Bruce and I don't really want to turn any of these young fellows down, so we're going to grant each a full scholarship, congratulations again!

Monday, December 28, 2015

Another update on memset()

We test submissions by running them through a set of unit tests which are written in standard C. Each unit test accepts a function pointer, which points to the being tested implementation. Thus, your function needs to work properly when called in a C program. While it's possible to use special compiler options or attributes to reduce code size, we won't use them in our unit tests. Moreover, if we replace the standard memset with your implementation existing C programs must still work.

Although you can give us an .asm file, it's best if you just give us some shellcode.

We have one hour to go, and the correct and shortest implementation that we've seen so far is 12-byte.

Last update on the memset challenge

We've received many good submissions to the memset challenge in the past 24 hours. We haven't tested, but it looks like someone has managed to shrunk it to fewer than 10 bytes, really cool!

Note that although we ask you to optimize for code size, in order to win your implementation must be correct first. It looks like some implementations don't return anything which is wrong as memset returns its first argument. Please send us updates if you want to correct your submission.

We're going to head out for the meeting at University of Science. After that we'll test the implementations and measure their size. We'll announce the winners early this evening.

Thanks all for participating!

Sunday, December 27, 2015

The shortest memset is... ?

We have a few 100% scholarships for college students to attend Bruce Dang's training class at TetCon 2016. In order to select the best persons that might make the most out of the class, we ask those who want to apply for the scholarship to implement memset, and whoever writes the shortest code wins. More details on this mini challenge can be found here.

So far we've already received 3 submissions. The shortest implementation is just 10-byte. Can you beat it ;)? Don't worry if you can't we'd love to see your code anyway.

--

In other news, tomorrow Bruce and I are going to have a Q&A session with computer science and computer security students at University of Science. We're going to share what we do in our day jobs, and answer any questions the audience might have w.r.t technology, working in the U.S., etc. The exact date and location is

Time: 13:00, December 29 2015 (tomorrow)
Location: Room I-23, 227 Nguyễn Văn Cừ, District 5.

The organizers told me that everybody is welcome. Hope to see you all!

Đánh nhau bằng toán

(Hello Facebookers! Có vẻ như ai đó đã gửi bài này lên Facebook. Tôi thấy rất nhiều người đọc đến từ đó. Tôi thêm vào một phần tóm tắt để cho những ai không rành kỹ thuật dễ nắm bắt hơn.)

Tóm tắt: Juniper, một hãng chuyên bán các thiết bị mạng nổi tiếng của Mỹ, thông báo rằng có ai đó đã bí mật cài mã độc vào các thiết bị của họ. Mã độc này cho phép kẻ tấn công có thể truy cập từ xa vào các thiết bị này, đồng thời giải mã luôn các dữ liệu được gửi xuyên qua chúng. Sau quá trình tìm hiểu, người ta phát hiện ra một trong hai mã độc có liên quan đến giải thuật tạo số ngẫu nhiên Dual EC. Từ năm 2007 hai nhà nghiên cứu ở Microsoft đã chỉ ra rằng giải thuật này có thể đã bị NSA cài mã độc và điều đó sau này được xác nhận bởi các tài liệu do Edward Snowden tiết lộ. Ngoài Juniper thì RSA, một công ty chuyên bán các sản phẩm an toàn thông tin đình đám khác của Mỹ, cũng từng bị phát hiện cố tình sử dụng Dual EC trong các sản phẩm của họ, sau khi nhận 10 triệu USD từ NSA. Nếu bạn là chủ doanh nghiệp hay người chịu trách nhiệm về an toàn thông tin cho doanh nghiệp, nên suy nghĩ thật kỹ trước khi sử dụng các sản phẩm của RSA hoặc Juniper. Cách tốt nhất để tồn tại là đầu tư để tuyển dụng và đào tạo các chuyên gia tại chỗ, những người sẽ giúp bạn xây dựng các giải pháp dựa trên các nền tảng mở.

Nếu quan tâm đến công nghệ và an toàn thông tin, bạn nên mua vé tham dự TetCon 2016. Trong khuôn khổ hội thảo chúng tôi sẽ thảo luận Việt Nam cần phải làm gì để tự bảo vệ trước hiểm họa đến từ chiến tranh mạng.

--

Tuần vừa rồi lúc tôi đang chuẩn bị cho chuyến về Việt Nam thì xảy ra một sự kiện cực kỳ lý thú: Juniper công bố các thiết bị VPN của họ đã bị cài backdoor (tức là ai đó cố tình tạo ra một lổ hổng để họ có thể bí mật kiểm soát các thiết bị này) từ năm 2012.

Sự kiện này là một trường hợp cho thấy tin tưởng mù quáng vào các thiết bị an ninh, nhất là các thiết bị mã nguồn đóng, thường là sai lầm lớn nhất khi làm quản lý an toàn thông tin. Cách đây nhiều năm khi viết về tường lửa (firewall) tôi có nói thế này:

<quote>
Firewall, về bản chất, cũng chỉ là một software chạy trên một hardware, mà đã là software, do con người tạo ra, thì thể nào cũng sẽ có lỗi. Kinh nghiệm của tôi cho thấy, nơi nào mà có software chạy, từ máy ATM cho đến các vệ tinh, nơi đó sẽ có bug, và có thể trong số các bug này, sẽ có những bug gây nguy hại đến sự an toàn của hệ thống.

Đương nhiên, các software, cụ thể là các hệ điều hành, chạy trên firewall thường rất nhỏ gọn, thường đã được kiện toàn trước khi xuất xưởng, và không phổ biến như Windows, Linux hay Mac, thành ra kiến thức về cách thức chúng hoạt động cũng như các kỹ thuật tìm kiếm và khai thác lỗ hổng bảo mật cũng không phổ biến đại trà.

Nhưng tất cả chỉ là vấn đề thời gian (và tiền bạc) mà thôi. Chẳng hạn như đối với Cisco IOS, từ năm 2005, Michale Lynn đã công bố các phương thức khai thác lỗi của nó (trước đó có FX từ năm 2003 đã có những research hoàn chỉnh về Cisco IOS). Kể từ đó đến nay, đã có rất nhiều research của các hãng và cá nhân tên tuổi trên thế giới về các lỗ hổng bảo mật trên hệ điều hành này của Cisco. Thậm chí gần đây, người ta còn phát triển được cả rootkit trên IOS.
</quote>

VPN là giải pháp truy cập từ xa vào hệ thống mạng nội bộ. Thông qua VPN một nhân viên ngồi ở nhà, hoặc quán cafe, có thể truy cập vào hệ thống mạng nội bộ của công ty như bình thường. Thiết bị VPN là dạng thiết bị trọng yếu bật nhất trong hệ thống thông tin của một công ty. Tài khoản truy cập VPN thường gắn liền với tài khoản email, ngoài ra với vị trí cầu nối giữa Internet và hệ thống nội bộ, thiết bị VPN thấy toàn bộ những dữ liệu nhạy cảm (bao gồm mật khẩu, văn bản, hình ảnh, v.v.) mà nhân viên công ty tải về máy tính cá nhân của họ. Ai kiểm soát được các thiết bị này thì coi như kiểm soát được tất cả thông tin mật của công ty.

Sau khi reverse engineering firmware của Juniper, người ta phát hiện ra hai backdoor: một backdoor cho phép truy cập từ xa mà không cần biết mật khẩu (chi tiết) và một backdoor cho phép những ai quan sát được dữ liệu (đã mã hóa) đi xuyên qua các thiết bị VPN có thể dễ dàng giải mã chúng. Với backdoor đầu, coi như ai cũng có thể điều khiển các thiết bị VPN của Juniper, rất nguy hiểm nhưng về mặt kỹ thuật cũng không có gì đặc sắc, nhưng backdoor thứ hai thì cực kỳ thú vị.

Mật mã học hiện đại phụ thuộc rất lớn vào các bộ tạo số ngẫu nhiên. Mỗi lần bạn truy cập vào Facebook, máy tính của bạn và máy chủ Facebook liên tục tạo ra các số ngẫu nhiên và sử dụng chúng để mã hóa dữ liệu truyền giữa hai phía. Cũng tương tự như vậy, khi một nhân viên truy cập vào hệ thống VPN, máy tính của họ và thiết bị VPN cũng liên tục tạo ra các số ngẫu nhiên để mã hóa dữ liệu truyền qua lại.

Ai đã từng lập trình sẽ hiểu tạo số ngẫu nhiên trên máy tính không đơn giản chút nào. Các hệ điều hành và các thư viện phần mềm thường cung cấp sẵn các hàm tạo số ngẫu nhiên, nhưng bạn có bao giờ thắc mắc các hàm này được lập trình ra sao chưa? Nói cách khác, bây giờ nếu không gọi các hàm có sẵn, bạn sẽ làm gì để tạo ra một số ngẫu nhiên trong chương trình của bạn? Bạn sẽ nhận ra rằng bất kể thuật toán của bạn là gì, nó sẽ là tất định, đầu vào hoàn toàn quyết định đầu ra, không có cách chi để bạn lập trình máy tính trả về một số ngẫu nhiên cả. Nếu đơn giản, Knuth đã không dành hẳn một chương trong bộ The Art of Computer Programming để bàn về các thuật toán tạo số ngẫu nhiên.

Các bộ tạo số ngẫu nhiên là những thuật toán tất định (deterministic algorithm) sử dụng một trong hai mẹo để tạo ra sự ngẫu nhiên:
* ghi nhớ số ngẫu nhiên đã tạo trước đó và các số tạo tiếp theo sẽ phụ thuộc vào số tạo trước nó. Tôi sẽ không bàn về kỹ thuật này ở đây, ai hứng thú có thể xem thêm bộ tạo số ngẫu nhiên đồng dư tuyến tính.
* sử dụng các phần cứng đặc biệt để tạo ra số ngẫu nhiên đầu tiên (thường được gọi là seed, hạt giống), các số ngẫu nhiên tiếp theo sẽ phụ thuộc vào hạt giống ban đầu. Đây là kỹ thuật của các bộ tạo số ngẫu nhiên dùng trong mật mã và cũng được sử dụng bởi các thiết bị VPN của Juniper.

Các CPU hiện đại thường có sẵn một mô-đun để tạo số ngẫu nhiên, dựa vào các sự kiện ngẫu nhiên mà CPU quan sát được, ví dụ như số lần instruction mov eax, eax được thực thi trong 1s vừa rồi, hay các hiện tượng vật lý (xem thêm bộ tạo số ngẫu nhiên thực). Các số ngẫu nhiên được tạo ra ở trong CPU hoàn toàn không thể dự đoán được, nhưng các bộ tạo số này thường rất chậm, do phải phụ thuộc vào môi trường, thường không đáp ứng được nhu cầu của hệ điều hành và các phần mềm chạy ở trên hệ điều hành (ví dụ như trình duyệt, v.v). Do đó người ta chỉ dùng các số ngẫu nhiên do CPU tạo ra để làm hạt giống cho các bộ tạo số ngẫu nhiên bằng phần mềm. Ví dụ như trên Linux, có bộ /dev/urandom

$ cat /dev/urandom

Từ đây về sau tôi dùng từ bộ tạo số ngẫu nhiên để chỉ các bộ tạo số ngẫu nhiên bằng phần mềm, tương tự như /dev/urandom.

Tiêu chuẩn quan trọng nhất của các bộ tạo số ngẫu nhiên là không thể dự đoán. Nếu chỉ cần quan sát một vài số đã được tạo ra mà có thể dự đoán được những số sẽ được tạo ra tiếp theo (hoặc là trước đó), bộ tạo số coi như không đủ tiêu chuẩn để dùng trong mật mã. Có nhiều thuật toán ngẫu nhiên, nhưng Juniper chọn thuật toán có tên là Dual EC. Trên danh nghĩa đây là thuật toán được thiết kế và chuẩn hóa bởi Viện Tiêu Chuẩn Công Nghệ Mỹ (NIST), nhưng các tài liệu của Edward Snowden chỉ ra rằng thuật toán này được thiết kế bởi Cục An Ninh Quốc Gia Mỹ (NSA). Vấn đề là NSA đã cài một backdoor vào thuật toán này, giúp họ có thể dự đoán được những số sẽ được tạo ra chỉ bằng cách quan sát một số trước đó.

Mặc dù Dual EC có thể đọc thành DỞ ẸC, nhưng chữ EC thật ra có nghĩa là elliptic curve. Dual EC sử dụng nhóm các điểm trên đường cong elliptic curve để tạo số ngẫu nhiên. Thuật toán này có hai bước đơn giản

* Từ một số ngẫu nhiên $r$, tạo ra số ngẫu nhiên kế tiếp bằng cách tính $r * Q$, tức cộng dồn điểm $Q$ $r$ lần.

* Thay thế $r$ bằng $r * P$.

Lưu ý nếu biết $r$ thì có thể dự đoán được tất cả các số sẽ được tạo ra tiếp theo.

Mô tả của tôi về thuật toán Dual EC không chính xác 100%, nhưng đủ chính xác để giới thiệu backdoor. $P$ và $Q$ là hai điểm cho trước trên đường cong. NSA chọn $P$ là một hằng số không có gì đáng nghi ngờ, nhưng không giải thích nguồn gốc của $Q$. Hai nhà nghiên cứu của Microsoft chỉ ra từ 2007 rằng nếu $Q$ không được chọn ngẫu nhiên, NSA có thể dự đoán được tất cả các số sẽ được tạo ra tiếp theo, chỉ bằng cách quan sát một số đã được tạo ra trước đó. Vì $P$ và $Q$ được định nghĩa trên đường cong có tên là P-256, nên tồn tại một số $e$, sao cho $e * Q = P$. Nếu biết được $e$, từ $r * Q$ NSA có thể tính $r * Q * e = r * P$, tức là đã tính được $r$ và từ đó có thể dự đoán được tất cả những số ngẫu nhiên sẽ được tạo ra. Vì NSA chọn $P$ và $Q$ nên chắc chắn họ biết $e$.

Nếu bài toán logarithm rời rạc trên nhóm các điểm trên đường cong elliptic là khó, ngoài NSA ra không ai có thể sử dụng backdoor này. Đây là dạng backdoor NOBUS (No One But Us) được chính phủ Mỹ và các nước ưa thích. Vấn đề của NSA là làm sao thuyết phục được các công ty sử dụng Dual EC. Thuật toán này chạy rất chậm và ngoài backdoor này ra, nó còn có vài vấn đề an ninh khác. Do đó khi Edward Snowden xác nhận Dual EC đích thực bị NSA cài backdoor, lúc đầu người ta nghĩ chắc không ai sử dụng nó đâu.

Rốt cuộc người ta phát hiện có ít nhất 4 công ty Mỹ có đính kèm Dual EC vào các sản phẩm của họ: Microsoft, Cisco, RSA và bây giờ là Juniper. Tôi không rõ Cisco sử dụng Dual EC như thế nào, nhưng Microsoft không sử dụng chúng như là bộ tạo số mặc định (người dùng phải chỉnh một cờ trong registry để kích hoạt bộ tạo số này). RSA là một trường hợp rất thú vị. RSA bán một bộ thư viện mật mã mang tên là BSAFE và BSAFE sử dụng Dual EC là bộ tạo số mặc định. Nói cách khác, ai sử dụng sản phẩm của RSA coi như đã bị chính phủ Mỹ nắm đầu. Người ta còn phát hiện ra một hợp đồng bí mật trị giá 10 triệu USD mà NSA trả cho RSA để cài Dual EC vào BSAFE. Tóm lại chỉ có khùng (hoặc giả khùng ngậm tiền) mới tiếp tục sử dụng sản phẩm của RSA.

Cái cách mà Juniper sử dụng Dual EC cũng rất lý thú. Họ dùng nó một cách gián tiếp. Họ tạo ra một số ngẫu nhiên từ Dual EC, rồi sử dụng số đó để làm hạt giống cho một bộ tạo số khác, nhanh hơn, an toàn hơn và không có backdoor. Tại sao? Chẳng ai biết! Không có lý do gì để Juniper làm như vậy cả, ngoại trừ khi họ bị ép buộc phải sử dụng Dual EC (hoặc, như RSA, có hợp đồng bí mật với NSA). Đặc biệt nhất, Juniper không sử dụng $Q$ do NSA chỉ định, mà lại tự định nghĩa một hằng số  $Q'$ khác. Vấn đề là Juniper không thể chỉ ra $Q'$ đã được tạo ra như thế nào. Không ai có bằng chứng chuyện gì đã diễn ra, nhưng chỉ có hai giả thuyết:

* Juniper tự tạo $Q'$ cho riêng mình để loại trừ backdoor của NSA.

* NSA tạo $Q'$ và yêu cầu Juniper sử dụng $Q'$.

Nhắc lại, chẳng có lý do chính đáng để sử dụng Dual EC, nên nếu Juniper muốn xóa backdoor, cách đơn giản hơn là không sử dụng Dual EC. Thành ra giả thuyết thứ hai có vẻ mạnh hơn. Có thể NSA không muốn gom tất cả trứng để vào một rổ, hoặc họ muốn chia sẻ backdoor trên thiết bị VPN của Juniper của họ với đối tác mà không muốn tiết lộ cách tạo $Q$, vì thông tin đó có liên quan đến backdoor ở nhiều thiết bị khác nữa, không riêng gì VPN.

Không ai biết Juniper bắt đầu sử dụng Dual EC từ khi nào, nhưng năm 2012 xảy ra một sự kiện quan trọng. Một nhân viên nào đó của Juniper hoặc một ai đó xâm nhập vào hệ thống của họ đã bí mật đổi $Q'$ thành $Q''$. Juniper mới (?) phát hiện ra chuyện này cách đây vài tuần và thông báo của họ đã khơi nguồn cho bài blog này.

Ai đã đổi $Q'$ thành $Q''$? Có phải Juniper mới phát hiện ra không, hay là họ đã biết từ lâu nhưng không nói gì? Tại sao lại chọn công bố ngay giữa lúc ở Mỹ đang có cuộc tranh luận lớn về chuyện chính phủ Mỹ có được quyền gài backdoor vào các tiêu chuẩn mật mã hay không?

Không có ai có đủ thông tin để trả lời những câu hỏi này. Tôi nghĩ chính NSA đã đổi $Q'$ thành $Q''$. Nếu NSA kiểm soát $Q'$ như đã bàn ở trên và vào năm 2012 một ai đó (Trung Quốc chẳng hạn) đổi $Q'$ thành $Q''$, tức là backdoor của NSA đã bị vô hiệu hóa trong suốt 5 năm qua mà họ không hay biết gì sao? Tôi nghĩ khó có khả năng đó. Ngược lại, nếu NSA đổi $Q'$ thành $Q''$ thì backdoor của họ vẫn còn hiệu lực trong suốt thời gian qua.

Khi phát hiện ra có người đổi $Q'$ sang $Q''$, Juniper sửa lại bằng cách đổi trở lại $Q'$. Có thể họ có hợp đồng với NSA? Chẳng ai biết tại sao họ không bỏ Dual EC đi quách cho rồi! Hơn nữa, để khai thác được backdoor này, kẻ tấn công phải quan sát được $r * Q$, nhưng điều đó là không thể nếu như Juniper chỉ sử dụng Dual EC để tạo hạt giống cho một bộ tạo số khác (như đã nói ở trên). Vấn đề là trong mã nguồn của Juniper còn có một lổ hổng khác (một backdoor thứ ba, không biết được cài từ hồi nào) tiết lộ giá trị của $r * Q$. Juniper không hề đả động gì đến lổ hổng này trong các thông báo sửa lỗi của họ. Tại sao? Không ai biết cả.

--

Một vị quan chức ngành an toàn thông tin có lần hỏi tôi có nên tin tưởng các thiết bị của nước ngoài hay không. Tôi có nói xét ở bình diện an ninh quốc gia thì chẳng thể tin tưởng ai cả. Chỉ có cách duy nhất là tuyển dụng đào tạo đội ngũ kỹ sư lành nghề để họ xây dựng giải pháp dựa trên các nền tảng mở sẵn có.

Đối với doanh nghiệp thì thú thật tôi cũng không có giải pháp nào khác ngoại trừ việc thuê mướn đào tạo tuyển dụng chuyên gia. Doanh nghiệp nhỏ thì hi vọng là chẳng ai để ý đến mình, còn doanh nghiệp lớn, có làm ăn mua bán với nước ngoài thì chỉ có cách đầu tư mạnh để thu hút chất xám công nghệ mà thôi.

--

Nếu bạn thích những chủ đề như vầy, bạn nên mua vé tham dự TetCon 2016.

Saturday, December 26, 2015

Free seats for Bruce Dang's training class

Better late than never, I'm excited to announce that we're going to grant a handful of 100% scholarships for college students to attend Bruce Dang's class at TetCon 2016.

Since we'll probably receive more applications than available spots, we have a challenge and whoever wins will get to attend the class for free (with a chance to obtain a signed copy of Bruce's book on practical reverse engineering). Anyone can take the challenge, but in order to win you must be currently enrolling to some official university in Vietnam or oversea. We will check your student ID at entrance.

The class is two-day, Dec 30 and Dec 31. The location is in downtown Saigon. We won't be able to pay for accommodation or transportation.

Without further ado, here's the challenge: write memset() using x86 assembly. Whoever provides the shortest code in terms of code size, i.e., number of instructions, wins. You can implement for Linux or Windows. You can use whatever instruction set you want; however we are optimizing for code size and not for speed so you should be careful with the instruction set ;). You will need to send us source code of a working program that exercises the function.

Bonus challenge (which will be used to select the winners if too many people come up with the same code size for memset): implement memcpy using x86 or x86-64 assembly, whoever provides the fastest code wins. You will need to provide a wrapper that copies 100MB from one memory location to another using your memcpy. Benchmarking will be done on my laptop, which has a 2.7GHz dual-core Intel Core i5 processor (Turbo Boost disabled) with 3MB shared L3 cache and 8GB of RAM. You can use whatever instruction set supported by this CPU. I'm not running Windows, but I have GCC, Clang, NASM, etc. please tell me how to compile your code in your submission.

Please email your code and a short intro about yourself to thaidn@gmail.com. You can submit multiple entries, but we'll benchmark only the last one. The deadline is GMT+7 11:59 (one minute before noon) Dec 29. The winners will be announced at 17:00 on the same day.

Please leave a comment if you have any questions.

Have fun!

Friday, December 25, 2015

Tại sao các công ty nên gửi người đến TetCon

Trong lần nói chuyện ở ngày hội an toàn thông tin ở VNISA, tôi có nói trái với hiểu biết thông thường của nhiều người hầu hết các thiết bị và giải pháp bảo mật có sẵn thường làm cho hệ thống của người mua kém an toàn hơn (xem tóm tắt báo cáo của tôi ở đây). Mấy tuần vừa rồi xảy ra một sự kiện chứng minh cho luận điểm này.

Nhóm Project Zero phát hiện ra một lỗi chạy lệnh từ xa trên các thiết bị của FireEye. Lỗi chạy lệnh từ xa là dạng lỗi nguy hiểm nhất vì chúng cho phép toàn quyền điều khiển mục tiêu có lỗi. Các thiết bị của FireEye thường được đặt ở những khu vực trọng yếu trong hệ thống, có thể thấy hết toàn bộ dữ liệu đi ra đi vào hệ thống, từ email, tài liệu, cho đến mật khẩu, v.v. Nói cách khác, các thiết bị này trở thành mục tiêu "béo bở" nhất. Vấn đề là chất lượng an ninh phần mềm của các thiết bị như vậy thường không được đảm bảo, bởi các công ty làm thiết bị an ninh, trớ trêu thay, lại thường không có đội làm an ninh phần mềm. Ngoài FireEye, Project Zero còn phát hiện được lỗi của hầu hết các phần mềm chống virut khác, cũng là một vấn đề mà tôi đã nêu lên ở hội nghị của VNISA.

Các công ty bán giải pháp có sẵn ở Việt Nam ắt hẳn không thích nghe tin này. Đó là lý do TetCon không được các công ty như vầy tài trợ, trong khi hội thảo của VNISA thì đầy ắp. Tôi chủ trương giữ TetCon độc lập, thuần túy chuyên môn, tuyệt đối không có các bài nói chuyện quảng cáo của nhà tài trợ như các hội thảo khác ở Việt Nam. Tôi đã nói đi nói lại nhiều lần, nhưng tôi chưa bao giờ thấy chán khi nói rằng cách tốt nhất để đảm bảo an toàn thông tin là phải có đội ngũ kỹ sư lành nghề. Muốn như vậy thì phải gửi kỹ sư đến các hội thảo, gửi họ đi học, phải tạo điều kiện cho họ được tiếp cận với giới chuyên gia và được cập nhật những nghiên cứu phát triển mới nhất trên thế giới.

Nói cách khác, phải mua vé và đến dự TetCon!

Nhưng đừng tự bỏ tiền túi ra (trừ khi bạn là chủ doanh nghiệp, làm tự do, hoặc chưa đi làm). Tôi thất vọng khi các lớp training của TetCon không có đủ người và có những người phải tự trả tiền túi, thay vì được công ty trả cho. Tôi chưa từng thấy ai tự trả tiền để đi Black Hat hay đi học các lớp training ở đó. Nếu bạn phải tự trả tiền để đi dự TetCon, có lẽ nên tính đến chuyện tìm công ty khác. $500 và 500.000 đồng là những con số quá nhỏ, nếu các công ty không sẵn lòng chi số tiền này để giúp kỹ sư của họ giỏi lên, tôi nghĩ chẳng đáng để làm việc cho họ.

Ở Google, nhóm của tôi mỗi năm mỗi người có một suất chính thức đi dự bất kỳ hội thảo nào, ở bất cứ nơi nào trên thế giới. Công ty sẽ trả toàn bộ chi phí. Thật sự chỉ cần có thời gian và có lý do, một năm có thể đi vài chuyến như vậy. Vừa rồi tôi đi Pháp để dự một hội thảo nhỏ về crypto, công ty trả hết chi phí khách sạn, di chuyển và ăn uống. Về đào tạo thì chủ trương của công ty đã có sẵn, ai cũng có thể lấy lớp học để nâng cao trình độ. Tôi mua sách crypto, sách toán và sách cho công việc chưa bao giờ phải tự trả tiền túi.

Thursday, December 24, 2015

Sài Gòn

Bay nửa vòng trái đất, vừa thấy may mắn vì mình sinh ra thời này, di chuyển xa như vậy mà chỉ mất có chưa đến một ngày, vừa thấy mệt vì vẫn còn dài quá. Chuyến bay đầu kéo dài gần 15 tiếng đồng hồ, thêm chuyến sau 2 tiếng nữa, cuối cùng tôi cũng đã về đến Sài Gòn. Chỉ có điều hành lý thì vẫn đang ở lại San Francisco. Tôi sẽ sa thải hãng United mắc dịch.

Năm nay tôi chỉ về vài bữa, phải quay trở lại ngay sau TetCon 2016. Tôi muốn đi dự hội thảo Real World Crypto 2016 diễn ra ngay sau TetCon 2016 ở Stanford, lỡ hẹn mấy lần rồi. Nhắc mới nhớ, hôm trước nhờ báo Tuổi Trẻ đưa tin (có chỗ sai là tôi không phải làm cho Project Zero), bán nhanh vèo vèo, bây giờ đã bán hết hơn 2/3, chỉ còn vài chục vé cuối cùng. Ai chưa mua nên nhanh tay.

Thời gian ít ỏi nên chắc tôi chỉ loanh quanh ở nhà với gia đình. Hoạt động yêu thích của tôi là dẫn mấy đứa con nít trong nhà đi chơi sở thú. Dẫu vậy tôi cũng muốn có một buổi gặp gỡ nói chuyện với các bạn sinh viên đang theo học ngành CNTT hoặc ATTT. Năm ngoái tôi rất thích buổi nói chuyện với các bạn sinh viên ở Học Viện Kỹ Thuật Mật Mã ở Hà Nội.

Nếu có bạn nào đang làm ở các trường đại học ở Sài Gòn sắp xếp được một buổi như vậy, chừng 2-3 tiếng, thì vui lòng liên hệ với tôi ở địa chỉ thaidn@gmail.com nhé. Tôi sẽ tự thu xếp thời gian và phương tiên đi lại, không cần hỗ trợ của trường, ngoài phòng ốc. Xin cảm ơn.

Thursday, December 17, 2015

TetCon 2016: discounted tickets sold out!

Wow, thanks to your support all of our discounted tickets are claimed. Please keep spreading the word and help us sell even more!

Note that even at full price, we're selling tickets at a loss, as Sheraton charges us \$30 per person. A friend asked why I keep the prices too low, and I don't even have a good reason rather than that I want to ensure that everyone has a chance to attend the conference. That's why we give away 30 free tickets to students who show some interest in our field. That's why we have discounted tickets. But we really need your support to make this work. Please share the conference with a link to https://tetcon.org/ on Facebook, Twitter, your favorite forums, or write about it on your blog. Anything would be helpful and much appreciated :).

We need this world of mouth marketing, because this year I didn't raise enough money to hire someone to run a proper marketing campaign. Last year I got \$17,000 from Microsoft, Facebook, and my employer, but this year I've got so far only \$10,000 from Microsoft (thanks to Bruce Dang!) My employer's promised to give me \$5,000, but I don't know when it will be approved. I didn't ask Facebook, because I'm too shy (last year my boss pulled some string for me, but I don't feel like asking strangers for money). Anyway if we sell all the tickets the bottom line won't look too bad, given that some friends have promised giving me some monetary support (if you are reading this, thanks again!)

Organizing a conference like TetCon takes a lots of time and energy. While this blog might give you the impression that I've been doing it alone, nothing is further from the truth. There would be no TetCon without help and support of many friends and even random strangers who I know don't want their names to appear here. The technical committee have also spent tons of time reviewing and improving the submissions. Thank you!

Wednesday, December 16, 2015

TetCon 2016 Final Program Released

Phew! I'm excited to announce that the final program of TetCon 2016 has been released. It'll be a packed day full of hackers and security researchers who will show you how to find 0-days in Microsoft Edge, to break Android phones, or to build your own security tools.

We'll have 10 talks (out of 20 submissions.) We know it's insane to pack so much content in a single day -- next year I'll try to make this a two-day event -- but just come and see, and you'll understand why we chose these talks.

Happy holidays and see you all at Sheraton Saigon a few weeks from now!

Tuesday, December 15, 2015

TetCon 2016: 3 more new talks announced!

Congratulations to Nguyen Anh Quynh, Nguyen Hong Quang and Nguyen Minh Hai! They will share with us their tools and frameworks that they've built to analyze malware, write exploits, or just do anything you want to do with the CPU. These are must-see talks for people who are into low-level stuff.

I'm waiting for confirmation from the last two speakers, and will update you all as soon as they get back to me.

I've also sent 30 free tickets to students that have reached out to us. We won't be able to give away any more.

There are fewer than 20 discounted tickets left. Go buy yours before the price increases any moment from now.

Monday, December 14, 2015

TetCon 2016 news

I've been working on the final program, and will release it as soon as the committee gives me the green light and the speakers confirm their participants.

If nothing changes at the last minute, the second batch of talks will be on building security tools to find 0days, to analyze malware or to develop kernel exploits. This is another proof that our community has reached to the next level of the security research food chain -- we used to be consumer of tools provided by oversea researchers, but we now build our own ones.

We will have up to 10 talks, and it's already a challenge to schedule the program. We want to give speakers enough time to demonstrate their ideas, but we also want to have more time for tea and lunch breaks which hopefully would sparkle more interactions between speakers and attendants. Speaking of lunch break, it'll be awesome if someone can sponsor a lunch party for everyone. Please drop me a line if you or someone you know are interested in this great chance to connect with the top security professionals in our country.

Two third of the discounted tickets were sold in the last few days. This is probably your last chance to get one; otherwise you'll have to pay the full price.

Re trainings: if you had registered for any of the classes, please expect an email from me tomorrow. I'll tell you the exact date, time, location, and payment method. Stay tuned.

Thursday, December 10, 2015

First batch of TetCon 2016 talks released tonight

Edit: talks are out. Congratulations to Ngo Anh Huy, Pham Tung Duong, Tran Minh Quang, Nguyen Van Long, Hung Dang, and Caleb Fenton!

We've finally come up with the first batch of talks, which will be released on https://tetcon.org as soon as I get home today (I'm at work and don't have access to the server.) The rest will be chosen and announced in a few days.

The talks are super interesting, some are very original, and I'm sure you will enjoy them all. All but one speaker are local, but what's made me most excited is I don't know most of them. Perhaps I've been too disconnected with the community -- I used to know most Vietnamese hackers -- but perhaps there is now a new generation with so many great hackers that it's impossible for anyone to know everyone. The new faces are young, speak English, work for big corps or consulting firms, and thanks to CTF games they can reverse engineer code, write exploits, hack web or break crypto. I have no doubt that in the years to come these comrades are poised to make great discoveries and make a name for themselves in the "Who's Who" of the world's best hackers.

We, as a community, have come a long way. If I remember correctly we had our first ever security conference in 2003. It attracted perhaps 100 people, and was held at Nha Van Hoa Thanh Nien. I was one of the presenters, but with all due respects to the organizers and all of my friends we were, or at least I was, lame. There were a few exceptions, but the rest of us frankly didn't really know what we were talking about. We took ourselves too seriously, but we didn't even know what we didn't know because we were too disconnected with the rest of the world. We still got to hack a lot of stuff, but we mostly used existing techniques or bugs without coming up with anything original ourselves. Nobody I knew except perhaps vicky or $$$ was actually trying to find new ways of breaking things.

We couldn't get to where we are today, without the pioneers of our community. In no particular order, rd, aquynh, lamer, phuong-ga-con, conmale, etc., have inspired me and my friends and their friends. I've learned a lot from them, and I'm grateful that they've shared with us the good stuff that they know. Thank you.

PS: the discounted tickets are selling pretty fast. I think we'll be sold out before the end of this week. Get yours now!

Monday, December 7, 2015

Bad Life Advice: Never Give Up - Replay Attacks Against HTTPS

(joint work with Thiago Valverde and Quan Nguyen -- see also Thiago's post on his blog)

I was once advised by a self-help book that I should never give up, be confident in myself, and keep trying. The secret to success is failure, wrote the book. I'd always believed that this is a great wisdom until Thiago and Quan helped me realize that it could lead to replay attacks.

A few weeks ago we found that because Chrome (and Firefox and possibly other browsers) automatically retries failed requests, a man-in-the-middle adversary can easily duplicate and replay HTTPS traffic. More details can be found in Thiago's blog post, but the attack can be summarized as follows:

* The adversary sets itself up as a TCP layer relay for the targeted TLS connection to, say, google.com.

* When the adversary detects a request that it wants to replay (using traffic analysis), it copies all relevant TLS records, and instead of relaying the HTTP response from the server it just closes the socket to Chrome. It keeps the leg to google.com open.

* Over a fresh socket, Chrome would automatically retry the (presumed failed) request. The adversary would then forward it normally to google.com.

* Adversary replays the copied records to google.com, which will happily accept them.

This a cute attack, but we don't think it's too alarming. While Thiago made a proof of concept which works like a charm against an internal tool at Google, we failed to mount the attack against PayPal though. It looks like most important websites that we looked at have some defense against this attack, probably not because they are aware of it, but because they just want to prevent their users from unintentionally sending duplicated requests.

Still it's amusing thinking about what has gone wrong here. I don't blame TLS, which does the right thing when it comes to replay attacks. TLS promises that none can replay its records, and it delivers by using random nonces and sequence numbers. No TLS records were replayed in our attack. We can't do that. What we replayed was HTTP payload.

This attack exploits a mismatch between what is promised by TLS and what is actually deployed. TLS proudly declares, "Alright. TLS clients and servers of the world, we protect your traffic against replay attacks," but our beloved protocol can't do nothing when clients replay their own traffic, which is what happening in the real world. As a result servers still have to defend themselves, which is surprising, and might caught some developers off-guard.

Moral of the story: give up on the first failure and stop reading self-help books.

Buy your tickets to TetCon 2016 now!

TetCon 2016 tickets are available for sale today. There are only 300 tickets. Buy yours now before it's too late!

Each ticket is VND500,000, but if you buy before December 21, you are eligible for a ~30% discount, and have to pay only VND350,000. Available tickets are on sale until January 3, 2016. We do not sell tickets on the day of the conference or at the entrance.

For students only: we will give free tickets to eligible students.

Friday, December 4, 2015

TetCon 2016 Last Call For Papers

If you submitted something, I just emailed you with a round of feedback from the committee. Please respond and address our concerns as soon as possible.

If you, however, plan to submit something, this is your last chance. We've received 13 submissions, 9 of them are Vietnamese, 3 of which are working and living oversea, and the rest are foreigner. The committee will be working very hard next week to select the best submissions which together with the invited talks will form the final program of TetCon 2016.

Chances are we have to cancel the training program, unless we get 5 more sign ups for each class before the end of next week. So if you want to learn more about bitcoin, Windows kernel reversing, or crypto, sign up now! I don't want to brag about it, but other conferences have offered the same classes at 4 to 6 times our price.

Thursday, December 3, 2015

It's official: TetCon 2016 will be at Sheraton Saigon

It's somewhat unexpected, but a very nice man, perhaps a regular reader of this blog, has helped us secure a deal with Sheraton, the marvelous 5-star hotel right at the heart of Saigon.

Tickets will be on sale tomorrow. See you all at Sheraton on Jan 4, 2016!

Tuesday, December 1, 2015

TetCon News

* If you want to submit to TetCon, please do it now. The CFP will end by the end of this week.

* If you want to take one of the training classes, please sign up now. We need at least 10 attendants per class; otherwise we have to cancel because we can't cover the cost.

* We are still working on the venue, as it turns out that we couldn't afford what we chose last time. If you know someone that wants to sponsor TetCon please leave a comment or reach out to me in private at thaidn@gmail.com. We seriously need more funding.

Thanks!