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 đư...

Thursday, August 27, 2009

WOWHacker CTF - Binary Challenges

Challenge 2

Challenge 2 is simple yet interesting. The initial target is a Python 2.2 byte-compiled file, so the first job is to decompile it to get the source code. Fortunately, decompyle just works:

$ decompyle newbie.pyc

Thu Aug 27 02:13:25 2009
# emacs-mode: -*- python-*-
import urllib
def some_cryption(arg):
a = 'http://'
dummy = 'http://korea'
b = 'uxcpb.xe'
b = b.encode('rot13')
c = 'co.kr'
cs = '.com'
d = '/vfrp/uxuxux'
dt = '/hackers'
d = d.encode('rot13')
dx = 'coolguys'
ff = urllib.urlopen(((a + b) + d))
f_data = ff.read()
file = open('hkhkhk', 'w')

You can see that the purpose of this script is to download some data from a fixed URL, and save them to a file named hkhkhk. We ran the script, and it indeed downloaded this file. As the script suggests, the content of hkhkhk is encrypted by some cipher.

Opening hkhkhk in a hex editor, one could see that it contains quite a lot of 0x77 characters. A friend of us, Julianor from Netifera, thought that hkhkhk is an executable file, and because excutable file contains a lot of null bytes so 0x77 may be the null byte in the original file. He suggested xoring the content of hkhkhk against 0x77. We did as he suggested, and it worked :-D. hkhkhk turns out to be an ELF executable file:

$ file hkhkhk
hkhkhk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped

$ ./hkhkhk
./hkhkhk [server] [port]

port> 1111, 2222, ..., 9999

Disassembling hkhkhk reveals that this binary is just a simple client that connects to a remote server to get two integers, and send the sum of them back to that server. If the result is correct (which is always), the server will return a congratulation message like below:

$ ./hkhkhk 1111
[(867925) + (9792)] = ?
answer is 877717
it's correct. great!, :-)
At first, we thought we should try to exploit the server to force it to return an error or something, but that didn't work. Then we thought there's something hidden inside hkhkhk, so superkhung and I spent 1 hour to inspect every single instruction of the binary, but we saw nothing weird.

At this point, a friend suggested us running the binary inside a debugger. He thought that there may be something hidden in the communication between the server and hkhkhk.

The communication? I fired up wireshark, and to my surprise, I saw the answer right away: Pandas likes hkpco XD. It turns out that the congratulation message is something like:
it's correct. great!, :-)\x00Password is "Pandas likes hkpco XD"
This message is passed to a printf call, and since printf expects a null-terminated string, one could never see the characters after the null byte if he doesn't run the binary inside a debugger, or sniff the communication like us.

Challenge 9

Challenge 9 (IP:; port :4600) is a remote stack-based buffer overflow exploitation. It's interesting because WOWHacker doesn't release the binary as other usual exploitation challenges.

While I was banging my head against challenge 8, gamma95 told me that he could crash challenge 9 with 293 bytes. He thought that this challenge is very obvious, and wondered why none was working on it.

Actually we were very short on manpower in the first day of the premilinary round. So we chose to work only on those challenges that we were interested in or had a larger chance of solving them.

When I first saw challenge 9, I thought this challenge should be hard. Blind remote exploitation is supposed to be hard you know. This wrong assumption plus the fact that I haven't practiced software exploitation in the last several months made me decide to leave this challenge for other teamates who might join us in the second day.

But it turns out this challenge is an easy one.

In order to exploit a stack-based buffer overflow vulnerability, one must know which address to return to. Fortunately, WOWHacker gives us a very helpful hint:
Mr.Her give you something "call me~ call me~" : bfbfeaf2
So 0xbfbfeaf2 is the return address. Normally this address should point to the beginning of our input buffer which in turn should have this structure:
The next problem is to determine how many bytes we need to control the EIP. The trick is to use \xeb\xfe as the shellcode, and increase the message one byte a time until we see the service hang after it processes our input. If our theory of the structure of the input buffer is correct, this process will succeed eventually because \xeb\xfe means "loop forever":
$ echo -ne '\xeb\xfe' | ndisasm -
00000000 EBFE jmp short 0x0
Using this technique, we can see that we need totally 302 bytes to control the EIP:
$ (python -c 'print "\xeb\xfe" * 149 + "\xf2\xea\xbf\xbf"'; cat) | nc 4600
We use Metasploit to generate a BSD reverse-shell shellcode, and we got the answer: WOWHACKER without beist.

Actually this wasn't as easy as we write here. We made two stupid mistakes: first off, we assumed that this challenge ran on a Linux box; secondly, our connect back box was behind a firewall :-(. Thanks Tora and biest for giving us a hand in resolving them.

Tuesday, August 25, 2009

Web Hacking Challenge - WOWHacker CTF

This post is about challenge 8 which made gamma95 and I feel so lost when it comes to web hacking.

Challenge 8 (not accessible atm) is the only web hacking challenge in WOWHacker's CTF. In hindsight it's not very difficult, but in fact it took us almost 1 day to solve it.

This is a classic PHP local file inclusion attack. If you set the parameter ty and the cookie 71860c77c6745379b0d44304d66b6a13 to the same file name, the vulnerable PHP script in challenge 8 would try to include that file. Here's what the code looks like:
$ty = $_GET["ty"];
$page = $_COOKIE["71860c77c6745379b0d44304d66b6a13"];
if ($ty != $page)
echo "Error!";
if (include($ty) != 'OK')
echo "Can't find that page!";

Update: gamma95 has just noticed me this challenge may not be a PHP local file inclusion attack. Maybe it's just a vulnerable readfile call like this:
$ty = $_GET["ty"];
$page = $_COOKIE["71860c77c6745379b0d44304d66b6a13"];
if ($ty != $page)
echo "Error!";
if (file_exists($ty))
echo "Can't find that page!";
For vulnerable scripts like this, the trick is to include files in known location which may contain important information, i.e. Apache httpd's error_log or access_log. As we knew this is a Windows machine, we tried to test our theory by including C:\Windows\system32\drivers\etc\hosts which worked as expected. At this point, we thought we were just moments away from the solution of this challenge, but in fact we were totally stuck for the next several hours.

We went on to guess the location of Apache httpd's log files. We sent hundreds of requests, but none worked. I even downloaded and installed a copy of Apache httpd to understand its directory structure but still no luck. Why it didn't work???

Like challenge 1, it wasn't until we almost gave up on this challenge, we realized the simple fact: we always thought that the web server was Apache httpd while it was IIS actually! Years of abandoning Windows has brainwashed us! What a shame!

The next steps are simple. The default IIS installation would store log files in C:\WINDOWS\system32\LogFiles\W3SVC1\exYYMMDD.log. As the premilinary round started on 2009.08.14, we guess we should include C:\WINDOWS\system32\LogFiles\W3SVC1\ex090814.log which in turn reveals this secret script:
This script asks for a username and password which gamma95 had bypassed it using a trivial SQL injection attack even before I figured out what I should do next. After bypassing the authentication, we obtained the flag which is: Do you know StolenByte???

No we don't know him, but thanks for a nice challenge!

Tuesday, August 18, 2009

Crypto challenges - WOWHacker CTF

Last week team CLGT took part in the WOWHacker CTF. I was in charged of crypto challenges, so I decide to write something about challenge 1 and challenge 10.

1. Challenge 1

Challenge 1 is...crazy hahaha. Only one or two teams could solve it until the author (hello hinehong :-D) gave out a list of 7 hints. I have designed some web-related crypto challenges (which you will see soon ^^) so I think the difficulty of challenge 1 relies on how fast people can guess the meaning of the cookie. It would be easier for the teams if the author sets the cookie as cookie = cipher + "|" + key. BTW, here's my solution.

When you access the link above, you'll see a bunch of javascripts. After decoding those javascripts (which I leave as exercise for readers), you'll see a form whose target is This form accepts a parameter named "hong" which is either true or false. If you set hong=true, the server sends back a cookie like below:

id =pKCdQgyJb4dziUESVUv+5qBIoGwQgL2WB@ae506e

This looks like a base64 encoded string, but it's not. In fact you need to modify it a little bit before you can base64 decode it. This is, as I said previously, why this challenge is hard.

One trick I learn from this challenge is to guess the boundary between key and cipher text, one should try to truncate one character a time and base64 decode the string until he gets an output whose length in bytes is a multiple of 8 or 16, which are common block cipher's block length.

The cookie can be either "cipher + key" or "key + cipher", so one should try the above process in both cases. If you can't find any such output, then you know your theory is wrong, i.e. the cookie is in some other form. Fortunately, my theory is right in this case.

It turns out that the first 32 bytes of the cookie is the cipher text, and the rest 8 bytes is the key. It's a 8-bytes key, so this cookie should be encrypted by DES which is a popular 8-bytes key block cipher. I wrote a small python script to decrypt the it:

>>>from Crypto.Cipher import DES
>>>cookie = 'pKCdQgyJb4dziUESVUv+5qBIoGwQgL2WB@ae506e'
>>> key = cookie[32:]
>>> data = base64.b64decode(cookie[0:32])
>>> des = DES.new(key, DES.MODE_CBC)
>>> des.decrypt(data)

Hmm. I remembered I tried to submit 'wowhacke' to the scoring server, but, of course, it's not the correct answer. Then I wasted the next hour to test various stupid theories to understand what the last 16 bytes of the output are.

It was not until I nearly gave up on this challenge, I realized the obvious: this is mode ECB stupid!!! Why on earth I always thought it's CBC? I changed the mode, and the result is:

>>> des = DES.new(key)
>>> des.decrypt(data)

Remember those '\x03\x03\x03'. You'll see them again in my crypto challenges ;-).

2. Challenge 10

Challenge 10 is cool. In summary, the author sets a RSA private key as a property of a Java object, then he gives out the serialization stream of that object, and asks teams to recover the private key to decrypt a ciphertext.

So the first thing we must do is to understand how Java does serialization. I was never a fan of Java, so this is something completely new to me. But that's why I really enjoy playing capture the flag games. It forces me to learn new thing fast in a very short time.

I spent nearly 1 hour reading the spec, mostly on the object serialization stream protocol. Then I spent one and a half hour starring at my hex editor screen and acting as a binary parser which was, I don't know why I feel that, really fun (later on Tora of SexyPwndas fame showed me a much less painful way to recover the object. Thanks Tora!)

I recovered the RSA private key eventually. How to use it to decrypt the ciphertext in key.txt? While de-serializing the object, you would see that there's a field named tripleDesKey containing a 24-bit string which you can get by base64-decoding the last 32 bytes of the serialized object.

At first I thought I should use the RSA key to decrypt this 24-bit string to get the real tripleDesKey, and uses that key in turn to decrypt key.txt. This hybrid approach is the standard way to do encryption using public key cryptosystem. But you shouldn't expect anything standard in CTF, rite?

It turns out all that tripleDes key and ciphertext are just there to distract me. I have to admit that I don't like challenges giving false trails. You can either give good trails or no trail at all. Giving false trail is a sin :-P.

Anyway, if you look at key.txt, you'll see that its content is a 128-bytes string. 128-bytes = 1024-bit = the size of the modulus in the recovered RSA private key. So this string should be the ciphertext encrypted directly using the RSA private key. Indeed it is!

>>> from M2Crypto.RSA import *
>>> rsa = load_key('my_rsa_key')
>>> data = open('key.bin').read()
>>> rsa.private_decrypt(data, 3)

There's a small minor issue that I intentionally left out. Can you find out what it is and resolve it yourself?

I hope you enjoy reading this. Happy hacking!

Sunday, August 16, 2009


Sau khi mém vào vòng chung kết CodeGate 2009, rồi chỉ lọt vào top 20 của Defcon 2009, lần này, sau 02 ngày thi đấu liên tục, team CLGT đã xuất sắc vượt qua vòng loại của WOWHacker 2009 trong khuôn khổ ISEC 2009!!! vị trí cuối cùng của CLGT là hạng 8/45+ đội.

ISEC là một trong những hội thảo an toàn thông tin lớn nhất châu Á, với sự tài trợ của các cơ quan an ninh đầu não của Hàn Quốc. Năm nay hội thảo có thêm cuộc thi Capture The Flag, do nhóm hacker lừng danh WOWHacker làm ban giám khảo.

Mình sẽ viết tường thuật chi tiết sau. Các báo cáo kỹ thuật có thể xem ở trên trang của team CLGT.

PS: Team CLGT đang tìm mạnh thường quân để tài trợ chi phí cho chuyến sang Hàn Quốc du đấu vòng chung kết vào đầu tháng 9, bạn nào có thông tin liên quan thì vui lòng liên hệ với mình nha. khó khăn lắm đội mới vượt qua vòng loại, nên nếu chỉ vì không đủ tiền mà không đi đấu chung kết thì rất uổng phí.

Sunday, August 2, 2009

này là cloud computing

cái bài này muốn viết lâu rồi, mà lười quá nên không viết, nhưng hôm nay không muốn làm toán nữa, thành ra viết blog trở thành lý do rất tốt để mà chay lười :-P.

tôi thấy hype ở các nước phát triển thường mất vài năm mới đến VN. ví dụ như trào lưu blogging bùng nổ ở nước ngoài vài năm thì mới lan đến VN bằng sự xuất hiện của Yahoo! 360. rồi web 2.0, lùng bùng từ 2003-2004, đến tận 2006-2007 ở xứ mình mới manh nha vài công ty và cá nhân nói và bàn về web 2.0. và bây giờ là cloud computing.

trào lưu nói và bàn về cloud computing bùng nổ trên thế giới khi amazon ra mắt dịch vụ amazon s3 vào tháng 3/2006. và bây giờ, tháng 8/2009, ở VN bắt đầu có nhiều người nói và bàn về cloud computing.

cứ theo cái đà này, tôi dự đoán chắc khoảng 2-3 năm nữa, các dịch vụ micro-blogging như twitter, các dịch vụ location-based gắn với điện thoại như Loopt hay các công nghệ như document-oriented database như CouchDB, MongoDB hay NoSQL mới bắt đầu được bàn tán nhiều ở đây.

nói nhảm đủ rồi, giờ quay về chủ đề chính là cloud computing nha.


tôi bắt đầu sử dụng amazon s3 cũng như các dịch vụ khác của amazon aws từ khoảng cuối 2006 cho đến nay. tôi sử dụng amazon s3 để backup dữ liệu, sử dụng amazon ec2, amazon simpledb để thử nghiệm vài ý tưởng liên quan đến công việc cũng như kinh doanh.

có dạo tôi còn làm một cái search engine nho nhỏ để search nhạc, dùng amazon ec2 để tính toán và amazon s3, simpledb để lưu trữ dữ liệu. tôi cũng là core contributor cho dự án ThruDB, một dự án tiên phong về document-oriented database trên nền cloud computing. đề tài một thesis của tôi cũng là làm về document-oriented database. ngoài ra tôi cũng giới thiệu cloud computing và amazon aws cho nhiều người và công ty khác ở đây, ví dụ như vinapo, công ty phát triển cloud.vn.

tôi giới thiệu dông dài như thế là để chứng minh với người đọc rằng tôi biết về cloud computing. sở dĩ tôi cần phải làm thế là tôi quan sát có nhiều bạn đọc không quan tâm đến lập luận của tôi thế nào, mà chỉ chăm chăm "thằng này là thằng nào vậy". có vẻ như rất nhiều người cho rằng "authority = accuracy", nên tôi đành phải chiều theo số đông vậy.


hôm rồi tôi có đi dự một cái hội thảo nói về cloud computing ở đây. bạn nào có theo đuôi tôi trên twitter thì cũng biết là từ trước khi hội thảo diễn ra, tôi đã tỏ ý nghi ngờ về việc có công ty ở VN đủ sức làm cloud computing.

trong mấy cái tweet của mình, tôi có nói đến cái ý: làm cloud computing khác xa với sử dụng cloud computing. khác ở đây là về độ khó. sử dụng thì rất dễ, ví dụ như tôi nè, chỉ vài dòng code là có thể xài được thôi. nhưng làm được là một chuyện không hề đơn giản tí nào. tôi có đưa ra lý do chính là không có người có đủ năng lực để làm.

làm sao để biết là VN không có người có khả năng làm cloud computing? trước tiên cần phải hiểu rõ là làm cloud computing là làm gì đã. tôi định nghĩa đơn giản thế này: làm cloud computing là lưu trữ và xử lý dữ liệu rất lớn cho rất nhiều người khác với chi phí nhỏ nhất.

để hình dung được chữ "lớn" và "rất nhiều" ở câu vừa rồi, bạn hãy thử tìm một công ty web startup tên tuổi (không thuộc các đại gia) mà _không_ sử dụng dịch vụ của amazon aws. twitter? có. dropbox? có. slideshare? có. cho đến hết tháng 3/2009, riêng amazon s3 đã lưu trữ 50 tỉ object, mỗi object tối đa là 5G.

thế còn "chi phí nhỏ nhất"? đây là điểm mấu chốt quyết định một công ty thành công hay thất bại khi làm cloud computing. tại sao các công ty lại thuê dịch vụ của amazon aws? đơn giản vì giá cả hợp lý. thay vì đầu tư rất nhiều tiền để làm data center, thì sử dụng dịch vụ của amazon aws sẽ tiết kiệm được rất nhiều tiền của và thời gian, và đạt được mục đích mong muốn rất dễ dàng: lưu trữ và xử lý một lượng cực lớn dữ liệu.

lý do thứ hai nhưng cũng không kém phần quan trọng khiến cho các công ty quyết định sử dụng các dịch vụ cloud computing của amazon, google hay microsoft: các đại gia này là những người làm hạ tầng tốt nhất thế giới. khó mà làm tốt hơn họ, nên xài của họ là tốt nhất. đây chính là lợi thế cạnh tranh cực lớn của amazon, google hay microsoft. cũng chính là nguyên nhân khiến cho 3 đại gia này độc chiếm thị phần public cloud computing service.

họ làm hạ tầng tốt nhất với chi phí thấp nhất thế giới. tại sao họ làm được điều đó? đơn giản vì đó là công việc hàng ngày của họ. công việc của amazon là chạy cái amazon.com. với google thì đó là google.com. còn microsoft là microsoft.com hay bing.com. tại sao ibm không làm public cloud computing service? tôi nghĩ một lý do là ibm không có kinh nghiệm trong việc vận hành một hệ thống có độ lớn tương tự như amazon.com hay google.com hay bing.com.

thế làm hạ tầng là làm gì mà khó dữ vậy?

thử tưởng tượng bạn có vài chục ngàn máy chủ, làm sao để nhét được hết chúng vào một cái data center mà vẫn đảm bảo đủ điện năng, máy lạnh, chống sét, chống ẩm và hệ thống mạng thông suốt với tốc độ lớn nhất có thể. sau khi đã giải được bài toán đó, bạn đụng tiếp bài toán thứ hai: ổ cứng của chúng như thế nào, RAM ra sao, CPU loại nào, card mạng ra sao. rồi quy trình quản lý, theo dõi, thay mới, sửa chữa...nói chung là vận hành cái data center đó thế nào. sau khi làm xong cho 1 data center, bạn cần phải nhân 3, nhân 5 lên nữa nha. rõ ràng muốn giải hai bài toán này với chi phi nhỏ nhất cần một đội quân làm phần cứng và data center hàng đầu thế giới.

nhưng đó chỉ mới là vấn đề phần cứng thôi. vấn đề phần mềm còn quan trọng hơn: chạy cái gì, như thế nào trên các máy chủ này? ví dụ như amazon s3, thiết kế và chạy cái đó ra sao, để người ta lưu 50 tỉ object vào mà vẫn không xi nhê gì hết. hay với google là lưu trữ toàn bộ thông tin trên Internet. rõ ràng muốn giải bài toán này một cách hiệu quả nhất thì cần phải có thêm một đội quân phd làm distributed system nữa nha.

rõ ràng chỉ có các đại gia như amazon, google hay microsoft mới có đủ tiền và động lực để nuôi các đội quân hàng khủng này. đó là lý do tôi cho rằng ở VN không có nhân lực có khả năng làm public cloud computing service.


quay trở lại hội thảo cloud computing mà tôi nói ở trên. tôi đánh giá cao việc tổ chức các buổi hội thảo như thế này, bởi bản thân tôi cho rằng cloud computing là một loại hình dịch vụ mà các doanh nghiệp ở VN nên tìm hiểu để có cái nhìn toàn cảnh khi đề ra chiến lược phát triển hệ thống thông tin.

tôi đến trễn nên chỉ nghe được 04 bài nói chuyện sau.

bài đầu tiên là của một anh bên ibm. bài này thì chủ yếu là sales, nên cũng không có gì đáng để nói. àh có một chỗ cần lưu ý, nhiều bạn nghe bài này nhầm tưởng rằng VN mình cũng làm được cloud computing, nhưng thực ra đây là công nghệ của ibm, họ đem qua để bán thôi.

bài thứ hai là của bạn Ngôn. bài này thì tôi nghĩ là phù hợp nhất cho hội thảo này. nên có nhiều bài nói chuyện thế này để mọi người thấy được lợi ích của việc sử dụng cloud computing.

bài thứ ba nói về kỹ thuật sandboxing để "kèm kẹp" các ứng dụng chạy trên cloud service theo hình thức "platform as a service" như google app engine và cloud.vn. bài này là một thảm họa. bạn trình bày không có kỹ năng trình bày và có cảm giác bạn ấy cũng rất lơ tơ mơ về đề tài mà bạn ấy đang nói. ở bên dưới thì tôi xác nhận cái cảm giác này là sự thật.

bài thứ tư nói về một "platform as a service" là cloud.vn của bạn PhươngCSA. bài này thì bạn PhươngCSA thể hiện được sự nhiệt tình của bạn ấy. nhưng đồng thời nó cũng chứng minh được rằng bạn ấy và các cộng sự không hiểu được làm cloud computing là làm gì.

theo thông tin của bạn PhươngCSA thì cloud.vn được chạy trên 6 máy chủ mà vinapo thuê rồi đặt tại data center của VDC, bởi theo ý bạn PhươngCSA "làm cloud computing là đi thuê lại". nội cái này thôi thì thấy đã có rất nhiều ngộ nhận.

nếu bạn theo dõi ngay từ đầu, bạn sẽ thấy tôi nhấn mạnh đến chi phí hiệu quả là một trong những yếu tố quyết định sự thành bại của một nhà cung cấp dịch vụ cloud computing. bởi vì nếu doanh nghiệp tự làm data center và các hệ thống phần mềm kèm theo để lưu trữ và xử lý dữ liệu thì sẽ tốn nhiều tiền hơn, nên họ mới thuê lại để tiết kiệm chi phí và rút ngắn thời gian.

công ty làm cloud computing phải là công ty làm được data center và các hệ thống phần mềm kèm theo với chi phí thấp nhất so với các khách hàng của họ. nếu cloud.vn đi thuê lại của VDC, thì tại sao doanh nghiệp không thuê trực tiếp máy chủ và đường truyền của VDC luôn cho nó rẻ? hay là thuê của Amazon.

"nhưng cloud.vn làm sẵn website, template cho doanh nghiệp luôn mà?". chúng ta đang nói đến dịch vụ cloud computing, chứ không phải dịch vụ thiết kế website cho doanh nghiệp. doanh nghiệp mà cần người khác thiết kế rồi làm website cho thì doanh nghiệp đó cũng chẳng cần phải sử dụng cloud computing làm gì.

ngoài các công ty web startup ra, những khách hàng nào là khách hàng tiềm năng của dịch vụ cloud computing? những khách hàng cần có nhu cầu lưu trữ và xử lý dữ liệu lớn, ví dụ như các ngân hàng, các tập đoàn kinh tế lớn. mà nếu họ đã có nhu cầu đó, thì họ chẳng cần phải nhờ một công ty khác làm giùm website cho họ.

"nhưng cloud.vn còn làm sẵn cả kiến trúc hệ thống để giúp cho doanh nghiệp có thể mở rộng website ra bất kỳ lúc nào mà?". có thật sự như thế không?

thứ nhất, không có cơ sở để tin rằng các bạn cloud.vn hay vinapo có kiến thức vững chắc về hệ thống phân tán. không có ai trong số các bạn ấy có bằng tiến sĩ về lãnh vực này cũng có thể là một lập luận. nhưng điều quan trọng hơn, là những gì các bạn ấy làm là đều dựa trên các tài liệu đã công bố của google về hệ thống của họ. cần phải phân biệt giữa "đọc hiểu sơ sơ" và "sáng tạo ra được".

thứ hai, không có cơ sở để tin rằng các bạn đó có kinh nghiệm trong việc thiết kế hệ thống phân tán. nhắc lại ý bên trên: sở dĩ amazon có khả năng làm cloud computing là vì họ đã làm việc đó hàng ngày, đó là công việc của họ. nếu như các bạn cloud.vn hay vinapo là những người làm ra vnexpress chẳng hạn, tôi sẽ tạm tin là các bạn ấy có kinh nghiệm trong việc thiết kế hệ thống có khả năng phục vụ nhiều người cùng một lúc. có dịch vụ hay phần mềm nào của các bạn ấy đã và đang được rất nhiều người sử dụng không? hình như là không.

nhưng hai lập luận ở trên của tôi cũng chỉ là những suy luận mà thôi, rất có thể các bạn cloud.vn hay vinapo hay vdc là những người rất am hiểu và làm rất tốt về hệ thống phân tán. thời gian sẽ chứng minh. nhưng có một điều mà tôi có thể chứng minh ngay.

sau khi nghe trình bày về cloud.vn, tôi có thử sử dụng dịch vụ này. kết quả là vì tò mò mà tôi đã vô tình làm treo toàn bộ hệ thống cloud.vn của các bạn ấy chỉ với 1 dòng mã python. còn có một bạn khác thì đã đi thẳng vào được cơ sở dữ liệu của cloud.vn. tôi tin là nếu muốn thì bất kỳ ai có chút hiểu biết về an toàn thông tin cũng đều có thể làm treo hay phá hủy toàn bộ hệ thống cloud.vn và megaweb.

"nhưng mấy cái này là vấn đề an toàn thông tin thôi, đâu có liên quan gì đến cloud computing, vả lại các bạn cloud.vn cũng đã nói là họ đang trong quá trình xây dựng mà?". an toàn thông tin, nhất là đối với cloud computing, khi mà dữ liệu khách hàng nằm trong tay của nhà cung cấp dịch vụ, không thể là dạng tính năng "chưa phát triển, để làm sau". chuyện gì sẽ xảy ra nếu như bây giờ một ai đó xâm nhập vào cloud.vn, cấy mã độc vào chương trình của họ?

tại sao google app engine có thể "sandboxing" được các ứng dụng python chạy trên đó rất dễ dàng, còn cloud.vn thì không? đơn giản vì Guido van Rossum, người tạo ra Python, làm việc cho google. như đã nói ở trên, chỉ có google mới có đủ tiền thuê các tay cỡ như Guido và các tay cỡ như Guido cũng chỉ muốn làm cho các công ty như google, nên chỉ có google mới có đủ người để làm cloud computing.

đây cũng là điểm mấu chốt mà tôi đã nhắc đi nhắc lại từ đầu bài: VN không có nhân lực (và tiền) để làm cloud computing.


những lập luận trên đây không nhằm để chỉ trích cloud.vn hay bất kỳ cá nhân nào. điều tôi muốn chia sẻ là cloud computing là sân chơi của các đại gia hàng đầu thế giới, các doanh nghiệp ở VN chỉ nên nghĩ đến cách tận dụng các dịch vụ này, hơn là phát triển các dịch vụ cạnh tranh.