Merhaba, bu makalede ek (attachment) kabul eden web servislere uygulanabilecek atak vektörleri üzerine bir inceleme yapacağız. Burada tehlike web servislerinin ek dosyayı sunucu üzerinde işlerken ve bu dosyaların istemcilere dağıtılırken yaşanmaktadır.
İçerisinde zararlı yazılım barındırabilen döküman tipinde olan yada çalıştırılabilir dosyalar web servisler aracılığı ile çeşitli şekillerde gönderilebilirler. Bu dosyalar bir web servis metodunun parametresi olarak gönderilebilirler. (Bkz : Direct Internet Message Encapsulation, DIME - http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation)
Saldırgan zararlı yazılım içeren bir dosyayı bir soap mesajının içeriğine attachment gömerek gönderebilir. Bu durumun web servis test planı içerisinde göz önünde bulundurulması gerekmektedir. Web servisin soap ek dosyaları alıp almadığı denetlenmelidir.
Öncelikle parametre olarak dosya alımında yapılacak denetimi inceleyelim. Bu durumun uygulaması için öncelikle attachment kabul eden bir WSDL bulunmalıdır.
(WSDL için bkz : http://en.wikipedia.org/wiki/Web_Services_Description_Language)
Aşağıdaki WSDL örneği bizim için uygun olacaktır. Sizde attachment alan bir web servis uygulamasını Visual Studio kullanarak kolaylıkla hazırlayabilirsiniz. Ben testlerimi Visual Studio 2012 Web Service Enhancement V.2 sp3 kullanarak gerçekleştirdim.
... <s:element name="UploadFile">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="filename" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="type" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="chunk" type="s:base64Binary" />
<s:element minOccurs="1" maxOccurs="1" name="first" type="s:boolean" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="UploadFileResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="UploadFileResult" type="s:boolean" />
</s:sequence>
</s:complexType>
</s:element> ...
Bu WSDL örneğini kullanan web servis metoduna ilgili attachment dosyasını soap parametresi olarak gönderebileceğiz. Bununla ilgili serviste attachment denetimi yapılıp yapılmadığını öğrenmiş olacağız. Bunun için zararsız virüslerden olan ve antivirüs test dosyası olarakta nitelendirebileceğimiz EICAR test dosyasını kullanacağız. EICAR hakkında detaylı bilgiyi http://en.wikipedia.org/wiki/EICAR_test_file adresinden edinebilirsiniz. Bu dosyayı kullanmamızın sebebi, testlerimizi yaparken de sistemlerimize zarar vermemektir.
Base64 olarak EICAR dosyasını post ediyoruz. Dosya UploadFile tagi arasında tanımlanmıştır. Base64 verisini de chunk tagi arasında görebilirsiniz.
POST /Service/Service.asmx HTTP/1.1
Host: somehost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: http://somehost/service/UploadFile
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<UploadFile xmlns="http://somehost/service">
<filename>eicar.pdf</filename>
<type>pdf</type>
<chunk>X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*</chunk>
<first>true</first>
</UploadFile>
</soap:Body>
</soap:Envelope>
Geriye response olarak UploadFile parametresinden true olarak dönüş aldık. Bunun servisten servise değişebileceğini Owasp kaynaklarından öğreniyoruz. EICAR test virüsü dosyamıza izin verildi ve PDF olarak dağıtımı yapılabilir demektir.
Şimdi ise parametre olarak değil attachmentı doğrudan post ediyoruz :
POST /insuranceClaims HTTP/1.1
Host: www.risky-stuff.com
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<claim061400a.xml@claiming-it.com>"
Content-Length: XXXX
SOAPAction: http://schemas.risky-stuff.com/Auto-Claim
Content-Description: This is the optional message description.
312
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<claim:insurance_claim_auto id="insurance_claim_document_id"
xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim">
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/>
<theCrashPhoto href="cid:claim061400a.jpeg@claiming-it.com"/>
<!-- ... more claim details go here... -->
</claim:insurance_claim_auto>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: base64
Content-ID: <claim061400a.tiff@claiming-it.com>
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.jpeg@claiming-it.com>
...Raw JPEG image..
--MIME_boundary--
Evet gene aynı şekilde test dosyasının uzak sunucuda saklanmasına izin verildi ve TIFF dosyası olarak dağıtımı yapılabilir. Testini yaptığım uygulamaların kaynak kodlarını yakın zamanda paylaşmayı planlıyorum. Uygulamalarda yukarıda belirttiğim gibi asp.net web servisleri ve web service enhancement v2 sp3 kullanılmıştır. Uygulamanın geliştirme adımlarını da başka bir kısa makale de paylaşıyor olacağım.
Caner Özden
Referanslar :
Owasp Testing Guide v3 - NAUGHTY SOAP ATTACHMENTS (OWASP-WS-006)
http://www.eicar.org/86-0-Intended-use.html
http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation
İçerisinde zararlı yazılım barındırabilen döküman tipinde olan yada çalıştırılabilir dosyalar web servisler aracılığı ile çeşitli şekillerde gönderilebilirler. Bu dosyalar bir web servis metodunun parametresi olarak gönderilebilirler. (Bkz : Direct Internet Message Encapsulation, DIME - http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation)
Saldırgan zararlı yazılım içeren bir dosyayı bir soap mesajının içeriğine attachment gömerek gönderebilir. Bu durumun web servis test planı içerisinde göz önünde bulundurulması gerekmektedir. Web servisin soap ek dosyaları alıp almadığı denetlenmelidir.
Öncelikle parametre olarak dosya alımında yapılacak denetimi inceleyelim. Bu durumun uygulaması için öncelikle attachment kabul eden bir WSDL bulunmalıdır.
(WSDL için bkz : http://en.wikipedia.org/wiki/Web_Services_Description_Language)
Aşağıdaki WSDL örneği bizim için uygun olacaktır. Sizde attachment alan bir web servis uygulamasını Visual Studio kullanarak kolaylıkla hazırlayabilirsiniz. Ben testlerimi Visual Studio 2012 Web Service Enhancement V.2 sp3 kullanarak gerçekleştirdim.
... <s:element name="UploadFile">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="filename" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="type" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="chunk" type="s:base64Binary" />
<s:element minOccurs="1" maxOccurs="1" name="first" type="s:boolean" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="UploadFileResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="UploadFileResult" type="s:boolean" />
</s:sequence>
</s:complexType>
</s:element> ...
Bu WSDL örneğini kullanan web servis metoduna ilgili attachment dosyasını soap parametresi olarak gönderebileceğiz. Bununla ilgili serviste attachment denetimi yapılıp yapılmadığını öğrenmiş olacağız. Bunun için zararsız virüslerden olan ve antivirüs test dosyası olarakta nitelendirebileceğimiz EICAR test dosyasını kullanacağız. EICAR hakkında detaylı bilgiyi http://en.wikipedia.org/wiki/EICAR_test_file adresinden edinebilirsiniz. Bu dosyayı kullanmamızın sebebi, testlerimizi yaparken de sistemlerimize zarar vermemektir.
Base64 olarak EICAR dosyasını post ediyoruz. Dosya UploadFile tagi arasında tanımlanmıştır. Base64 verisini de chunk tagi arasında görebilirsiniz.
POST /Service/Service.asmx HTTP/1.1
Host: somehost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: http://somehost/service/UploadFile
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<UploadFile xmlns="http://somehost/service">
<filename>eicar.pdf</filename>
<type>pdf</type>
<chunk>X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*</chunk>
<first>true</first>
</UploadFile>
</soap:Body>
</soap:Envelope>
Geriye response olarak UploadFile parametresinden true olarak dönüş aldık. Bunun servisten servise değişebileceğini Owasp kaynaklarından öğreniyoruz. EICAR test virüsü dosyamıza izin verildi ve PDF olarak dağıtımı yapılabilir demektir.
Şimdi ise parametre olarak değil attachmentı doğrudan post ediyoruz :
POST /insuranceClaims HTTP/1.1
Host: www.risky-stuff.com
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<claim061400a.xml@claiming-it.com>"
Content-Length: XXXX
SOAPAction: http://schemas.risky-stuff.com/Auto-Claim
Content-Description: This is the optional message description.
312
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<claim:insurance_claim_auto id="insurance_claim_document_id"
xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim">
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/>
<theCrashPhoto href="cid:claim061400a.jpeg@claiming-it.com"/>
<!-- ... more claim details go here... -->
</claim:insurance_claim_auto>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: base64
Content-ID: <claim061400a.tiff@claiming-it.com>
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.jpeg@claiming-it.com>
...Raw JPEG image..
--MIME_boundary--
Evet gene aynı şekilde test dosyasının uzak sunucuda saklanmasına izin verildi ve TIFF dosyası olarak dağıtımı yapılabilir. Testini yaptığım uygulamaların kaynak kodlarını yakın zamanda paylaşmayı planlıyorum. Uygulamalarda yukarıda belirttiğim gibi asp.net web servisleri ve web service enhancement v2 sp3 kullanılmıştır. Uygulamanın geliştirme adımlarını da başka bir kısa makale de paylaşıyor olacağım.
Caner Özden
Referanslar :
Owasp Testing Guide v3 - NAUGHTY SOAP ATTACHMENTS (OWASP-WS-006)
http://www.eicar.org/86-0-Intended-use.html
http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation
YanıtlaSilDoes your website have m.scr888 casino download 4.0 a contact page? I'm having trouble locating it but, I'd like to shoot you an e-mail. I've got some ideas for your blog you might be interested in hearing. Either way, great blog and I look forward to seeing it improve over time. The Gaming Club bears a license from the direction of Gibraltar, and claims to be one of a select few casinos that have a license from the Gibraltar government. A supporter of the Interactive Gaming Council (IGC), The Gaming Club follows every the guidelines laid all along by the organization, something that has afterward a long mannerism in it brute ascribed as a great place to gamble online.
Everything nearly The Gaming Club feels good; be it the promotions, the big number of games, the merged banking options upon offer, the modern security measures, or the fair and responsible gaming practices the casino adopts.
The Gaming Club motors along upon software developed by one of the giants of online gaming software evolve Microgaming. The software it uses is radical and has a range of features meant to tally up your online gambling experience and make you desire to come back up after all round of gambling you reach here.
Another hallmark of a fine casino is the character of its customer retain team, and The Gaming Club does not disappoint upon this front.
https://onegold88.com/scr888/