On 1/23/2020 9:32 AM, Peter Vander Woude wrote:
The apar is meant to deal with those types of hacks, where someone has a list
of userids and then just try to logon to TSO by connecting and attempting to
logon to TSO. Without the apar/parm, the normal logon screen shows the person
IF the userid actually has a TSO profile.d
When the correct parm is in the IKJTSO00 parmlib member, they just get a prompt
for the password. There is no notification at that point that the user does,
or does not, have TSO access. Even the response does not tell the hacker that
information.
While I agree that it could be a vein for a ddos of getting the users id
revoked, the premise is valid to prevent the identification of someone with TSO
access is very valid.
That opens the way to a denial of service attack; someone can write a script to
cause revocation of a long list of userids.
This fix was not an attempt to prevent a DDOS revocation attack. It was
designed to prevent the ability of a hacker to enumerate the TSO id's on
a system. With PASSWORDPREPROMPT(ON), both a valid TSO id and password
are required to present the fullscreen TSO logon panel, or a nebulous
error message is presented. Without it, the error messages clearly
state whether you have a valid TSO userid or password. Armed with a
list of valid TSO id's, then the attacker could start social engineering
or other phishing attempts to get a valid password.
Once a hacker gets access to a TN3270 port, a DDOS revocation attack is
possible whether you have PASSWORDPREPROMPT(ON) or not. The fix did not
enable the DDOS revocation attack, the potential has always been there
to run it.
Regards,
Tom Conley
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
