1. Środowisko
2. Modyfikacje dokonane przez włamywacza
3. Analiza modyfikacji
4. Jak dokonano włamania
5. Naprawa

Środowisko

Zgodnie z regułami gry, regularnie dbałem o aktualizacje WordPress’a, zainstalowanych wtyczek i skórki. Wszystkie nieużywane komponenty były wywalane z bloga, by nie korciło kogoś eksperymentowanie np. z nieaktywną skórką czy wtyczką.

Logowanie do bloga było zabezpieczone m.in. przez mechanizm obrazków z losowymi literkami, hasła nasto-znakowe były generowane losowo, zawierając litery, cyfry, znaki specjalne… Zabezpieczenie obrazkiem ma swoją istotną zaletę- widziałem nie raz w logach całe serie prób logowania się metodą brute-force, w ciągu sekundy można wysłać do serwera nawet kilka takich żądań- bywa, że w ciągu godziny atakujący testuje parę tysięcy haseł. Przy zabezpieczeniach z SSL, z obrazkami- gwałtownie spada ilość prób i tempo tych prób. Zainteresowanym polecam przyjrzenie się temu tematowi- są np. wtyczki, które po kilku nieudanych próbach robią czasową blokadę IP, albo wprowadzają wydłużający się czas między kolejnymi próbami logowania.

Skórka została dobrana tak, by nie zawierała pliku “thumb.php” ani “timthumb.php” (wykorzystywane do generowania miniaturek), które dawno i wielokrotnie były kompromitowane i które są właściwie głównie wrzodem…. Wtyczki były dobrane wg oceny dbania o nie przez autorów i popularności, sprawdzałem je też we własnym zakresie pod kątem jakichś dziwnych skryptów, które mogłyby ułatwić komuś zrobienie włamu. Ponadto, w katalogu głównym bloga – jak w przypadku wszystkich stron i blogów, którymi zarządzam- zmodyfikowałem plik “.htaccess”, dodając sporo reguł zabezpieczających blog- choćby takie, które nie pozwalają by jakikolwiek plik bloga (pliki PHP, pliki JS) mógł ściągnąć jakąkolwiek treść z zewnątrz- spoza bloga. W dużej mierze przydatne okazały się artykuły na WordPress.org poświęcone bezpieczeństwu blogów, a także- co muszę przyznać z dużym naciskiem- artykuły na PerishablePress.Com- szczególnie te związane z budową “firewall’a” dla stron w oparciu o pliki “.htaccess” (zachęcam do zerknięcia do artykułu “5G Blacklist 2012“, a także “Protect Your Site with a Blackhole for Bad Bots“)

Modyfikacje dokonane przez włamywacza

Pomimo to- dostałem wiadomość od firmy hostingowej, iż system antywirusowy znalazł “niebezpieczne pliki” w obrębie bloga. (Całe szczęście, firma hostingowa ma dobre narzędzia do skanowania plików, regularne skanowanie plików w poszukiwaniu wirusów w PHP/JS i innych typach plików to ostatnia deska ratunku). Natychmiast zabrałem się za sprawdzenie, co to za pliki, gdzie, dlaczego, kiedy, kto……

Włamywacz w głównym katalogu, oraz w kilku innych katalogach zmodyfikował pliki “.htaccess“. Dla tych którzy nie wiedzą- pliki te zawierają kluczowe dyrektywy dla serwera WWW. Pliki “.htaccess” mają bardzo duże znaczenie dla bezpieczeństwa strony.

Do plików .htaccess dodano klauzule:

< IfModule mod_php5.c>
 php_value auto_append_file "google_verify.php"
< /IfModule>

< IfModule mod_php4.c>
 php_value auto_append_file "google_verify.php"
< /IfModule>

 Te klauzule “auto_append_file” są niezwykle niebezpieczne- oznaczają, że DO KAŻDEGO PLIKU dołączany jest na końcu plik “google_verify.php“. Haker nie musi modyfikować istniejących plików/skryptów, po prostu dołącza złośliwy kod na każdej naszej stronie, elemencie…

Analiza modyfikacji

Oczywiście, w miejscach w których zmieniono “.htaccess” dodano plik “google_verify.php”. I nie był to bynajmniej plik “hello ”- to był plik zawierający dość mocno zamaskowany kod skryptu. Nie jestem programistą- próbowałem zdekodować ten tekst i zrozumieć, jak działa, ale zmarnowałem sporo czasu i do niczego nie doszedłem. W końcu zwróciłem uwagę na interesującą rzecz- na komentarze. Były po łacinie…

Początkowo myślałem, że zabiorę się za ich tłumaczenie, bo może one opisują elementy kodu infekującego przeglądarki. Ale natychmiast po wpisaniu fragmentu komentarza w wyszukiwarce trafiłem na artykuł, który wszystko wyjaśnił.

Wpisałem tą frazę do Google:

google_verify.php  //Mauris gravida, libero ut tempor ultricies, ante erat blandit dui, vestibulum convallis ligula lacus et metus. Duis quis nunc justo, gravida sem

I od razu pierwsza pozycja w wynikach. Na stronie Unmask Parasites. Blog. opisano podobne przypadki. Autor wyjaśnia, że łaciński tekst pochodzi z generatorów typu Lorem Ipsum- więc jasne jest, że tłumaczenie komentarzy w skrypcie jest stratą czasu.

Poza tym, na wspomnianej stronie opisana jest zasada działania skryptu doklejanego do zhakowanej strony (skrypt próbuje infekować przeglądarkę odwiedzających – w udanych wypadkach zamienia komputer odwiedzającego w zombie i element botnetu, wykorzystywanego albo do kolejnych włamań albo np. do generowania maili).

W jednym z katalogów – poza plikiem infekującym przeglądarki- wrzucono skrypt PHP z backdoor‘em- tworzący shell’a (czyli wejście do systemu bez wiedzy/kontroli administratora, pozwalający na wykonanie każdego polecenia dostępnego na serwerze z poziomu linii komend).

W pliku z backdoor’em na początku skryptu jest komentarz:

# Web Shell by oRb

 Analiza backdoor’a sama w sobie była interesującym zajęciem. To nie pierwszy backdoor jakiego widziałem, muszę jednak przyznać, że na tle innych ten jest dość zaawansowany i daje bardzo duże możliwości włamywaczowi.

Pliki “.htaccess” i “google_verify.php” były w kilku egzemplarzach- w głównym katalogu strony, w katalogach trzech różnych wtyczek, w dwóch innych katalogach w obrębie bloga. Plik z backdoor’em / shell’em był jeden.

I ważna informacja, jaką muszę tu podać- pliki, które zostały dodane- miały bieżące daty, z momentu wgrywania ich na serwer. To ważny element- gdyby włamywacz zmienił po swojej akcji daty wgranych plików na takie daty/godziny, jak pozostałe pliki w katalogach- wyszukanie tych plików byłoby znacznie trudniejsze.

Poza tym- niczego więcej nie zmieniono. W zasadzie nie było konieczności- jak wyżej napisałem- mechanizm “auto_append_file” po prostu dokleja wszędzie plik “google_verify.php”, włamywacz nie musi niczego więcej zmieniać. A backdoor jest potrzebny- na wszelki wypadek, gdyby trzeba było ponownie infekować stronę (dla ułatwienia w przyszłości), albo gdyby włamywacz chciał rozszerzyć zakres swojej działalności – użyć serwera do innych celów poza atakowaniem przeglądarek odwiedzających osób. Np. do mailingu, do zamiany serwera w warez/składnicę nielegalnych czy zainfekowanych plików etc.

Jak dokonano włamania

Z grubsza wiedziałem już co zostało zmienione, najwięcej czasu spędziłem na odkrycie tego “JAK“. Przekopywałem się przez pliki “.htaccess”, WordPress’a, wtyczek, skórki- ale niczego nie znalazłem, żadnej luki pozwalającej na tak poważne modyfikacje. Zalinkowany wyżej artykuł doczekał się niedawno aktualizacji, w artykule z 18 lutego Autor wskazuje, iż popularną drogą do infekcji jest włam przez FTP. No i…. mamy go!

Nie wiem czemu nie wpadłem na to wcześniej. To prawdopodobnie zbyt duże zaufanie do siebie lub innych, albo za małe przywiązanie wagi do tej drogi dostępu do serwera- to dobra nauczka i dla mnie, i dla Czytelników- każdy kanał dostępu do serwera trzeba sprawdzić, sprawdzać, sprawdzać…. Obejrzałem logi dla wszystkich kont FTP założonych na serwerze i okazało się, że jedno z nich, nazwijmy je ‘kontraktor’, było w użyciu dokładnie w momencie, gdy zostały wrzucane złośliwe pliki na serwer. Sprawdziłem IP z jakich logowano się na to konto – adres pochodził z sieci kablowej w USA, w Pensylwanii. Oczywiście, prawdopodobnie z jakiegoś komputera typu zombie. Jak można się domyślić, użytkownik konta ‘kontraktor’ nie był w tym czasie w USA, w stanie Pensylwania…

Niestety pełnych logów z FTP nie mam- nie mam informacji o nieudanych próbach logowania. Nie wiadomo więc, czy logowanie nastąpiło po jakimś czasie, po dziesiątkach prób i ataków typu brute-force (lub wykorzystaniu jakiejś luki w serwerze FTP), czy może na komputerze ‘kontraktora’ był trojan przechwytujący hasła- a jak grupa hakerów uzyskała login/hasło do nieznanego im wcześniej serwera FTP- po prostu “w ciemno” zalogowała się i uruchomiła odpowiednie skrypty przejmujące kontrolę nad nieznaną im stroną. Informacja jak uzyskano wejście przez FTP byłaby interesująca. Na razie nie wiem jednak tego, zabezpieczenie istniejących kont FTP i ograniczenie grona osób, które korzystają z tej formy dostępu, jest jedynym w tej sytuacji rozwiązaniem.

Naprawa

Zanim natrafiłem na artykuł wykonałem już parę kroków, tj:

• usunięcie z plików “.htaccess” dyrektyw “auto_append_file”
• usunięcie plików “google_verify.php”
• usunięcie pliku z backdoor’em / shell’em
• w każdym katalogu- na wszelki wypadek- zmieniłem uprawnienia dla plików “.htaccess”, “index.php” lub “index.html”
• w katalogach można wyłączyć przeglądanie ich zawartości w przeglądarce (dyrektywa “Options All -Indexes” w pliku “.htaccess”) – dyrektywa wyłącza możliwość wyświetlenia w przeglądarce listy plików w danym katalogu
• pliki .htaccess można dodatkowo zabezpieczyć przed modyfikacją ich przez serwer WWW, dyrektywami:

  # SECURE HTACCESS
  <Files .htaccess>
   Order allow,deny
   Deny from all
  </Files>
  

• oczywiście, kolejną sprawą po zapoznaniu się z artykułem było zablokowanie konta FTP dla ‘kontraktora’- i na wszelki wypadek- zmiany hasła na jakieś ekstremalnie skomplikowane. Jeśli w przyszłości będzie potrzebny dostęp przez FTP- opracuję jakiś system haseł jednorazowych (OTP) lub inną formułę zabezpieczającą ten kanał dostępu.

W artykule (w aktualizacji z 18 lutego) są opisane kroki potrzebne do przywrócenia strony do jej oryginalnego stanu. Jest tam też sporo innych przydatnych informacji dotyczących włamań przy użyciu metody, z którą właśnie się zetknąłem.

I na koniec- podsumowując: każdy kij ma dwa końce. Włamanie to poważny problem. Możemy stracić ważne dane, ważną treść nad którą pracowaliśmy latami. Stronę, która ma wysoki PR i jest dobrze rozpoznawana w Internecie. Może skończyć się zablokowaniem usług, z których korzystamy- firma hostująca może nam podziękować bez zwrócenia pieniędzy za niewykorzystany okres świadczenia usług. W końcu łamiemy zasady, mamy wirusy na stronach etc. Z drugiej strony- to nauka, walka o przetrwanie… jak w rozprawie Darwina o ewolucji gatunków- przetrwają ci, którzy lepiej się dostosują do sytuacji. Dotyczy to także walki hacker-Ty i Twoje usługi. Oczywiście, możesz też zrzucić obowiązki na jakąś firmę zewnętrzną, samemu dbając tylko o treść na blogu- resztę (czyli kwestie bezpieczeństwa) przerzucając na innych. To jest pewne wyjście, ale może kosztować jakąś kwotę pieniędzy.

I jeszcze ostatnia, bardzo ważna uwaga- ten typ włamania nie jest związany konkretnie z WordPressem. To może dotyczyć KAŻDEJ strony, wykorzystującej PHP, do której można dostać się albo przez FTP, albo przez wykorzystanie jakiejś luki i wgranie odpowiednich plików na serwer.

Jeśli ktoś spotkał się z podobnym typem włamu/mechanizmem/skryptami- proszę o kontakt albo uwagi w komentarzach pod postem.

Zapraszam:
The Best Way to Build a Cloud

Zapraszam na aukcje!

Zapraszam na aukcje!

Np. adres 80.239.22.30 można przedstawić jako 4-bajtową wartość 1357846046.

Oto formuła do takich przeliczeń:

=((WARTOŚĆ(LEWY(B2; ZNAJDŹ("."; B2)-1)))*256^3)+((WARTOŚĆ(FRAGMENT.TEKSTU(B2; ZNAJDŹ("."; B2)+1; ZNAJDŹ("."; B2; ZNAJDŹ("."; B2)+1)-ZNAJDŹ("."; B2)-1)))*256^2)+((WARTOŚĆ(FRAGMENT.TEKSTU(B2; ZNAJDŹ("."; B2; ZNAJDŹ("."; B2)+1)+1; ZNAJDŹ("."; B2; ZNAJDŹ("."; B2; ZNAJDŹ("."; B2)+1)+1)-ZNAJDŹ("."; B2; ZNAJDŹ("."; B2)+1)-1)))*256)+(WARTOŚĆ(PRAWY(B2; DŁ(B2)-ZNAJDŹ("."; B2; ZNAJDŹ("."; B2; ZNAJDŹ("."; B2)+1)+1))))

Dość długa- ale działa

Oczywiście, zamiast pisać ogromniaste i bezsensowne formuły, pomyślałem o zastosowaniu wyrażeń regularnych- w świecie *nixów, BSD i ruterów w którym żyję to chleb powszedni.

Chwila zastanowienia i przejrzenia paru stron logów- wychodzi mi, że do wyszukania języka przeglądarki powinienem zastosować takie wyrażenie:

“;[ ]?[a-z][a-z](-[A-Z][A-Z]|;|\))”

(dla jasności- tekst opisujący język przeglądarki wyglądał w logach w taki sposób:

• ;pl;
• ;en-US)
• ; en-GB;
• ; zh-CN)

Czasem po średniku była spacja, czasem nie. Czasem był to ostatni kawałek w tekście User-Agent i po nim następował nawias zamykający, czasem był to średnik i kolejna porcja informacji UA. Czasem- jak w przypadku pl- był to tekst jednoczłonowy, czasem- jak w przypadku en- dwuczłonowy (ze względu na odmiany języka). Nie muszę dodawać, że nie ma określonej pozycji w tekście, w której taki tekst się pojawia. CZASEM W OGÓLE SIĘ NIE POJAWIA, bo zazwyczaj boty nie wstawiają informacji o języku, a niektóre skrypty (np. libwww) w ogóle nie umieszczają informacji o UA

Jak ktoś mi napisze formułę w Excelu bez użycia RegExp do wyszukania takiej informacji krótszej niż 1000 znaków- stawiam skrzynkę piwa i oczywiście opublikuję ją tu na stronie

No a wracając do RegExp, wszystko fajnie, formuła w głowie się pojawiła, ale jak ją użyć… na szczęście Wujek Google podpowiedział parę rzeczy i podrzucił fajny dokument w Wordzie z kilkoma przykładami.

Funkcja TestRegExp wyszukuje określony tekst w łańcuchu i wyświetla ilość powtórzeń i ich pozycje:

Function TestRegExp(myPattern As String, myString As String) As String
Dim objRegExp    As Object
Dim objMatch     As Object
Dim colMatches   As Object
Dim RetStr       As String
Set objRegExp = CreateObject("VBScript.RegExp")
   objRegExp.Pattern = myPattern
   'ignorowanie wielkości liter
   objRegExp.IgnoreCase = True
   'czy szukać wszystkich wyników czy tylko pierwszego
   objRegExp.Global = True
    'czy ciąg można porównać.
    If objRegExp.test(myString) = True Then
        Set colMatches = objRegExp.Execute(myString)
        For Each objMatch In colMatches
            RetStr = RetStr & "pozycja: " & objMatch.FirstIndex & _
                              " dopasowanie: " & objMatch.Value & _
                              " długość: " & objMatch.Length & Chr(10)
        Next
   Else
        RetStr = ""
   End If
   TestRegExp = RetStr
Set objRegExp = Nothing
Set colMatches = Nothing
End Function

Dalszy krok- funkcja WytnijRegExp:

Function WytnijRegExp(myString As String, myPattern1 As String) As String
Dim objRegExp    As Object
Dim objMatch     As Object
Dim colMatches   As Object
Dim RetStr       As String
Set objRegExp = CreateObject("VBScript.RegExp")
   objRegExp.Pattern = myPattern1
   'ignorowanie wielkości liter
   objRegExp.IgnoreCase = True
   'czy szukać wszystkich wyników czy tylko pierwszego
   objRegExp.Global = True
    'czy ciąg można porównać.
    If objRegExp.test(myString) = True Then
        RetStr = objRegExp.Replace(myString, "")
   Else
        RetStr = ""
   End If
   WytnijRegExp = RetStr
Set objRegExp = Nothing
Set colMatches = Nothing

End Function

I jeszcze jedna przydatna do tych celów funkcja – SzukajRegExp:

Function SzukajRegExp(myString As String, myPattern As String) As String
Dim objRegExp    As Object
Dim objMatch     As Object
Dim colMatches   As Object
Dim RetStr       As String
Set objRegExp = CreateObject("VBScript.RegExp")

   objRegExp.Pattern = myPattern
   'ignorowanie wielkości liter
   objRegExp.IgnoreCase = False
   'czy szukać wszystkich wyników czy tylko pierwszego
   objRegExp.Global = True
    'czy ciąg można porównać.
    If objRegExp.test(myString) = True Then
        Set colMatches = objRegExp.Execute(myString)
        For Each objMatch In colMatches
            RetStr = RetStr & objMatch.Value
        Next
   Else
        RetStr = ""
   End If
   SzukajRegExp = RetStr

Set objRegExp = Nothing
Set colMatches = Nothing

End Function

Funkcje te trzeba wpisać w Edytorze VisualBasic (Microsoft Visual Basic for Applications). Mając te funkcje można w komórce napisać:

=JEŻELI(CZY.BŁ(ZNAJDŹ("(";B2));"";szukajregexp(FRAGMENT.TEKSTU(B2;ZNAJDŹ("(";B2);500);";[ ]?[a-z][a-z](-[A-Z][A-Z]|;|\))"))

(dla jasności- nie chciałem przekopywać się przez cały łańcuch UA, wyszukuję więc pierwszy nawias- jeśli istnieje- i dopiero w tekście rozpoczynającym się od nawiasu wyszukuję łańcuch odpowiadający wyrażeniu regularnemu).

Wynik warto jeszcze oczyścić- zawiera średnik (średniki) lub nawias zamykający. Ale to już detal. Dopisałem sobie taką funkcję:

Function Cleaner(inputstring As String) As String
Dim Tmp As String
Dim i As Integer

Tmp = inputstring
Tmp = Application.Substitute(Tmp, ";", "")
Tmp = Application.Substitute(Tmp, ")", "")
Tmp = Application.Substitute(Tmp, " ", "")

Cleaner = Tmp
End Function

To prosta funkcja, kasuje średniki, nawiasy zamykające i spacje. Dzięki niej poprawiłem formułę, wygląda tak:

=JEŻELI(CZY.BŁ(ZNAJDŹ("(";B2));"";cleaner(szukajregexp(FRAGMENT.TEKSTU(B2;ZNAJDŹ("(";B2);500);";[ ]?[a-z][a-z](-[A-Z][A-Z]|;|\))")))

Mamy już piękne wyniki- en-US, pl, zh-CN bez zbędnych śmieci…

To teraz czas na kolejne wyzwanie. Zakładając że Referrer pochodzi od wyszukiwarek (np. Google)- zazwyczaj zapytanie zawiera łańcuch typu “&q=wyszukiwany+tekst“, lub “?q=wyszukiwany+tekst“. URLe kodowane są za pomocą funkcji URLEncode- trzeba więc użyć funkcji odwrotnej- URLDecode, by wyszukiwany tekst był czytelny.

Wyszukanie powyższych łańcuchów bez RegExp to katastrofa. Stosując RegExp możemy szukać łańcucha “(&|\?)q=[^&]+“:

=szukajregexp(B2;"(&|\?)q=[^&]+")

Z wyniku trzeba wywalić pierwsze trzy znaki (tj “?q=” lub “&q=”), a pozostały tekst przekonwertować funkcją URLDecode. O- taką funkcję trzeba najpierw napisać w Edytorze (w sieci można znaleźć wiele różnych wariantów, użyłem jednego z nich):

Public Function URLDecode(sEncodedURL As String) As String

On Error GoTo Catch

Dim iLoop   As Integer
Dim sRtn    As String
Dim sTmp    As String

If Len(sEncodedURL) > 0 Then
    ' Loop through each char
    For iLoop = 1 To Len(sEncodedURL)
        sTmp = Mid(sEncodedURL, iLoop, 1)
        sTmp = Replace(sTmp, "+", " ")
        ' If char is % then get next two chars
        ' and convert from HEX to decimal
        If sTmp = "%" And Len(sEncodedURL) + 1 > iLoop + 2 Then
            sTmp = Mid(sEncodedURL, iLoop + 1, 2)
            sTmp = Chr(CDec("&H" & sTmp))
            ' Increment loop by 2
            iLoop = iLoop + 2
        End If
        sRtn = sRtn & sTmp
    Next
    URLDecode = sRtn
End If

Finally:
    Exit Function
Catch:
    URLDecode = ""
    Resume Finally
End Function

Mając tą funkcję możemy zmienić formułę wyszukującą teksty w kwerendach:

=urldecode(FRAGMENT.TEKSTU(B2;ZNAJDŹ("=";B2)+1;500)))

No i mamy to co chcieliśmy. A przy okazji mamy parę funkcji w VBA, które może kiedyś się do czegoś innego przydadzą…

Zapraszam na aukcje!

The New generic Top-Level Domain Program was developed to increase competition and choice by introducing new gTLDs into the Internet’s addressing system.

What is a gTLD? It is an Internet domain name extension such as the familiar .com, .net, or .org. There are roughly two dozen gTLDs now, but soon, there could be hundreds.

Learn more about the program and the history behind it.

Na stronie jest mnóstwo materiałów do ściągnięcia. Przydadzą się nie tylko domeniarzom- ale także (albo raczej przede wszystkim) wielkim korporacjom czy inwestorom.

Na stronie jest oczywiście zbiór linków kontaktowych (w tym obsługa klienta), jest też zbiór wiadomości ostatnio publikowanych przez ICANN. Warto dorzucić sobie stronę do bookmarków.

Oczywiście, oficjalnie Google twierdzi, że to dlatego że już od ponad 90 dni usługa jest testowana i że teraz to już chcieliby udostępnić ją wszystkim. Ale pewnie jest jeszcze inny powód- po wielkim szale i zainteresowaniu usługą na początku (ogromna ilość nowych użytkowników w ciągu pierwszych dni serwisu, kiedy jeszcze trzeba było mieć zaproszenie żeby tam się dostać) w ostatnich tygodniach mówiło się o dużym spadku zainteresowania usługą. Pewnie brak możliwości zakładania kont bez zaproszenia powodował stagnację- brak userów=brak interakcji, dyskusji, chęci angażowania się w serwis => w efekcie znudzenie projektem. Więc teraz pewnie Google czeka na nową falę userów- żeby z powrotem przywrócić zainteresowanie Kręgami… Dla przypomnienia- to właśnie kręgi i bezpieczeństwo były (i są) dalej mocnymi stronami serwisu i powodem zazdrości ze strony Facebooka. FB w ostatnim czasie kopiował niektóre z cech Google Plusa (np. ustawienia bezpieczeństwa, FB zaczął także wdrażać koncepcję grup- podobną do koncepcji Kręgów w G+).

Jestem ciekaw, jak to się skończy. Fajnie by było, gdyby jakiś serwis rozwalił hegemonię i monopol FB na świecie – FB trochę się już niektórym przejadło…

• A Brave New (Security) World – How Security is Changing to Support Virtualization and Cloud Computing – by Eva Chen for Trend Micro
• Evaluating Storage Technologies for Virtual Server Environments – by Russ Fellows
• Extending IT Governance – From Private to Hybrid Clouds through Consistency and Portability – by Gordon Haff
• Fast Facts for the Hybrid Cloud – Microsite Offer
• Five Myths of Cloud Computing
• Platform-as-a-Service – Private Cloud with Oracle Fusion Middleware
• Weaving the Hybrid Cloud – by Taneja Whitepaper