#Massive SQL injection scanner

[pentesttoolz]

SQLiv – Massive SQL Injection Vulnerability Scanner – Kali Linux 2017.2

SQLiv – Massive SQL Injection Vulnerability Scanner – Kali Linux 2017.2

Hey Guys, In this video i show you a cool tool called SQLiv which used to scan websites for sql injection.

SQLiv: https://github.com/Hadesy2k/sqliv

Features: multiple domain scanning with SQL injection dork by Bing, Google, or Yahoo targetted scanning by providing specific domain (with crawling) reverse domain scanning

both SQLi scanning and domain info checking are done in multiprocessing so the…

[daniloqp]

A controversial tool calls for thousands of hackable websites

A controversial tool calls for thousands of hackable websites

https://theministerofcapitalism.com/blog/a-controversial-tool-calls-for-thousands-of-hackable-websites/

Cáceres freely admits that malicious hackers could use PunkSpider to identify websites to hack. But he argues that scanners that find web vulnerabilities have always existed. This only makes the results public. “You know your customers can see it, your investors can see it, so you’re going to fix that shit quickly,” Cáceres says.

Grab two of them

The Defcon talk of Cáceres and Hopper marks the second incarnation of PunkSpider. The idea of ​​the tool was born a decade ago, in the summer of 2011, as the hacker collective Anonymous and its splinter group LulzSec were in the midst of data theft and destruction, most of which were made possible by simple web vulnerabilities. (“Why is there SQL injection everywhere?”, Was the saying of a hip-hop song tribute to LulzSec.)

Cáceres noted at the time that even relatively unsophisticated hackers apparently had no trouble finding a preponderance of web errors. He began to wonder if the only solution could be to reveal all the vulnerabilities of the web in a massive purge. So in 2012 he started building PunkSpider to do exactly that; presented it at the Shmoocon piracy conference in early 2013. Its small security R&D company, Hyperion Gray, also received funding from Darpa.

But from the beginning, the project faced challenges. The Shmoocon hearing wondered if Cáceres was enabling blackhat hackers and violating the Computer Fraud and Abuse Act in the process. Soon, Amazon repeatedly ripped it from the Amazon Web Services accounts it used to power the search engine, after receiving reports of angry webmaster abuse. He was forced to constantly create new burner accounts to keep it running.

In 2015, Cáceres was exploring the web to detect new vulnerabilities only about once a year. He struggled to keep PunkSpider online and cover its costs. Shortly afterwards, he let the project expire.

Earlier this year, however, it was Hyperion Gray acquired by QOMPLX, and the largest startup agreed to revive a new and improved version of its web piracy search engine. Now Cáceres and Hopper say explorations of their revamped tool are driven by a cloud-based cluster of hundreds of machines, capable of scanning hundreds of millions of sites a day, updating their results for the entire web continuously or by scanning URL URLs at a user’s request. The annual scans of the entire PunkSpider website took almost a week to complete.

Caceres declined to name its current hosting provider, but says it has understood with the company the motivations of PunkSpider, which it hopes will be able to ban its accounts again. Also, albeit reluctantly, it has added a feature that allows webmasters to detect user-based PunkSpider tests that help identify visitors to a website, and has included an email address and a deactivation feature that allows websites to be removed from searches. “I’m not happy about that, honestly,” Cáceres says. “I don’t like the idea of ​​people being able to opt for safety things and bury their heads in the sand. But it’s a matter of sustainability and balance.”

PunkSpider website

The reincarnated version of PunkSpider has already revealed real flaws on major websites. Cáceres showed WIRED screenshots that demonstrated vulnerabilities between scripts between sites Kickstarter.com i LendingTree.com. In the case of LendingTree, Caceres claims that the vulnerability could be used to create links that, if users were tricked, clicked on them, would host malicious software on the site or show fishing directions on LendingTree’s own site. Caceres says the Kickstarter error would allow hackers to create a link that, if a victim clicked on it, could similarly show fishing directions or make a payment from their credit card to a Kickstarter project.

“LendingTree employs multiple layers of control to protect our site and the confidentiality and integrity of consumer data,” the company said in a statement. “This includes web application firewalls, external penetration testing, and static / dynamic code review to identify and fix vulnerabilities. In addition, we take the reported security vulnerabilities seriously and quickly investigate and resolve any issues found.” KickStarter wrote in an email to WIRED that its web defect is being “actively treated”.

Source link

[webart-studio]

A WordPress security plan for SEOs and builders – Search Engine Land

WordPress powers an astonishing one-third of all web sites today. It has been the CMS platform of selection for our neighborhood because the mid-aughts when lots of WordPress’s search engine optimization options have been applied. It’s subsequently relentlessly attacked, largely for search engine optimization spam causes, however assaults can escalate to a lot worse.

Right here’s a have a look at some WordPress fundamentals and methods to make sure your WordPress web site stays secure.

Is WordPress secure?

The newest model of WordPress could be very secure out of the field. Neglecting to replace it, nonetheless, amongst different issues, could make it unsafe. This is the reason many safety professionals and builders aren’t WordPress followers. WordPress additionally resembles PHP spaghetti code which is inherently insecure, the place WordPress itself warns that vulnerabilities “stem from the platform’s extensible components, particularly plugins and themes.”

WordPress updates

There is no such thing as a such factor as a 100 p.c safe system. WordPress wants safety updates to function safely, and people updates shouldn’t negatively have an effect on you. Activate computerized safety updates. Updating the WordPress core, nonetheless, does require that you simply be certain all the things is appropriate. Replace plugins and themes as quickly as appropriate variations can be found.

Open supply

WordPress is open supply, which entails dangers in addition to advantages. The challenge advantages from a developer neighborhood that contributes code for the core, the core staff patches safety flaws discovered by the neighborhood, whereas hooligans uncover methods to pry issues open. Vulnerabilities are scripted into scans by exploit purposes which might detect what variations of issues are working to match recognized flaws to your variations.

Defend your self first

There are issues you are able to do to guard your self even if you don’t have an administrator function. Be sure to’re engaged on a safe community with a usually scanned workstation. Block advertisements to forestall refined assaults that masquerade as pictures. Use VPN for end-to-end encryption everytime you’re working at public WiFi hotspots to forestall session hijacking and MITM assaults.

Safe passwords

Securely managing passwords is vital it doesn’t matter what function you could have. Make certain your password is exclusive and lengthy sufficient. Mixtures of numbers and letters aren’t secure sufficient, even with punctuation, when passwords aren’t lengthy sufficient. You want lengthy passwords. Use phrases of 4 or 5 phrases strung collectively if you’ll want to memorize nevertheless it’s higher to make use of a password supervisor that generates passwords for you.

Password size

Why is size so vital? Put it this manner, eight character passwords crack in lower than 2.5 hours utilizing a free and open supply utility known as HashCat. It doesn’t matter how unintelligible your password is, it solely takes hours to crack brief passwords. Beginning at 13+ characters, cracking begins to get insurmountable, at the very least for now.

Directors

In case you have an admin person function, create a brand new person for your self that’s restricted to an editor function. Start utilizing the brand new profile as an alternative of admin. That manner, broad space web assaults can be centered on attacking your editor function credentials, and in case your session will get hijacked you could have the admin capability to alter passwords and wrest management away from the intruders. Compel everybody, maybe via using a plugin, to observe a robust password coverage.

Safety coverage

In case you have safety expertise, carry out code audits of your plugins and themes (clearly). Set up the precept of least privilege for all of the customers. You then are forcing hackers to carry out shell popping methods and privilege escalation which entails attacking targets aside from WordPress credentials.

Change file permissions

When you management the host, present your self with a SFTP account via using the Management Panel when you’ve got one, or strive what administrator person interface you could have entry to. It could have the aspect impact of configuring credentials to open a safe shell terminal window (SSH). That manner you possibly can carry out further safety measures utilizing system utilities and extra.

Lock down crucial information

There are a couple of information that ought to by no means be accessed besides by the PHP course of working WordPress. You may change file permissions and edit the .htaccess file to additional lock these information down. To vary file permissions, both use your SFTP consumer (if it has the choice), or open a terminal shell window and run the chmod utility command.

$ chmod 400 .wp-config $ ls -la

WordPress Config File Safety

Which means that solely the PHP course of working WordPress will be capable of learn the file, and nothing else. The file ought to by no means have the “execute bit” set, like with chmod 700. You must at all times have zeros within the second and third place — that’s what actually locks it down. Confirm your modifications working the ls utility with -la choices and take a look.

Having strict file permission settings means nothing could be written to the file, even by WordPress. You’ll wish to grant write permissions again with $ chmod 600 .wp-config when there’s a main WordPress replace whereby the config file has modifications. That ought to occur extraordinarily hardly ever, if ever.

WordPress login file

I prefer to lock down the wp-login.php file utilizing .htaccess guidelines. Limiting entry to solely my IP addresses is nice for after I work from one statically assigned IP, or a small handful of addresses for myself and a few customers. It’s not troublesome to alter the setting when you’re logging in from one other location so long as you possibly can acquire a shell on the host. Merely remark out the deny directive, login together with your browser, and uncomment it afterwards.

WordPress Htaccess Restrict By IP

XSS and SQL injection

By far the scariest assaults that you simply’ll encounter can be cross-site scripting (XSS) and SQL injection. There are .htaccess question string rewrite guidelines you should use to cease a few of these, and also you may be finest off utilizing a plugin that may handle this for you. Some safety plugins will scan your set up in search of indicators of compromise. If you understand how to make use of rewrites, redirect or block question string signatures for assaults you examine or see in your logs.

Safety plugins

Some safety plugins will scan your set up in search of indicators of compromise. Wordfense is a well-liked safety plugin, and it will get usually up to date. Sucuri Scanner has a paid choice that may scan your set up. Ninja Firewall goes to try to restrict request-base assaults, blocking them earlier than they attain WordPress core. You can even write an utility using Google’s new Internet Threat API to scan your web site’s pages.

About The Writer

Detlef Johnson is Editor at Massive for Third Door Media. He writes a column for Search Engine Land entitled “Technical search engine optimization for Builders.” Detlef is among the authentic group of pioneering site owners who established the skilled search engine optimization discipline greater than 20 years in the past. Since then he has labored for main search engine know-how suppliers, managed programming and advertising and marketing groups for Chicago Tribune, and consulted for quite a few entities together with Fortune 500 corporations. Detlef has a robust understanding of Technical search engine optimization and a ardour for Internet programming. As a famous know-how moderator at our SMX convention collection, Detlef will proceed to advertise search engine optimization excellence mixed with marketing-programmer options and webmaster suggestions.

Supply hyperlink

source https://webart-studio.com/a-wordpress-security-plan-for-seos-and-builders-search-engine-land/

[cyberkid1987]

sqliv: massive SQL injection vulnerability scanner

[commanderxanon]

Tweeted

Massive SQL Injection Scanner: SQLiv #Security #InfoSec #CyberSecurity https://t.co/1oHz0irC9F

— CyberPunk (@Hackers_toolbox) June 6, 2018

[ossig]

Finished Reading: Massive SQL Injection Scanner: SQLiv

http://ift.tt/2yXfMBO via Read it Later (October 11, 2017 at 09:27AM )

[inuwashi]

SQLiv - Massive SQL Injection Vulnerability Scanner https://t.co/imXI2otYLk— Nicolas Krassas (@Dinosn) October 26, 2017

http://twitter.com/AdamGrandt

[ericvanderburg]

Massive SQL Injection Scanner: SQLiv

http://i.securitythinkingcap.com/PtmRSB #PenTest

[the-hacker-news]

Katyusha Scanner — Telegram-based Fully Automated SQL Injection Tool

The Hacker News : A new powerful hacking tool recently introduced in an underground forum is making rounds these days, allowing anyone to rapidly conduct website scans for SQL injection flaws on a massive scale — all controlled from a smartphone using the Telegram messaging application. Dubbed Katyusha Scanner, the fully automated powerful SQLi vulnerability scanner was first surfaced in April this year when a http://dlvr.it/PV0zhy Posted by : Mohit Kumar ( Hacker )

[pentesttoolz]

SQLiv - Massive SQL Injection Vulnerability Scanner

SQLiv - Massive SQL Injection Vulnerability Scanner #Vulnerability #Injection #SQL #SQLI #Hacking #Scanner #python #infosec

Massive SQL injection vulnerability scanner.

Features

multiple domain scanning with SQL injection dork by Bing, Google, or Yahoo

targetted scanning by providing specific domain (with crawling)

reverse domain scanning

both SQLi scanning and domain info checking are done in multiprocessing so the script is super fast at scanning many urls

quick tutorial & screenshots are shown at the bottom project…

[sikoko]

Attacked Over Tor

For over 6 months, I have been running a Tor Hidden Service that provides a front-end to the Internet Archive (archive.org). The hidden service is at: http://ift.tt/2klcViP (This link only works if you are on Tor.) From running my other services, I think I know how to make an optimized web server. FotoForensics, for example, is handling some pretty impressive network loads. In fact, my two main sites have only gone down a few times. There was the Body by Victoria blog entry, Boston Marathon bombing, World Press Photo, and the explicit denial of service attack. Beyond outages, I've had various attacks from dumb bots and big search engines. (I still haven't forgiven Google for abusing FotoForensics and submitting random words into search forms. Half of my current anti-attack code came about after attacks from Google.) With each of these service outages and issues, I learned, made changes, and improved the system's performance. None of my systems are completely bullet proof -- another large denial-of-service could knock these public sites offline. (Please don't do that.) But I'm no longer worried about having my services listed on the front-page of Reddit, Slashdot, or other major social networks. However, running this hidden service has been a learning experience. The problems that I'm experiencing with my Tor Hidden Service are similar but different from non-Tor services. They have the same basic causes -- bots and denial-of-service attacks -- but the Tor architecture introduces a serious problem. This problem leads to choke point on the hidden service server. Bad bots and attackers can create a bottleneck, resulting in a denial of service. Without rewriting the tor daemon or spawning dozens of parallel servers, there are few mitigation options.

On the attack

The first attacks against my Internet Archive hidden service began hours after the public announcement. A slew of bots all came in, trying to index the entire Internet Archive through my little hidden service. This is just insane -- the Internet Archive is massive, and Tor is slow. There is no way that it can pass all of the data. And it isn't like they were doing HTTP 'HEAD' requests -- no, they were doing 'GET' requests. I quickly wrote a couple of rules to detect these poorly behaved mirror-bots and block their access. This stopped most of the abuse. A few more rules stopped the vulnerability scanners and blind attackers who tried SQL-injection, overflows, and other malicious actions. Stopping these abuses sped up the response times for real users who wanted to access the Internet Archive over Tor. As far as how to stop them... I had discussed this with a couple of people at the Internet Archive. At their recommendation, I began to return HTTP 403 "Forbidden" responses. If your bot sees this kind of response, it should stop. And if you make changes so that your bot avoids the 403 response, then you are attacking the site. Please don't attack my sites. However, there's a few bots that have continued to attempt to mirror all of the Internet Archive through my little service. They ignore robots.txt, ignore HTTP 403 messages, continue to violate my terms of service. They have given me no other option but to use more active defenses.

On the defense

Today, only five bots are really appearing to be problems. I've named them after letters of the alphabet: Albert, Bobby, Chuck, Dennis, and Eddie. Of the 5 bots, Dennis and Eddie are very aggressive. But it wasn't until Eddie appeared (on April 20th) that I had to make more active defenses. (This is when I realized that Eddie was more than a mirror bot.) My first deterrence was very simple. All five bots accept gzip encoding. So, I sent them zip-bombs. A gzip data stream maxes out at about 1032:1 compression. I can create a file that is 100K, but that decodes into 1 gigabyte. A 200K file on the wire expands into 2 gigabytes on the recipient's end. Albert was first. He downloaded three of the 100K compressed zip bombs (that expanded into 1 gigabyte each) and stopped cold. This tells me that he unpacked them in memory, ran out of memory, and then crashed. It also means that he had about 2 gigs of RAM. So far (it's been a week), he hasn't been back. Bobby and Chuck were almost as fast. Bobby downloaded 8 of the 1 gig zip bombs and then vanished. Chuck could handle the 1 gig zip bombs, but couldn't handle a dozen of the two-gig bombs. With Albert, Bobby, and Chuck out of the way, I began to focus on Dennis and Eddie. (As an aside: Why do I refer to misbehaving bots as guys? I may not know the gender of the person(s) running these bots, but they are clearly being dicks.)

Dennis

With Dennis, I began to feed him different types of results. These allowed me to profile the system. Based on how it reacted, I could tell that Dennis was a single-threaded streaming bot. It downloaded content, saved it to a file, and then streamed the file into a parser. Dennis has a built-in one-second pause. If I respond as fast as possible, he would visit once a second. If I pause 2 seconds before responding, then he visits every 3 seconds. And whoever is running Dennis runs multiple instances at the same time. The problem with Dennis isn't that he's sucking up server resources. The problem is that he's trying to mirror the entire Internet Archive, and the Internet Archive has some really big files. This results in a resource issue related to my external bandwidth. Moreover, he has never accessed my robots.txt and ignores 403 errors. As an active deterrence, I tried to fill up his hard drive with zip bombs. However, he appears to store the compressed data (or he has more than a few terabytes of free disk space). When that failed, I went after his queue. The parser that Dennis uses looks for URLs and adds them to a queue. I won't give exact details here, but I found out how to crash his parser. Crashing his parser was all it took to make him stop. He did restart a few times, but gave up after repeated crashes. Oddly, when he eventually came back, he didn't start re-parsing his queue. Instead, he saw a "403 Forbidden" (with no URLs to parse) and stopped. My interpretation here is that I didn't just crash his parser. I also caused Dennis to flush his queue. (I wouldn't be surprised if the human user saw the crashes and manually flushed the queue before restarting.) This defense stopped Dennis for a few days. But he came back this morning, and he appears to have fixed his parsing problem. He's still ignoring 403 errors, still ignores robots.txt, but since he isn't downloading anything from the Internet Archive, he has been downgraded from an active threat to a nuisance. (And my counter-defense seems to take him down periodically.)

Eddie

Eddie is the newest and most aggressive of the misbehaved bots. I haven't been able to stop him, and he has the ability to impact regular users who want to access the hidden service. What I know about Eddie:

He is a very rapid bot. If I respond as fast as possible, then he can make 20-30 or more requests per second. Eddie accounts for over 70% of the requests to my hidden service over the last week.

He ignores all return codes. I've been sending him "403 Forbidden" responses for days, and he just continues.

He has a 10 second timeout. If I don't respond in 10 seconds, or if my response does not finish transmitting data within 10 seconds, then he disconnects and tries a different URL. Among other things, it means that I cannot send him the 10 gig zip bomb. Tor is a slow network -- after sending 700kb-800kb of the 1000kb data, he disconnects due to his timeout. It also means that he doesn't care about the response -- he only cares about making requests.

Normally I don't track requests. (My web logs don't even list the requested URL.) However, I can readily identify Eddie based on a half-dozen unique signatures. So for Eddie, I began logging his attacks. He requests some URLs that were never sent to him and he ignores all data that I send him. If I send him custom URLs for tracking, he never accesses the URLs. Here's a sample of the URLs that he requests:

GET /details/zx_ZZZ_UNK_Gol GET /search.php?query=collection%3Aetree+AND+format%3Amp3+AND+creator%3A%22The+Visions%22 GET /details/911?chan=PSC&time=200109161810 GET /bookmarks.php?add_bookmark=1&identifier=RockyJordan&mediatype=audio&title=Rocky+Jordan GET /details/911?chan=PSC&time=200109161820 GET /details/zx_Quondam_1989_Ocean_a2 GET /search.php?query=collection%3Aetree+AND+format%3Amp3+AND+creator%3A%22The+Vista+Stringband%22 GET /details/911?chan=PSC&time=200109161830 GET /search.php?query=collection%3Aetree+AND+format%3Amp3+AND+creator%3A%22The+Vital+Might%22 GET /details/zx_Sea_of_Zirun_1985_Gilsoft_International_a GET /details/911?chan=PSC&time=200109161840 GET /search.php?query=subject%3A%22A+Man+Named+Jordan%22 GET /details/zx_Spectrasmash_Intro_1983_Romik_Software_16K GET /search.php?query=collection%3Aetree+AND+format%3Amp3+AND+creator%3A%22The+Vivid+Tangerines%22 GET /details/911?chan=PSC&time=200109161850 GET /search.php?query=subject%3A%22A+Man+Called+Jordan%22 GET /details/911?chan=PSC&time=200109161900 GET /details/zx_ZZZ_UNK_Gyufa GET /search.php?query=collection%3Aetree+AND+format%3Amp3+AND+creator%3A%22The+Void%22 GET /search.php?query=subject%3A%22Casablanca%22

He looks like he's doing search engine abuse -- submitting random searches and looking at the results. And he looks like he's going after a couple of responses. This collection of random queries and random results makes Eddie very different from a mirroring bot. Eddie isn't mirroring. He wants to look like he's trying to crawl the Internet Archive, but that's a cover-up for his real purpose. (I'll get to his real purpose in a moment.)

He cycles through connections faster than my hidden service cycles through connections. He connects, sends some GET requests, and then disconnects. Each of Eddie's processes repeats this a few times per minute.

He has an extremely high bandwidth. I benchmarked my own Tor clients. He's faster than a Tor client going through the typical 3 Tor node chain. He's even faster than a 1-node Tor chain. I strongly suspect that Eddie is actually a high-speed Tor relay.

I mentioned that Tor is really slow. Requests to my hidden service go from Tor to me to the Internet Archive and back. Even with his rapid requests, Eddie doesn't make a dent in my bandwidth. So what is he doing? He's exploiting a vulnerability in the Tor daemon. The same Tor process that you use for relaying onto Tor is used on my server for relaying to my hidden service. It's the exact same code. Except with the hidden service, the Tor daemon does one more thing... it connects to my local web server. This is what the Tor code does: it forwards traffic from the Tor network to my own service. In this case, Eddie establishes a Tor connection to my service. (That's one network connection from Tor to me.) Then he sends a bunch of rapid open/close connections from the Tor client to my web server. If I had not optimized the connection timeouts on my local server, then he would rapidly consume all network ports. This is a resource exhaustion attack. And while many web servers are optimized to prevents this type of attack on the external network connection, few are configured to prevent this over the loopback adapter. If I delay my responses to Eddie by more than 2 seconds, then Eddie can consume enough ports that Tor begins to fail to allocate new ports. This prevents users on Tor from accessing my hidden service. If I had not previously altered my network timeouts, then he would have consumed all available ports almost immediately. Fortunately, Eddie hasn't been able to kill my hidden service, but he has been able to slow it down. I've spent the last few days optimizing both the internal and external connection and garbage collection settings. I've also been working to slow down Eddie. He had been hitting me at more than 20 connections per second. I've currently got him reduced to 4-8 requests per second (one second per parallel Eddie process). Fortunately, non-Eddie users are getting a fast response time.

Who is Eddie?

There's a saying in the computer security field: if you own the server, you own the user. The same holds true with Tor. I really do value anonymity and privacy. And the Tor Project has done a very good job making it hard to track systems. Having said that... it just means I have to work harder to find out who is attacking me. (And I have a very large toolbox of dirty tricks that I will use against attackers.) I've been working with a couple of people to track down Eddie. I'm not going to detail all of the magic that we had to conjure up in order to track him. But I'm pretty confident in the current findings. Eddie consists of 3-4 high-speed servers, all located in either Germany or France. While searching for him, Joe Klein and I noticed that there were an oddly high number of "Unnamed" high-speed Tor nodes in France and Germany. Of the current 604 unnamed Tor nodes (as seen on 2017-05-04), 159 are in the United States, 105 are in Germany, and 64 are in France. But when sorted by bandwidth, 15 of the top 30 are from France. Germany comes in second, with 7. Of these fastest nodes, three of them are very interesting. They are [185.170.41.8], [185.170.41.7], and [185.170.42.4]. (In the above graph, the suspicious nodes are the 1st, 2nd, and 5th lines.) Now, I want to be clear: I am not convinced that these servers are Eddie. While looking for Eddie, we found these Tor servers. And these Tor servers, by themselves, seem very odd. Among the odd things:

The TorStatus page has no country associated with the ASN information. In fact, of the 604 unnamed Tor nodes, only 6 have no ASN information -- three are hosted at "cloudatcost.com" (a cloud hosting provider), the other three are these unidentified addresses.

To find the ASN information, we had to look through other methods. According to MaxMind, they are part of AS395978. A six-digit ASN number means it was registered pretty recently. According to WHOIS, it was registered around 2017-03-12. Unfortunately, MaxMind labels them as part of an anonymous proxy network. Hurricane Electric says that AS395978 has only one peer: AS174 -- that's Cogent. Cogent mainly provides service in the United States and Europe.

The "First seen" dates (as recorded by TorStatus) are 2017-04-08, 2017-04-10, and 2017-04-27. The attacks from Eddie began on 2017-04-20 -- shortly after they were registered. The attacks picked up speed on 2017-04-27, when the third server came online.

The WHOIS information for each of the three suspicious Tor nodes claims to registered to Trump Tower in Panama. NOTE: Regardless of my feelings about Trump, I believe this registration information is fake and it isn't really related to him.

inetnum: 185.170.41.0 - 185.170.41.255 org: ORG-OA825-RIPE netname: OKSERVERS country: PA admin-c: OL2665-RIPE tech-c: OL2665-RIPE status: ASSIGNED PA mnt-by: CYBR-DMZ created: 2017-01-31T19:51:49Z last-modified: 2017-04-29T11:18:45Z source: RIPE organisation: ORG-OA825-RIPE org-name: OKSERVERS org-type: OTHER address: TRUMP TOWER abuse-c: ACRO1670-RIPE mnt-ref: CYBR-DMZ mnt-by: CYBR-DMZ created: 2017-03-12T11:26:43Z last-modified: 2017-03-12T11:26:43Z source: RIPE # Filtered

While these IP addresses have likely-fake WHOIS registration information, they are registered to a service provider in New York city: OkServers. Except that OkServers says that their servers are located in Romania -- not Germany. So this may also be fake registration information.

Because the registration appears fake and lacks contact information, I reached out to RIPE (the registration provider). They said that they are investigating. Meanwhile, they directed me to the address space owner: ORG-RNL23-RIPE. I don't know how RIPE found this (I saw ORG-RNL25-RIPE, not ORG-RNL23-RIPE), but if they say it's the owner, then I believe them. This registrant is named Reachable Network (Pty) LTD, they are based out of South Africa, and they serve Germany and England. Oddly, in the last 24 hours, the command 'whois ORG-OA823-RIPE' has changed to identify OKSERVERSORG in the Netherlands. And their registration record now says it was created on 2017-03-08 -- a few days before the other registration records.

organisation: ORG-OA823-RIPE org-name: OKSERVERSORG org-type: OTHER address: NL abuse-c: ACRO1670-RIPE mnt-ref: CYBR-DMZ mnt-by: CYBR-DMZ created: 2017-03-08T20:37:55Z last-modified: 2017-03-08T20:37:55Z source: RIPE # Filtered

So let's see... We have a registrant in South Africa who's service areas are Germany and England. They just changed names to a company in the Netherlands. They provide network addresses for a company in New York that has servers in Romania. These odd boxes trace to Germany/France and says that the registration is Trump Tower in Panama. And the timestamps in WHOIS report that everything is less than 2 months old. The registration information bounces between multiple countries and never actually identifies the source. And they were all registered recently. If you talk to any cybersleuths about identity theft, spam, online fraud, scams, and fronts, they will tell you that misleading registration and bouncing between countries is a big red flag. This is some type of front. And it's deep enough to either be organized crime or a nation-state.

Where's Eddie now?

Late last night, Eddie abruptly stopped. Here's the last log entries:

[04/May/2017:23:00:50 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:50 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:50 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:50 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:51 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:51 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:51 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:51 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:00:51 -0600] "" 403 31 "" "Eddie" [04/May/2017:23:10:03 -0600] "" 403 31 "" "Eddie"

As far as I can tell, there's nothing I was doing that would have caused him to stop. The time that he stopped is also interesting -- near the top of the hour. (Off by 50 seconds? That's probably clock drift.) Perhaps Eddie had actually been processing some of the junk I returned to him, hit a long-queued-up zip-bomb, and died. But I kind of doubt it. As I mentioned, Eddie was multiple processes on multiple servers. (I'm very confident about that). So my zip-bombs would have taken down one process at a time; there wouldn't be a sudden stop. Perhaps the owner of the bot checked the logs. 11pm in Colorado is 7am in France and Germany, and 8am in Moscow. Then again, a lot of denial-of-service attacks are programmed to start at a specific time and end at a specific time. Running for exactly 24 hours, exactly 48 hours, or exactly 1 week are common. I mentioned that the attack started on April 20th. It stopped almost exactly 2 weeks later. And then there's that correlation with three suspicious Tor nodes. Shortly after the attack stopped, the volume of traffic through those nodes dropped dramatically. In this graph, the suspicious Tor nodes are the first three lines. (I seriously doubt that my hidden service was the only one being attacked. I bet all of the attacks suddenly stopped.) So why would they be attacking my little Tor hidden service? Or more specifically, who would not want people to access the Internet Archive over Tor? This is where we dive into conspiracies. For example, the first French election was held on 2017-04-23 (right after the attack started), and the run-off will happen on 2017-05-07 (which is days after the volume of the attack increased). The attack stopped less than a day after President Obama endorsed French candidate Emmanuel Macron. Assuming that this attack was related to the French election, it could take a day for Le Pen supporters, or a nation-state trying to influence the election, to change tactics. (Like Donald Trump, Le Pen wants to restrict Internet access. Both Tor and the Internet Archive are threats because they promote an open Internet.)

A better mitigation option

Finally, there's one thing that the Tor Project could do to really help mitigate this situation. Right now and as far as I can tell, there's no way for a hidden service to shutdown a single connection. Closing the connection from my web server to the tor daemon does not close the connection from the daemon to the remote client. And restarting the tor daemon impacts all connections, not just the hostile one. If I could easily tear down the entire tunnel from the remote client to my hidden service, then the delay to rebuild the tunnel would mitigate the resource exhaustion attack. I'm not asking for a way for someone to arbitrarily close any connection; I want a way for the hidden service to control which connections to it are permitted. For example, if I see hostile activity from 127.0.0.1:12345, then I want to close the entire Tor connection associated with this port. This won't prevent the attacker from coming back over a different port, but it does delay the attacker by forcing him to renegotiate the entire tunnel.

Source: http://ift.tt/2qBaHOO

[weblistposting-blog]

New Post has been published on Weblistposting

New Post has been published on https://weblistposting.com/a-way-to-address-a-wordpress-attack/

A way to address a WordPress attack

Today, we have an increasing number of individuals who need to create a blog, making them an awesome target for hackers – especially in popular Content Control Systems (CMS) inclusive of WordPress. This is a critical trouble due to the fact months or maybe years of sacrifice can vanish in an instant.

This article presents some of the matters all of us dealing with a hacking of a WordPress site have to so, with the intention to solve or, as a minimum, reduce the damages of that assault.

Carry out a backup It may seem peculiar to Carry out a backup of a domain being attacked, however, in truth, that can be very beneficial. As the attack goes on, possibilities are that more and more records are affected, so it is a superb concept to keep the as a lot of Content as viable.

Change passwords Again, this can seem an unusual factor to do whilst being beneath attack, however, it will most probably be effective to deter the attacker(s). Simply browse to the wp-config.personal home page document and Trade the modern-day passwords to secure ones. This manner, the attacker(s) might be blocked.

Perform a smooth installation of WordPress A smooth set up of WordPress will remove any issues that resulted from the assault. It may be performed by way of disposing of all Content material associated with WordPress from the server, except for wp-config.personal home page, that has the brand new passwords like explained above, and the wp-Content folder, that has all the website online’s contents.

Investigate the ‘wp-Content material’ directory Now it’s time to discover the wp-Content directory. Any suspicious folder needs to be eliminated. It’s miles vital to Carry out a backup before doing so due to the fact, if anything important is eliminated by using mistake, the backup assures that restoration is possible.

Look into and reinstall plugins Subsequent, It’s far vital to Investigate all the plugins which will apprehend if the attack changed into achieved through any of them. All plugins no longer being at once used inside the website online healing need to be eliminated. The mechanics must be to disable, get rid of and reinstall all plugins. In case you recognize for certain that a given plugin isn’t always inflamed or compromised, then it does not should be eliminated — however it need to be, Simply in case.

Take measures to protect the website in future assaults With the website online restored and returned online, It’s miles now time to fear about future attacks. Check if your web hosting is covered and, if now not, circulate to at least one this is. Also, use equipment that saves you this type of things, like Google Webmaster tools or particular protection plugins for WordPress, like WordPress record Screen Plus, a plugin to Reveal modifications in any WordPress installation.

Last but no longer least, a recommendation this is certainly old but constantly actual: plays regular backups. Consequently, if an attack takes the complete website down for exact, you’ll continually be capable of going back right away using those backups.

Being Smart about WordPress safety You can properly have heard all of the buzzes on-line about the attacks on WordPress security. Alas That is no shaggy dog story, and it wishes to be taken very critically, or all you’ve built will be hijacked or worse, lost to you.

Beginning within the first week of April of this 12 months, “botnets” have launched attacks against scantily blanketed WordPress websites, targeting some ninety,000 at the Closing count. This may result in many lousy outcomes, which includes denial of provider, junk mail and more

great your site or perform a little redecorate paintings without having to do it stay for all the world to look as you cross alongside.

Suggestions for WordPress safety

The fact is, if a capable master of the script goals your web page, there’s genuinely no way to save you an intrusion. What you are approximate to examine under are some precautionary movements you can take to fast decrease the risk to an appropriate stage. in case your WordPress web page is well-protected possibilities are a hacker might choose to select any other, the less difficult victim.

Starting with the extra apparent ones:

1. Neglect approximately the usage of “admin” as your username.

A few of the assaults goal the default WordPress username with brute force, password cracking robots. The first step is to Alternate your “admin” or “administrator” username from the WordPress Management Panel.

– Visit myself device (PHPMyAdmin) – Find your database – Visit wp_users and skim for “admin” – beneath user_login column, Exchange it to some thing else. This certainly leads to the following…

2. Pick a strong password

Choose a password that consists of more than one upper and lowercase letters, in addition to symbols which include “!@#$%^&*()” Visit Users->Your Profile and Trade it via the “New password” area at the bottom. This could make it way more difficult to crack it down. Ensure you do the equal on your FTP Cpanel website hosting account password and do not use the same one you used in WordPress.

three. Frequently backup your database

You heard this one earlier than. Do everyday backups or you may sooner or later remorse it. You could lose all of your work if being hacked. Also, recollect to backup every time you are making changes. you can do this through the use of a plugin or manually.

4. usually Replace your WordPress

there may be truely no reason to live on the older versions when there’s a new one available. WordPress updates comprise worm fixes, vulnerability fixes and cover safety flaws observed with the aid of the massive WordPress community. identical is going for updating themes. It is simple and green. Actually, It is the great and simplest way to prevent your page from malicious sports, which might be most probable as end result of a compromised and no longer fully updated utility, site, exploitable PHP scripts, and many others. all the antique versions of your programs can be considered as an ability protection holes. They are able to honestly be used by the attacker, who is (most of the time) an automatic spider.

5. defend your WP-CONFIG.Hypertext Preprocessor file.

flow your wp-config.Hypertext Preprocessor files one directory up from the WordPress root. WordPress will look for it there if it can’t be found inside the root directory. Additionally, no person else will be able to examine the report except they’ve SSH or FTP access to your server.

There are a number of essential plugins you ought to recollect putting in:

6. Login LockDown

This is a very useful plugin, shielding you in opposition to brute-force password-crack assaults. It maintains music of the IP deal with of every failed login strive. you can configure the plugin to disable login tries for various IP addresses whilst a sure quantity of failed tries is reached.

7. Comfy WordPress

Secure WordPress is an easy to put in comprehensive plugin looking after a range of factors, such as: – Hides your WP model. – Gets rid of blunders records on login web page. – Eliminates center Update, plugin Replace and subject Replace statistics for non-admins. – Blocks queries probably harmful to your WordPress internet site – Provides a digital index.personal home page plugin directory. – Many others…

eight. Bullet Evidence WordPress security

Crash resistant, complete plugin, covering many elements of an attack – XSS, RFI, CRLF, CSRF, Base64, Code Injection, and SQL. Injection hacking attempts. According to the respectable description – “The BulletProof security WordPress security plugin is designed to be a quick, simple and one click protection plugin to add.Htaccess internet site security safety on your WordPress website.” This quite a great deal sums it. A must have!

nine. Take advantage of Scanner

Exploit Scanner goes thru the documents to your website database, remark and submit tables looking for anything suspicious. It Additionally notifies you for uncommon plugin names. It does not eliminate some thing, it truly warns you for capacity threats.

10. WordPress Firewall

That is any other should-have safety plugin. – Investigates WordPress net requests in try and block obvious assaults.

[cyberkid1987]

sqliv: massive SQL injection vulnerability scanner