82

This is the result of someone trying to exploit an SQL injection on your site. Someone tried to detect if your website was vulnerable to a union-based injection. For all the records that you see, it doesn't seem to have worked. You should check your access and error-logs for the affected timespan to see if any further requests were made. One suspicious ...


42

Have a look at "Union Injection" SQL attacks such as found here. Basically, it's trying various methods to identify the number of columns in the query, looking for one which is successful. The order by lines attempt to detect the difference between data ordered by specific columns and an error caused by attempting to order by a non-existent column, while ...


31

In addition to the good answers already given, stating that these are probably signs of unsuccessful attempts, I would like to add that these user ids may be part of a more elaborate successful injection. This is not purely theoretical. I have encountered situations where the results of one select query are used without proper input validation in a second ...


22

If using SSL, then what PostgreSQL does is fine. If not using SSL, but still doing the authentication across the network, then what PostgreSQL does stinks. Their games with MD5 are worthless, but not because they use MD5. MD5 has its own issues, but there they are just misusing it awfully. With "cleartext password" authentication, the client shows a user ...


19

The PostgreSQL documentation says that UUID generation relies on the OSSP library. A look at the source code of OSSP (version 1.6.2) shows that the code uses /dev/urandom on Unix-like systems (CryptGenRandom() on Windows), and also a much weaker PRNG based on current time, process ID, and the C library rand() function. Fortunately, the two outputs are XORed ...


10

Yes, using MD5 is safe. When a client wants to authenticate, the server sends a random salt value. The client uses that value, along with the password to generate a MD5 hash. Because a random salt is used, an attacker can not use a dictionary attack. Also, because the salt is changed each time a client authenticates, this is no ability to replay old ...


9

The same as any other database using SQL, use the following (taken from the OWASP cheat sheet) Option #1: Use of Prepared Statements (Parameterized Queries) Option #2: Use of Stored Procedures Option #3: Escaping all User Supplied Input Also Enforce: Least Privilege Also Perform: White List Input Validation


7

SQL injection is an application threat, not a database threat. In the end, all relational databases execute the SQL which is passed to them as a string. And it is the responsibility of the application developer to make sure that SQL string is not harmful. SQL injection is a way to cause an application to send SQL strings to the database which are harmful, ...


7

Restricted user accounts Sanitizing such a query securely may be very, very hard and you should expect that you might have failed in some way which allows the users to execute arbitrary sql. A possible mitigation for this would be severely restricted user accounts - you need to ensure that the connection under which these queries are executed is run under ...


5

Postgres uses MD5 as algorithm with the username as "salt". Using a salt normally prevents computation of hashes, for example in rainbow tables. Using the username as salt only partially covers this problem. It is possible to precompute hashes for common usernames, such as "root" or "postgres". Furthermore, MD5 is one of the fastest cryptographic hashes ...


4

You already mentioned some of the problems: misconfiguration is easy, privilege escalation bugs could put you at risk, offering raw, more or less uncontrolled access to the data can lead to DOS situations. But there are some additional problems with your idea: This means that your university will be bound to offer the service as long as the product is in ...


4

TL;DR - upgrade, it works like you expect now. In versions before 4.13.8, search used a union instead of an intersection of results. Thus your example ("search platform:windows type:exploit") would show you all modules that target Windows (including payloads, auxiliary, and post modules) and all modules that are exploits (regardless of the platform they ...


4

It's not an SQL injection, and shouldn't be directly exploitable as one, since you've used a named parameter (:sendTo) instead of directly concatenating strings. However, it is indeed exploitable, because an attacker can simply change the ID number and cause your server to spam other accounts with emails. Also, cases like this one, where the client sends ...


3

TLDR. It can be secure if you configure it properly and use good long passwords. 1. In postgres the md5 auth-method means client-side hashing (discussions: 1, 2), which makes hashes password equivalent. A hash in the db is compared to a hash received from a client. An attacker can use any hash from stolen pg_shadow table directly, without even spending time ...


3

In pgAdmin 4.x the password file location can be specified in GUI whereas pgAdmin III has a fixed path. Both documentations refers to the PostgreSQL libpq (C Library) documentation for The Password File: The file .pgpass in a user's home directory can contain passwords to be used if the connection requires a password (and no password has been ...


2

...does storing ciphertext in a database gain you much over using the database's built-in encryption? I would think it protect data that was obtained from SQL injection or database access as long as the key remained safe? No. SQLi can be used to quickly escalate access to the rest of the machine. Form the pgcrypto docs you list: F.25.6.3. Security ...


2

random() can have at most 64 bits of significance, since it's a double precision float. That assumes perfect random number generation and all that. We only produce a random significand, the sign and exponent is fixed. The fractional part of the significand is 52 bits. So ... about 2^52 possible values. It looks like you're thinking of the rainbow table as ...


2

Inside an older version of msfconsole, you could call grep immediately before calling the search command. For example, to search for the 2 terms 'shellshock' and 'mod_cgi': msf > grep mod_cgi search shellshock auxiliary/scanner/http/apache_mod_cgi_bash_env 2014-09-24 normal Apache mod_cgi Bash Environment Variable Injection (Shellshock) ...


2

That Warning is irrelevant - The attack itself could have been through any weakness you have on your network, or through a phish, or a web facing service or anything. You need to pull all your logs from: firewall routers host platforms end user systems database user/ID management systems etc Then analyse them together to understand the timeline. This ...


2

Almost certainly not. It's quite common to see automated attacks from web scanners - IPv4 is a pretty small address space and quite easy to enumerate (IPv6, at least, makes them work a bit to find targets!) It's a low-cost, low-success, but potentially high-reward tactic if they stumble on a server with interesting data and a terrible (or default) password. ...


2

Pg stores its passwords in pg_authid Password (possibly encrypted); null if none. If the password is encrypted, this column will begin with the string md5 followed by a 32-character hexadecimal MD5 hash. The MD5 hash will be of the user's password concatenated to their user name. For example, if user joe has password xyzzy, PostgreSQL will store the md5 ...


2

I've seen the same behavior in a few of the apps I manage. I also saw this tweet - https://twitter.com/testflyjets/status/1102410441723015168 - so I don't think these are targeted attacks, but rather an un-targeted effort to find vulnerable Postgres databases. Most of the attempted connections were with the username "postgres", but I also saw attempts with "...


2

Since you are explicitly allowing users to construct raw SQL code, you have to trust them. However, this doesn't mean that you're defenseless. Relational databases -- especially those with replication -- have Write-Ahead Log (WAL) files that act as transaction-by-transaction incremental backups. If you perform regular full (offsite) backups, and ship your ...


2

Denial of service An attacker could construct a query condition that's very resource intensive, and run it repeatedly, making the server so overloaded that it can't serve normal requests. Information extraction For starters, even if there are no other options to see the results through your app, an attacker probably can construct a timing-based channel ...


1

So I'm simply asking, how strong would my (super user) database credentials ideally be? Maximum strength. Based on this answer, a length 100 cryptographically random password with upper, lower, numbers, symbols fits that. Store it in KeePass or similar. why shouldn't I just generate a random 40 letters string and use it hard-coded in my script files ...


1

So I'm simply asking, how strong would my (super user) database credentials ideally be? As strong as possible. Use random passwords as long and as with as many different characters as the database will let you. Do not try to remember them. If you pick passwords that you can easily remember, they are probably to weak. ...use it hard-coded in my script ...


1

Starting from PostgreSQL 10, the SCRAM-SHA-256 password authentication mechanism is included: To upgrade an existing installation from md5 to scram-sha-256, after having ensured that all client libraries in use are new enough to support SCRAM, set password_encryption = 'scram-sha-256' in postgresql.conf, make all users set new passwords, and change the ...


1

Further to what Rory says, these attacks are very common with unsecured databases exposed to the internet. I know of them happening with MongoDB's, but any database platform is possible assuming it's exposed to the internet and has weak authentication. For a ransom of .5 BTC I'm imagining the attack vector was not sophisticated. It's unlikely they put too ...


1

It really depends on your requirements as Vinay pointed out. However I can give you some options: You setup an IAM role which allows to change the master password of the RDS instance. Whenever you start the server you set this credential via the application. The AWS account has to be configured in a way that the developers are not able to do that. Issues: ...


Only top voted, non community-wiki answers of a minimum length are eligible