Potential Security Threat - Unique Names in IP Ranges

Use this forum if you have installed hMailServer and want to ask a question related to a production release of hMailServer. Before posting, please read the troubleshooting guide. A large part of all reported issues are already described in detail here.
Post Reply
NetChain
New user
New user
Posts: 20
Joined: 2016-08-07 23:58

Potential Security Threat - Unique Names in IP Ranges

Post by NetChain » 2019-06-25 21:31

Why the IP Ranges Names are suppose to be unique?

I didn't realized it until I tried to update the database directly and found out that the Name field "RangeName" in the table "hm_securityranges" must be unique.

Here's a hypothetical scenario:
A hacker tries to guess password for one particular account (let's say a@b.c) from IP Address #1 from one network. After few attempts this IP address would get blocked and labeled as "Auto-ban: a@b.c", so the hacker can potentially use another IP#2 to continue attempts. He would get... what... 3-5 more attempts until IP#2 would get blocked.

And here's the problem: The IP#1 record would get overwritten with the new IP#2 address, because of the same unique label, before IP#1 suppose to be expired. Now the hacker can immediately continue his "quest" using IP#1, since it is no longer blocked. After the limited number of attempts he can switch back to #2, and keep repeating that forever.
Am I just fantasizing? :) Or this could possibly happen?
And if it could, then seems like this scenario could be easily avoided if IP Range Names field would be allowed to have the same names.
Which leads to the main question: what's the reason for enforcing the uniqueness?

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Potential Security Threat - Unique Names in IP Ranges

Post by SorenR » 2019-06-25 22:36

NetChain wrote:
2019-06-25 21:31
Why the IP Ranges Names are suppose to be unique?

I didn't realized it until I tried to update the database directly and found out that the Name field "RangeName" in the table "hm_securityranges" must be unique.

Here's a hypothetical scenario:
A hacker tries to guess password for one particular account (let's say a@b.c) from IP Address #1 from one network. After few attempts this IP address would get blocked and labeled as "Auto-ban: a@b.c", so the hacker can potentially use another IP#2 to continue attempts. He would get... what... 3-5 more attempts until IP#2 would get blocked.

And here's the problem: The IP#1 record would get overwritten with the new IP#2 address, because of the same unique label, before IP#1 suppose to be expired. Now the hacker can immediately continue his "quest" using IP#1, since it is no longer blocked. After the limited number of attempts he can switch back to #2, and keep repeating that forever.
Am I just fantasizing? :) Or this could possibly happen?
And if it could, then seems like this scenario could be easily avoided if IP Range Names field would be allowed to have the same names.
Which leads to the main question: what's the reason for enforcing the uniqueness?
Set the default BAN to 12 months, problem solved!

It is declared a unique field in the database because it is searchable.

Like this:

Code: Select all

Set oSecurityRange = oApp.Settings.SecurityRanges.ItemByName("Localhost")
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

NetChain
New user
New user
Posts: 20
Joined: 2016-08-07 23:58

Re: Potential Security Threat - Unique Names in IP Ranges

Post by NetChain » 2019-06-25 22:42

SorenR wrote:
2019-06-25 22:36
Set the default BAN to 12 months, problem solved!
The problem I noticed is NOT the expiration. It was the fact that the name gets overwritten with another attempt to login with the same name, but from another IP address. This overwriting is forcing the previous record to expire immediately.

Am I wrong?

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Potential Security Threat - Unique Names in IP Ranges

Post by SorenR » 2019-06-25 22:48

NetChain wrote:
2019-06-25 22:42
SorenR wrote:
2019-06-25 22:36
Set the default BAN to 12 months, problem solved!
The problem I noticed is NOT the expiration. It was the fact that the name gets overwritten with another attempt to login with the same name, but from another IP address. This overwriting is forcing the previous record to expire immediately.

Am I wrong?
hMailServer will NEVER overwrite an IP Range. It will append (1), (2)... etc. to the name.
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

NetChain
New user
New user
Posts: 20
Joined: 2016-08-07 23:58

Re: Potential Security Threat - Unique Names in IP Ranges

Post by NetChain » 2019-06-26 00:36

SorenR wrote:
2019-06-25 22:48
hMailServer will NEVER overwrite an IP Range. It will append (1), (2)... etc. to the name.
Excellent!

I didn't know that because I've never seen (x) as part if the names, even though I've seen some brutal attacks. I was testing it by adding IP Range manually when I noticed that adding a new range with in the same name would overwrite the old one. My version is: 5.6.7-B2425

Thanks.

User avatar
mattg
Moderator
Moderator
Posts: 19979
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Potential Security Threat - Unique Names in IP Ranges

Post by mattg » 2019-06-26 00:56

NetChain wrote:
2019-06-25 21:31
I didn't realized it until I tried to update the database directly...
You understand that direct manipulation of the database is NOT supported, right?
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

estradis
Normal user
Normal user
Posts: 145
Joined: 2014-09-09 10:47

Re: Potential Security Threat - Unique Names in IP Ranges

Post by estradis » 2019-07-25 17:26

NetChain wrote:
2019-06-25 21:31

Am I just fantasizing? :) Or this could possibly happen?
No, this doesn't happen!

Let's assume that there is an intrusion attempt to the specific account john.doe@example.com. This is, how HMS handles it:
1st entry: "Auto-ban: john.doe@example.com"
2nd entry: "Auto-ban: john.doe@example.com (1)"
3rd entry: "Auto-ban: john.doe@example.com (2)"
4th entry: "Auto-ban: john.doe@example.com (3)"
...
10th entry: "Auto-ban: john.doe@example.com (9)"
>10th entry: "Auto-ban: john.doe@example.com (10 RANDOM CHARS)"

HMS doesn't also block "users", it always blocks IP addresses. This means if an autoban entry exists for 1.2.3.4, hms won't allow any connection and therefore jane.doe@example.com cannot connect either from this address.

If you want a clear overview, you can use this select to gain all relevant information:

Code: Select all

SELECT DISTINCT
	`ranges`.`rangeid` AS `rangeid`,
	`ranges`.`rangepriorityid` AS `rangepriorityid`,
	`ranges`.`rangelowerip1` AS `rangelowerip1`,
	`ranges`.`rangelowerip2` AS `rangelowerip2`,
	`ranges`.`rangeupperip1` AS `rangeupperip1`,
	`ranges`.`rangeupperip2` AS `rangeupperip2`,
	`ranges`.`rangeoptions` AS `rangeoptions`,
	`ranges`.`rangename` AS `rangename`,
	`ranges`.`rangeexpires` AS `rangeexpires`,
	`ranges`.`rangeexpirestime` AS `rangeexpirestime`,
	(`ranges`.`rangeexpirestime` - INTERVAL -(select settinginteger from `hmailserver`.`hm_settings` where `settingname` = 'autobanminutes') MINUTE) AS `rangecreatedtime`,
	INET_NTOA(`ranges`.`rangelowerip1`) AS `rlowerip1`,
	INET_NTOA(`ranges`.`rangelowerip2`) AS `rlowerip2`,
	INET_NTOA(`ranges`.`rangeupperip1`) AS `rupperip1`,
	INET_NTOA(`ranges`.`rangeupperip2`) AS `rupperip2`,
	TRIM(REPLACE(SUBSTRING_INDEX(CONCAT(`ranges`.`rangename`, ' ('), '(', 1), 'Auto-ban:', ''))  AS `loginname`
FROM `hmailserver`.`hm_securityranges` `ranges`
WHERE
	`ranges`.`rangeexpires` = 1 AND `ranges`.`rangename` LIKE 'auto-ban:%'
ORDER BY `ranges`.`rangeexpirestime` DESC
Please keep in mind that the value in column `rangecreatedtime` is calculated from actual setting `autobanminutes`. If the setting was changed after an entry was added, the value will be incorrect.

Post Reply