Jump to content

Recommended Posts

Hello All

I am very new to script world for please forgive my silly questions. 

i have managed to create the sql developer script using mouse positions and it is working fine. 

 

The actual step i want to perform is that the send of username and password. So basically when if i mention send Send ("username") ..the script is actually injecting the username as word what i want is to get the username and password from beyondtrust pam solution.

 

I read about $cmdline but i am not sure how to start with. 

 

i want the paramters of username password and hostname to be retrived from BT and then inject so the usecase will be successful.

please help with suggestion.

Link to post
Share on other sites

That method of using mouse positions to send data to fields is not a good idea. A much more stable approach is to get the control ID the field in question in the window then send to that control. 

Question: Are you working with a website? If yes, then you may want to look at this: 

 

Link to post
Share on other sites

Reading from the website, I see that beyondtrust pam is actually a software security suite to exert control over privilege elevation, access, and permissions strategies. If you are interfacing with that, I strongly suggest you consult with them about using AutoIT to store user credentials in AutoIT variables where they may be stored in plain text, even if only temporarily, as nefarious types love trawling through memory dumps for exactly these type of misuse. Often if you pass these values to programs, other software can access these values, something that may be extremely undesirable. Let the existing security infrastructure in your OS give you the privileges to execute your programs without having to pass passwords and usernames as parameters.

[Note: I speak from extensive corporate experience here] A strong warning: You are opening your organisation to a whole lot of grief, possibly without even realising it. Obviously your organisation is taking the current threats of cyber attacks very seriously if they are investing money on beyondtrust packages, and scripting your way in the background will just be undermining that. Your AutoIT code may even be flagged as malware and unceremoniously deleted. Given the kind of self admitted newbie type question you have posed, it is obvious you are innocently looking at the trees and not the forest. Please, please talk to your security team before you proceed with any further coding. Ask their opinion if AutoIT is the appropriate tool to be using to launch other software and pass security attributes to it.

Link to post
Share on other sites

Confuzzled is correct. (Thanks for doing  the background work on that)

Please get with your group that handles IT security and also see if you are even permitted to use Autoit in your corporate environment. This is the sort of thing that asking permission first is much better than trying to get forgiven after. In my corporate career I've seen people lose their jobs over doing something like this and not getting in writing permission first. 

Edited by Bert
Link to post
Share on other sites

Unfortunately, people rarely get fired for not giving permission.

This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Link to post
Share on other sites

I would say getting fired, versus having your company get rolled by ransomware or worse, might be the least of your worries. In the first instance, it is your payroll that goes down the gurgler, in the second, the entire company payroll. Just in the last few weeks, many Americans have woken to no gasoline and no hamburgers - two of the things they hold most dear, due to ransomware. The methods of infiltration are still being investigated, but it is usually human inattention, rather than software bugs that make it easiest to compromise targets.

It only takes one slip-up on your company part to let them in. You don't want this to be the weakest link in a well planned and expensive security strategy that was bypassed by a simple script. The criminals only have to get it right one time. Your corporate defences have to get it right every time.

 

Here's a challenge for all those reading this thread:

Go through all the AutoIT forums here, find ALL code that has ever been posted that uses a password in any shape or form (search for word 'password' might do it), and then go see if the coder cleared, overwrote, or wiped the value IMMEDIATELY after they had used it.

You would think any security minded coder would do this routinely, without thinking, to keep it from being retained in memory, getting copied to the clipboard, getting siphoned by another program reading the field from your GUI, getting stored in a dump file, etc.

Yep, read and weep!

Edited by Confuzzled
Link to post
Share on other sites

Actually, if you wanna join the skript kiddies, go plunder GitHub! A lot of hard coded passwords right there, in plain text intermingled with the code.

I think Microsoft, as a responsible member of the IT industry (did I really type that?), and current owner of GitHub, has been making attempts to identify these oversights and alert the people archiving the code for others to browse of the security implications.

Conversely, the baddies have been plucking the low hanging fruit and playing havoc on the Internetz.

Link to post
Share on other sites

You want to logon somewhere with userid and password to get another userid/password?

  1. Make sure you run in a single signon securitycontext (like others said do not store it in script or configuration files you check in to github)
  2. Call an api to get userid/password from your vault management system beyondtrust pam
  3. Make sure you are aware of variables containing your userid/pwd in memory and handle them in line with company policies
  4. If possible work with timebased tokens for security

In general I do not think it makes a difference typing userid/pwd manually or automated as soon as its entered you have the risk its left somewhere in memory (even encrypting does not help as the unencrypted variable could be anywhere in garbage collection or not reinitialized memory by the operating system). 

Wiping password variables will not help to get it out of computer memory. Google for DPAPI to get an idea about problematics around data that needs to be secured in memory. but again whenever you use send("plain password") it is in unprotected memory.

And indeed screenscraping like you started with can easier be done with iuiautomation.

Link to post
Share on other sites
  • 2 weeks later...
On 6/15/2021 at 10:44 AM, Confuzzled said:

I would say getting fired, versus having your company get rolled by ransomware or worse, might be the least of your worries. In the first instance, it is your payroll that goes down the gurgler, in the second, the entire company payroll. Just in the last few weeks, many Americans have woken to no gasoline and no hamburgers - two of the things they hold most dear, due to ransomware. The methods of infiltration are still being investigated, but it is usually human inattention, rather than software bugs that make it easiest to compromise targets.

It only takes one slip-up on your company part to let them in. You don't want this to be the weakest link in a well planned and expensive security strategy that was bypassed by a simple script. The criminals only have to get it right one time. Your corporate defences have to get it right every time.

 

Here's a challenge for all those reading this thread:

Go through all the AutoIT forums here, find ALL code that has ever been posted that uses a password in any shape or form (search for word 'password' might do it), and then go see if the coder cleared, overwrote, or wiped the value IMMEDIATELY after they had used it.

You would think any security minded coder would do this routinely, without thinking, to keep it from being retained in memory, getting copied to the clipboard, getting siphoned by another program reading the field from your GUI, getting stored in a dump file, etc.

Yep, read and weep!

You know - many years after I left a job I STILL have the main admin ID and PW for a root account that can be used all across the company. They won't change the PW for it is hard coded in MANY things.  :doh:

When I was there some idiot coded a script that they sent me to fix and lord and behold - he coded the ID and PW. Should I have it? No. Have I ever used it? No. It was something I just kept in my back pocket for I did IT support for them and now & again you need to fix things.

Link to post
Share on other sites
  • 2 weeks later...

Thanks... my simple question was how to pass the parameters... but anyways it seems it went in different direction, i have found my solution by performing some RND so thanks for going out of topic !! and filling up this topic without any related content.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...