#110928 - 2003-12-26 08:12 PM
Admin rights in script
|
Alex.H
Seasoned Scripter
Registered: 2001-04-10
Posts: 406
Loc: France
|
Hello guys, it has been a long time since my last kixtart script post, but recenlty, while playing with my self-made snmp monitor, a friend ask me if it was possible to translate the network socket part in a COM object usable as a standalone and scriptable client/server component.
In fact, he was thinking to use it for some file tranfert over his network that can be server side controled and on which users wouldn't be able to take their hands. But with the way I used it, I point him that it's possible to pass whatever data you want, as I had to do with a http and smtp engine wrapped around the socket functions, even plain or crypted text containing username and passw .... *add the sound of remaining kixtart neurons connecting*
So that's the point, and the idea that may already exist, but did someone already build a such component, or used the windows socket layer to get a valid admin password for such purposes using a server side scheme ? Or even the whole main logon kixscript or other things too sensitive you don't want the user be able to see it unless he used a memory dump and play with a file containing hundred of megabytes and playing with assembly better than he spoke his native language
To be clear, actually there's nothing more than the base code on my hardrive (saved each 3 days  ) so no toy available, but it's just to get an idea about it, if I have to build it fast and badly for a friend or take in mind that more people will use it.
Is the idea viable, isn't it too much coding after in kixtart to be used, and whatever other stupid question comming through.
_________________________
? getobject(Kixtart.org.Signature)
|
|
Top
|
|
|
|
#110930 - 2003-12-26 08:37 PM
Re: Admin rights in script
|
Alex.H
Seasoned Scripter
Registered: 2001-04-10
Posts: 406
Loc: France
|
Quote:
I am not a programmer but is there not some potential with MSMQ?
Maybe, but can you be more clear on MSMQ, I fear i have an idea about what it means, but i'm not sure
Also note that buildin encryption will be integrated, at last base64 with custom key, and the possitility of md5 using an external component that can be wrapped in (and maybe integrated in the component if I don't make one myself), as the usable encryption is limited to windows version, and sometimes not easily usable.
_________________________
? getobject(Kixtart.org.Signature)
|
|
Top
|
|
|
|
|
#110932 - 2003-12-26 09:24 PM
Re: Admin rights in script
|
Alex.H
Seasoned Scripter
Registered: 2001-04-10
Posts: 406
Loc: France
|
Thanks Les, I also found it on msdn with msmq word. It seems interesting (seems also I won't sleep tonight), and a Com component already exists in the NT ressource kit.
there are some sample here
On the other hand, it seems 9x is not supported by the Com component
_________________________
? getobject(Kixtart.org.Signature)
|
|
Top
|
|
|
|
|
#110934 - 2004-01-07 11:02 AM
Re: Admin rights in script
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
1. KiXtart having access to the socket object is only half the story. KiXtart does not handle binary i/o at all well, so you will be restricted in what you can do.
2. You cannot expose the mechanism for getting authentication or password information in a script, as it can then be simply hijacked.
What you can do is have a client which connects to a service running on one of your servers, authenticates and requests a password. This can then use that password locally to initiate tasks and change security context.
In most real-world cases this is safe so long as:
- Your handshaking protocol and conversation encryption are at least as strong as the one that MS uses when authenticating.
- Your executable validates itself (MD5 cheksum) to ensure that it hasn't been messed about with.
- All tasks are internal to the executable or on a trusted server. Never execute binaries or scripts on the local machine. Never execute a script which executes binaries on the local machine. If you "shell" out a command in any way, you are inviting disaster.
- No member of staff who has access to the binary has the skills to extract the authentication routine and link to his own executable, or overwrite text strings in the executable so that it runs arbitrary code.
All-in-all it is a very tricky business. Using something like the task scheduler method to get jobs done is currently about the safest and by far the simplest method.
|
|
Top
|
|
|
|
Moderator: Shawn, ShaneEP, Ruud van Velsen, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Mart
|
0 registered
and 2375 anonymous users online.
|
|
|
