RE: [U2] Uniobjects hack
SNIP It's funny. D3 has the capability to assign a macro to any user who gets to tcl (or the debug prompt). Often this macro is either a login (again) or a logoff. Works great. U2 doesn't seem to have addressed this issue because their client base has never required it. Hopefully, now they do! SNIP I don't know about UniData, but in UniVerse, there is a subroutine called ON.ABORT that will execute if you have a program that 'ABORTS' (Goes to TCL via debugger/error). What I have done in this instance is just send them back to the menus. Regards Bjvrn Behr Programmer HYFLO Southern Africa (Pty) Ltd Tel : +27 11 386 5800 Fax : +27 11 444 5391 Mail: [EMAIL PROTECTED] WWW : http://www.hyflo.co.za --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
ON.ERROR ON.ABORT (and remote verbs) JayJay snip It's funny. D3 has the capability to assign a macro to any user who gets to tcl (or the debug prompt). Often this macro is either a login (again) or a logoff. Works great. U2 doesn't seem to have addressed this issue because their client base has never required it. Hopefully, now they do! Bill snip --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack (diverging into Outages I have known and loved)
BJ Yes I think it's pretty tight . I am sort of assuming everyone uses ON.ERROR and ON.ABORT as a matter of course. (Otherwise they are obviously not worried about security and keep their credit card PINS in their wallets and leave them on the sidewalk. On a sort-of-spin-off point - I (used to/another hat) test demonstrate RFS after I set it up and configured it for clients some years ago. - How do you do that? pull out the server power supply cable of course. It was AMAZING how unwilling people were to check everything worked. How Else? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frost, Bodo Sent: 01 June 2005 04:45 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, This combination just misses Level -1 (Minus One, or DefCon Dark Red): Pull the plug... :-D Cheers BJ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
JayJay It misses the point. I'm not talking about hackers from outside, I'm talking about valid, legitimate users with update access to the database because they have access to the relevant application but within that application are constrained by menus and application programs. If I load UniObjects onto their PC in order to provide downloads to Excel then if (big if, I know) they understand UniObjects and U2 they can then fire up Excel, add the UO reference and do pretty much what they like with VBA and U2 commands using their normal telnet login id and the direct path to the database instead of the nice secure account I've just set up specifically for UO. UO bypasses anything in the login para in the main account OK, I accept that this would be inappropriate behaviour, disciplinary offence etc but I prefer to keep the door to the computer room locked, instead of swinging wide open with a sign telling people not to go in. Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 31 May 2005 23:42 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack So what does this combination miss? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
JayJay: Neither one of these verbs are invoked if someone logs onto an account and goes directly to TCL (no menu desired). For instance, one creates a UO account with Q-Pointers, ON.ABORT, and a few other things to allow extraction of data. :-) The two functions you refer to are accessed, I believe, either via a BASIC error or a debug error. What I was referring to was D3 validates a user at TCL (and at debug). This way, the developer doesn't need to worry about all the ways this could happen, just that it happens. It doesn't matter whether it happens in the Unix or Windows implementation. Since I'm nowhere near as knowledgeable as I would like, I'm hoping I can find a solution to this sticky problem: from within U2 (and not from Unix this way and Windows that way), how can I guarantee only those I authorize, in the manner I authorize, can access resources? Along with UOLOGIN this information will always help. Thanks. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Jenkins Sent: Wednesday, June 01, 2005 1:01 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack ON.ERROR ON.ABORT (and remote verbs) JayJay snip It's funny. D3 has the capability to assign a macro to any user who gets to tcl (or the debug prompt). Often this macro is either a login (again) or a logoff. Works great. U2 doesn't seem to have addressed this issue because their client base has never required it. Hopefully, now they do! Bill snip --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les -Original Message- From: Piers Angliss [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 10:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://virus.e2e-filter.com/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
I agree it's unlikely, but it's something that needs to be considered I can't remember whether your branches are running PCs or dumb terminals but if the former, would you be happy to roll out an Excel/ UniObjects reporting tool/solution given your user population and distribution, some of whom might be IT students (or ageing U2 developers :-) ) working in part-time/ temporary positions ? I know I'd be wary of recommending it to you without clearly explaining the risks Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Les Hewkin Sent: 31 May 2005 11:09 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
The bigger threat is the ODBC/OLE-DB Connects as there are more chance of someone having SQL knowledge and being able to use Excel to access the database and update and delete records. This is a problem for Oracle, SQL Server and other Databases. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Piers Angliss Sent: Tuesday, 31 May 2005 9:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack I agree it's unlikely, but it's something that needs to be considered I can't remember whether your branches are running PCs or dumb terminals but if the former, would you be happy to roll out an Excel/ UniObjects reporting tool/solution given your user population and distribution, some of whom might be IT students (or ageing U2 developers :-) ) working in part-time/ temporary positions ? I know I'd be wary of recommending it to you without clearly explaining the risks Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Les Hewkin Sent: 31 May 2005 11:09 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
Even scarrier, if a person has telnet (almost definitely since its a OS supported application), a valid user id, password and knows how U2 works then they may be able to access data. No need to install UniObjects or purchase Excel. Depending on the version of UniData or network access, the user may be able to go as far as utilizing Windows Explorer to access / view UniData data. The user could use a file browser to view report information contained within the HOLD (_PH_ / PH) file. ... Ian - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, May 31, 2005 6:09 AM Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les -Original Message- From: Piers Angliss [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 10:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://virus.e2e-filter.com/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack Solution
An alternative method is looking at Single Sign On technologies. Single sign on technology would enable you to hide the username and password to UniVerse either through telnet, uniobjects or ODBC and all the user would know is the single logon which maybe tied to windows. Thus if someone tries to login through excel they would not know what is the login details for UniVerse. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Can we have a quick show of hands of those who have had there U2 system hacked? I am not saying that it's not an issue, I am just curious. I do not know of it happening. Les -Original Message- From: Ian Renfrew [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 13:33 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Even scarrier, if a person has telnet (almost definitely since its a OS supported application), a valid user id, password and knows how U2 works then they may be able to access data. No need to install UniObjects or purchase Excel. Depending on the version of UniData or network access, the user may be able to go as far as utilizing Windows Explorer to access / view UniData data. The user could use a file browser to view report information contained within the HOLD (_PH_ / PH) file. ... Ian - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, May 31, 2005 6:09 AM Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les -Original Message- From: Piers Angliss [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 10:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://virus.e2e-filter.com/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users
Re: [U2] Uniobjects hack
Bingo! Ian. If your users are good enough to hack together an application out of notepad, excel and uniobjects, then you've hired the wrong guy for that sales / counter job. Move him/her into the development group. Be carefull of over protecting your systems to the point they become more trouble to use than they are worth. It's also been interesting to watch the evolution of firewalls and applications over the years. How many apps can now make use of non html based data transfers via port 80? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
This is an issue for governance such as under SOX, Basel II and a number of other areas. It is an operational risk issue that has to be considered. The rule for operational risk is to identify the probability of something happening, what could be the cost/damage if it occurs and what is the cost of solving it. Whilst the likelihood is low, the potential to delete major files or commit fraud could be high; however the solution may not be too expensive. It is positive that people have identified a potential and the list has identified solutions, as this makes U2 not look micky mouse to auditors when these questions are broached. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Kibbey Sent: Tuesday, 31 May 2005 11:36 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Bingo! Ian. If your users are good enough to hack together an application out of notepad, excel and uniobjects, then you've hired the wrong guy for that sales / counter job. Move him/her into the development group. Be carefull of over protecting your systems to the point they become more trouble to use than they are worth. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
In 15 years with my last job, I know of 3 times when bored users found their way into parts of the system that should not have been accessable, but were left open through a philosophy of security by obscurity on the part of the developer. In 2 of those cases the user reported the problem, and in the third, significant damage was done (by accident, on the part of a user who had gotten their hands on a manual and was trying to select vustomers by install date, but instead ran an install program). I also know of 2 attempts by disgruntled former employees to do damage, one successful, again because of security by obscurity. So it does happen. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Les Hewkin Sent: Tuesday, May 31, 2005 8:29 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Can we have a quick show of hands of those who have had there U2 system hacked? I am not saying that it's not an issue, I am just curious. I do not know of it happening. Les -Original Message- From: Ian Renfrew [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 13:33 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Even scarrier, if a person has telnet (almost definitely since its a OS supported application), a valid user id, password and knows how U2 works then they may be able to access data. No need to install UniObjects or purchase Excel. Depending on the version of UniData or network access, the user may be able to go as far as utilizing Windows Explorer to access / view UniData data. The user could use a file browser to view report information contained within the HOLD (_PH_ / PH) file. ... Ian - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, May 31, 2005 6:09 AM Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les -Original Message- From: Piers Angliss [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 10:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://virus.e2e-filter.com/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message
RE: **POSSIBLE SPAM**::RE: [U2] Uniobjects hack
From: Les Hewkin Can we have a quick show of hands of those who have had there U2 system hacked? I was accused of it once by a system administrator because I pointed out the security hole that I was then accused of wriggling through. This was the same system administrator who once ended up as the punchline of a Scott Adams cartoon. Coincidence? Perhaps. I am not saying that it's not an issue, I am just curious. I do not know of it happening. Security through Ignorance is a common strategy. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Pretty rare, in 20 years as a PI/U2 software/ services provider I've experienced only one confirmed instance This was of repeated inappropriate access by a legitimate user with a grudge who found a back door into the database and by resetting control records caused quite serious problems for a few months. The individual concerned would have been more than capable of figuring out how to use UniObjects I accept the chances are pretty slim and if it was my system I'd probably decide that the benefits outweighed the risk. Equally, I don't think it should take much work on IBM's part to provide something like UOLOGIN so that we can prevent valid telnet users who for historic reasons have full access to the database but are carefully cocooned in menus and application programs from giving themselves access to TCL via UO Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Les Hewkin Sent: 31 May 2005 14:29 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Can we have a quick show of hands of those who have had there U2 system hacked? I am not saying that it's not an issue, I am just curious. I do not know of it happening. Les --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
Les, All the hacking I've seen has come through the front door - it has always been authorized people using the system in the way in which they were authorized. I've had senior executives who have sabotaged their own systems. - Chuck Les Hewkin wrote: Can we have a quick show of hands of those who have had there U2 system hacked? I am not saying that it's not an issue, I am just curious. I do not know of it happening. Les --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
There were a few times that I've seen people exploit the fact that they knew how to cause the program to error out to get them to the prompt level. Then it was open season for them since we were just working off a menu based security. They were just trying to be more efficient in how they worked. Using the program took too long. It was faster just to edit the records. Was the reasoning. They couldn't get to the payroll account but they could have if they knew how to make a pointer to the files in that account. Things could have been worse. A few bill of materials and some pricing needed to be fixed but nothing major. Jeffrey Lettau ERP Systems Manager polkaudio -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Les Hewkin Sent: Tuesday, May 31, 2005 9:29 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Can we have a quick show of hands of those who have had there U2 system hacked? I am not saying that it's not an issue, I am just curious. I do not know of it happening. Les -Original Message- From: Ian Renfrew [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 13:33 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Even scarrier, if a person has telnet (almost definitely since its a OS supported application), a valid user id, password and knows how U2 works then they may be able to access data. No need to install UniObjects or purchase Excel. Depending on the version of UniData or network access, the user may be able to go as far as utilizing Windows Explorer to access / view UniData data. The user could use a file browser to view report information contained within the HOLD (_PH_ / PH) file. ... Ian - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, May 31, 2005 6:09 AM Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les -Original Message- From: Piers Angliss [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 10:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://virus.e2e-filter.com/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify
RE: [U2] Uniobjects hack
So what does this combination miss? Level 1 --- 1. Use a firewall with a DMZ and reverse lookup so only designated client PCs can access specific systems (and audit) 2. User Public Key based application level authentication between VALID client applications and the server to permit valid connects only with UOLOGIN 3. Stop any software being loaded on any PC except by IT admin staff (to stop keyboard snoopers grabbing IDs and passwords). 4. After repeated invalid access attempts block the ID. Level 2 --- 5. Use SSL to stop IDs and Passwords being sent in plain (network sniffers etc) if you are that twitchy / unsure about local PC lockdown or hardware devices being introduced into the network. 6. Use fixed IP addresses and MAC addresses - directly associate BOTH with the specific ID and Password that can use that workstation at the application level (UOLOGIN). 7. Use a magnetic eraser for all tapes and FDDS that are to be dumped 8. Use secure disposal of all old HDDs (heating above Curie point / destroying etc). There are reputable companies that offer this service. 9. Make all offensive verbs REMOTE verbs and positively authenticate using credentials in a named COMMON block. Level 0 - yes 0 - I have seen ALL of these --- 0.1 Stop stringing Network cables between Windows outside the building just because it is easier than re-routing. (Gosh - look at that handy network access point...) 0.2 Lock the office doors to stop people wandering into the computer room and walking off with the kit (really ! Honest!). (And they did it to the same site 2 weeks on the trot). The (old) kit from week 1 was found dumped, when brand new kit was installed in week 2 they stole that for resale. 0.3 If you are using a Wireless network then please, please encrypt it properly, use decent authentication, and check the log files.(use email authentication of invalid access attempts). It is AMAZING what wireless LANS I pick up when out and about. 0.4 Shoot the guy who added a wireless repeater to the LAN to work from outside when it was hot. 0.5 Use real IDs and passwords - not names, birthdays etc. Oh yes - don't change them so often that people HAVE to write them down to remember them (death by password). If you have a BIOS password, a HDD password, a Windows ID password, a Network password, an application login ID and password, a screen saver password and force regular changes and prevent re-use/duplication and stop anything that even LOOKS like a word then you can't tell ME no-one writes them down and sticks them next to a screen somewhere... 0.6 Remove the following: 0.6.1 Root password written on wall next to computer room light switch (visible through window) 0.6.2 Administrator login written on back of office calendar (can be found 1st working day in New Year in the trash can). In Attorneys offices it usually has the safe combination written on the back of it as well (handy). 0.6.3 Don't leave the computer room door / window open to the street because it gets hot (which is why there was no-one in there at the time). 0.6.4 Dumping old HDDs after an upgrade in boxes outside to be collected 0.6.5 Dumping old magnetic tapes in the trash BONUS: For those who know me personally: It is AMAZING how many people are good enough to open secure doors when I walk up to them. Not just folks who know me (thanks folks!) - but also lots of other kind and friendly people. They will also carry all sorts of stuff after helping me unplug cables and even load up. I am looking for someone who will help me with all that heavy cash in the safe (drop me a line - I am willing to come and collect). I have only seen hacking twice - both times by insiders. Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
Les, this is a situation i have right now which is why i raised this. So far no damage has been done but i know the guy is trying and has enogh of free time to play around. Its unlikely that you will get a user who knows the workings of Universe but some do know VBA and ODBC/OLEDB well enough to think they can get the information they require by doing it themselves.without going through the official menus. jak - Original Message - From: Les Hewkin [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, May 31, 2005 7:39 PM Subject: RE: [U2] Uniobjects hack I have been following this thread with great intrest. The issues seems to be that if someone has Excel, UniObjects and knows how U2 works that they can gain access to the data. Where are these people? Are they working for the IT department? Is this a real life scenario? or an exercise in theory of what might happen? Les -Original Message- From: Piers Angliss [mailto:[EMAIL PROTECTED] Sent: 31 May 2005 10:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack JayJay, Reading between the lines I think you're saying a firewall could be a good idea I'm not sure that the other methods will work though. As I understand the problem, it is that you can have a secure VB App using UniObjects on a secure PC but if I have access to Excel on that PC, together with a valid server login id and password (with update rights) and basic knowledge of the directory structure on the server then techniques 2, 5, 6 7 won't trouble me at all. Ok, I need to understand UniObjects and U2. I'm not even sure that a firewall would help because the PC I'm trying to hack the database from has a valid IP address to run the VB App As somebody looking to implement UniObjects alongside traditional server-based applications that's a big hole. I can plug it by taking David Jordan's advice and using AUTHORIZE, but that's a lot of work for me at this stage. It sounds like UOLOGIN is a step in the right direction, but it is only available on UniData and if Ian's experience is any guide may have some implementation issues. I've been impressed with how easy it is to use UniObjects, I'm less impressed now. The functionality is great but in too many cases it's just a hugely inviting route to hack the database, it needs better server-side authentication Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: 30 May 2005 01:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://virus.e2e-filter.com/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Above the IT security, you should have a policy on appropriate behaviour. You should ensure that users are aware that unauthorised access and attempts to access the system outside of the facilities provided is a sackable offence and make sure they understand that you check logs for such accesses. Should discourage the casual player. Regards David Jordan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Kent Sent: Wednesday, 1 June 2005 8:43 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Les, this is a situation i have right now which is why i raised this. So far no damage has been done but i know the guy is trying and has enogh of free time to play around. Its unlikely that you will get a user who knows the workings of Universe but some do know VBA and ODBC/OLEDB well enough to think they can get the information they require by doing it themselves.without going through the official menus. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Of course you could just stop anyone loading or using any development tools unless they are authorised to do so Making it a sackable offence usually works (I think that's a pink sheet for those on the western side of the Pond) Otherwise set the firewall to only accept connections on the UO port from designated IP addresses. Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall I know I said firewall 3 times but I'll say it again *firewall* - there. Why? Because far too many people pay attention to firewalls - that's why I keep on saying use a firewall - yes really - firewalls are good ideas - yep so are DMZs with firewalls. See - I said firewalls again. BTW: Own up - who never changed their default RedBack administrator ID !!AND!! password. Own up folks - how many defaults are there still out there - we all know the default password I am sure? And yes - I have seen RBOScope access possible from the WWW with the default ID and password. Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Did you mean to say carhacked? Mind you, having a finger dangling from your key-ring instead of rabbits foot would sure be a tip-off at key-parties. S What about the thieves who carjacked a Merc? Because it was biometrically started, they chopped off the driver's finger so they didn't need him to start the car. ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack]
According to the IBM website, UOLOGIN must be a globally cataloged subroutine with two arguments. First argument is a return value. If set to zero, login is rejected and error code 80011 is returned. Second argument is input to the subroutine and contains the application name. Example: SUBROUTINE UOLOGIN( RETURN.VALUE, APPLIC.NAME ) IF APPLIC.NAME = SOMETHING THEN RETURN.VALUE = 0 END ELSE RETURN.VALUE = 1 END RETURN END N.B., I haven't tested this. The document references software version 6.x. Might only work on UniData. Steve Johnson FXA Group Ltd. Bangkok --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack]
Tried this on UniData for Windows PE, version 6.1.7. If I set RETURN.VALUE to zero (0), I encounter the error code 80011 which is great. If I set RETURN.VALUE to one (1), It appears as if I need to re-establish session connection for each database access. Not really what I was expecting. Once I've established my connection, I shouldn't need to re-connect. Noticed that my catalog verb is now screwed up. Is their some dependency on a version of AE? Also, I'm curious as to how I would pass the second argument (application) from my client/server application to the host? If this is done by referencing the subroutine method, then my hack still gets in by guessing at a valid application code. This is no different than guessing at a password. Regards, Ian Renfrew - Original Message - From: Steve Johnson [EMAIL PROTECTED] To: U2UG u2-users@listserver.u2ug.org Sent: Saturday, May 28, 2005 3:27 AM Subject: Re: [U2] Uniobjects hack] According to the IBM website, UOLOGIN must be a globally cataloged subroutine with two arguments. First argument is a return value. If set to zero, login is rejected and error code 80011 is returned. Second argument is input to the subroutine and contains the application name. Example: SUBROUTINE UOLOGIN( RETURN.VALUE, APPLIC.NAME ) IF APPLIC.NAME = SOMETHING THEN RETURN.VALUE = 0 END ELSE RETURN.VALUE = 1 END RETURN END N.B., I haven't tested this. The document references software version 6.x. Might only work on UniData. Steve Johnson FXA Group Ltd. Bangkok --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
You might want to look at the article in the U2UG newsletter on security. http://u2ug.org/docs/20040919_U2UG_Newsletter.pdf that deals with this issue. With Universe a program can have higher access rights than the user. If a user gets to tcl they may not have access rights to update, enquire or delete records in a file. However they can run a program that can update that same file. This may solve the issue of UniObjects from Excel to access tcl and the security issue. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
How about using file level security, and common area in your subroutines. Marc Harbeson ERP/Systems Administrator Brinly Hardy Company O - (812) 218-7206 F - (812) 218-6084 [EMAIL PROTECTED] www.brinly.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Kent Sent: Friday, May 27, 2005 2:03 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Steve, thanks for that jak - Original Message - From: Steve Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org; U2UG u2-users@listserver.u2ug.org Sent: Friday, May 27, 2005 2:46 PM Subject: Re: [U2] Uniobjects hack How about running a monitor program constantly in the background. It monitors all new logins to U2. The new login process must send a sleeping pill to the monitor within a short time after login -- short being relative to your system performance. If the monitor doesn't receive this sleeping pill then it kills the new login. The trick here is to keep the requirement for this sleeping pill as secret as possible; and to invent one that cannot be easily spoofed; and to insure that the monitor is always active. Steve Johnson FXA Group Ltd Bangkok --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
The ability to bypass application security using UniObjects has really got me thinking. In the absence of any suitable remedies and perhaps as a stop gap solution whilst a better solution is written, I would recommend the following: 1. As Martin said, make sure that you do not let UniObjects traffic through your firewall. This cuts down the threat from outside but many hacks come from employees who are disgruntled or just plain nosey. 2. If you don't require UniObjects on all PCs then don't install it. If you do require it, don't install the documentation that gives the user a sample application to copy. Change the standard port used by UniObjects and don't advertise it. 3. Consider an architecture where the UniObjects client is a separate server (e.g. web server or Citrix server) and users don't require the UniObjects DLLs on their own client. This is also easier to maintain when you upgrade. 4. In addition to application security, make use of OS security. For example, if your HR system is only used by a handful of people, don't give all your users access to the data files and rely on the application security to keep them away. If they have to steal a password as well as write a VBA program, it is harder than just writing a VBA program. 5. Don't hard code usernames and passwords into your source code! They can be seen in the object code of any application. 6. Keep an eye on logs and look out for unusual behaviour. Can anyone help me with this? What logs are written to when someone logs in and can you distinguish between a telnet login and a UniObjects login? The reason it got me thinking was because I am guilty on a number of these points :- so thanks for the question! Regards, Rob Wills (rob dot wills at tigerinfotech dot com) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
How about using file level security, and common area in your subroutines. The problem remains that a user who can validly use the application must have access to these files and hence can open them and tinker in his own VB program. It all comes down to the fact that UV/Udt cannot tell the difference between a valid VB application and someone's own private little program. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
The same issue applies for SQL access to UniVerse as it does for UniObjects. It is a problem for RDBMS. They get around by restricting access and only allowing updates through Stored Procedures which can have a different access level. UniVerse can do the same thing. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, May 27, 2005 10:56 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack The ability to bypass application security using UniObjects has really got me thinking. In the absence of any suitable remedies and perhaps as a stop gap solution whilst a better solution is written, I would recommend the following: 1. As Martin said, make sure that you do not let UniObjects traffic through your firewall. This cuts down the threat from outside but many hacks come from employees who are disgruntled or just plain nosey. 2. If you don't require UniObjects on all PCs then don't install it. If you do require it, don't install the documentation that gives the user a sample application to copy. Change the standard port used by UniObjects and don't advertise it. You can still sniff out open ports easily. Your best bet is to map port access by IP class range and exclude departments that don't need access. Of course, if the network is all over the place then you'll need to specify filtering by IP. 3. Consider an architecture where the UniObjects client is a separate server (e.g. web server or Citrix server) and users don't require the UniObjects DLLs on their own client. This is also easier to maintain when you upgrade. DMZ setup is still a big part of the equation if you use a remote machine to host a connectivity portal. The only problem there is traceability, if someone where to hack into that box and gain root/admin privs. The same can be said for any box on the LAN, except you won't be looking for oddball IP-based activity if it's all coming from one machine. :P 4. In addition to application security, make use of OS security. For example, if your HR system is only used by a handful of people, don't give all your users access to the data files and rely on the application security to keep them away. If they have to steal a password as well as write a VBA program, it is harder than just writing a VBA program. 5. Don't hard code usernames and passwords into your source code! They can be seen in the object code of any application. You can concatenate raw characters together to form a username or password, and you won't be able to easily pull the object code up in hexedit and look for stored strings. You can also use an internal character shifting algorithm to make it harder to dechiper what's what in the object code. 6. Keep an eye on logs and look out for unusual behaviour. Can anyone help me with this? What logs are written to when someone logs in and can you distinguish between a telnet login and a UniObjects login? If you are firewalling the box, then you should be able to log incoming traffic regardless of destination port. If not, then setup a firewall router that can log and report activity. A 586 with 32MB of RAM will run a Linux firewall just fine. Glen http://mvdevcentral.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack {Unclassified}
In message [EMAIL PROTECTED], HENDERSON MIKE, MR [EMAIL PROTECTED] writes Things will get better? No, things will get much, MUCH worse! When someone finds out my password, then to repair the security breach, I have to change my password. When someone finds out the magic number which is the encoding of my fingerprint, then to repair the security breach I have to ... um, no I can't fix that problem. What about the thieves who carjacked a Merc? Because it was biometrically started, they chopped off the driver's finger so they didn't need him to start the car. Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Richard: Am I accurate in thinking Pick __USED__ to have file level security but it doesn't exist in the U2 products because, it was always said, the O/S takes care of security (aka: we don't need no stinkin file level security)! Perhaps, having dbms security isn't such a bad idea after all. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Taylor Sent: Friday, May 27, 2005 8:09 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack [snipped] 2) Convert the account to an SQL schema. You can then attach file level security via the SQL user. Just remember to create a security entry for Public too otherwise you could end up locking out all the other users that are not subject to the tighter security. (i.e. GRANT ALL TO PUBLIC) If you are trying to allow them to access a file, but control what they do you may be out of luck. However you could use triggers to a least create audits. [snipped] Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
All, The BetterBetter committee (got an idea for an improvement or fix? email [EMAIL PROTECTED]) has been listening in and kicking this around. Here's what we've come up with so far: UniData *has* a UOlogin functionality which will allow you to vett the user and decide if they can connect as a UO connection. You could build most of what you want in there. We haven't tested it on UniVerse, but I have the PE and UO set up, so if no one gets to it by Monday, I'll test it and let everyone know. - Chuck --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Actually, when you convert an account to a schema you can use SQL security to do this. This is what I am referring to. You need to setup SQL users in your schema (same login used to get into UV) or set privileges for PUBLIC. If the user exists in the Schema user table then those permissions are used otherwise the PUBLIC setting is used. Note that you can use an account as both a schema and a regular account. This is the reason I needed to set all permissions for PUBLIC. I have done this under Universe to provide some basic security related to using Uniobjects in the past. I am not sure if this will fully solve the issue being discussed here or if Unidata would behave the same way. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. The more they complicate the plumbing the easier it is to stop up the drain - Montgomery Scott NCC-1701 Richard: Am I accurate in thinking Pick __USED__ to have file level security but it doesn't exist in the U2 products because, it was always said, the O/S takes care of security (aka: we don't need no stinkin file level security)! Perhaps, having dbms security isn't such a bad idea after all. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Taylor Sent: Friday, May 27, 2005 8:09 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack [snipped] 2) Convert the account to an SQL schema. You can then attach file level security via the SQL user. Just remember to create a security entry for Public too otherwise you could end up locking out all the other users that are not subject to the tighter security. (i.e. GRANT ALL TO PUBLIC) If you are trying to allow them to access a file, but control what they do you may be out of luck. However you could use triggers to a least create audits. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
UniData *has* a UOlogin functionality which will allow you to vett the user and decide if they can connect as a UO connection. You could build most of what you want in there. We haven't tested it on UniVerse, but I have the PE and UO set up, so if no one gets to it by Monday, I'll test it and let everyone know. These are all great ideas but they still do not address the fundamental problem A user who can validly make a connection to use an application can write his own client program to subvert the system. None of the proposed solutions solve this. As far as we can see, it requires a change to the server side of Uniobjects (hence the solution to the equivalent functions in our product). Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
Martin, Not true. Using UOlogin, I could run a filter and only allow a subset of the valid user list access. That would stop people from using telnet ids as UO ids. If you expand this to lock out some accounts to ALL UO logins, you can draw a box around the UO user. Now, if you said 'great ideas but they take too much work' then I'd be inclined to agree with you. We need a simpler way. - Chuck Simple Barouch Martin Phillips wrote: These are all great ideas but they still do not address the fundamental problem A user who can validly make a connection to use an application can write his own client program to subvert the system. None of the proposed solutions solve this. As far as we can see, it requires a change to the server side of Uniobjects (hence the solution to the equivalent functions in our product). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
I have looked at all of the documentation that I have and can't find ANY reference to UOLOGIN, UOlogin, ... Is this documented anywhere? I tried to create a simple PROC (UniData 6.1PE) and it doesn't execute on login. The interesting thing is that if I create and direct catalog a program called UOLOGIN, I can't login anymore (with UniObjects). It's either a coincidence or it may mean that there is something special that needs to be passed back in order to complete the connection. Regards, Jim UniData *has* a UOlogin functionality which will allow you to vett the user and decide if they can connect as a UO connection. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Chuck, Thanks! Regards, Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Key Ally Sent: Friday, May 27, 2005 7:08 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack James, Here's a link on the IBM site. http://www.ibm.com/Search/?q=UOLoginv=14lang=encc=zzSearch.x=50Search. y=11Search=Search - Chuck --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
And the good reason why IBM restricts access to this information so only VARs and End-Users with direct support contracts can see it is? Why is this not in a publicly accessible piece of documentation? The number of times I have tried to register for an IBM techconnect ID and been refused because I'm a consultant not a VAR/End User is frustrating! :-( Cheers, Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Key Ally Sent: Saturday, 28 May 2005 9:08 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack James, Here's a link on the IBM site. http://www.ibm.com/Search/?q=UOLoginv=14lang=encc=zzSearc h.x=50Search.y=11Search=Search - Chuck James Canale, Jr. wrote: I have looked at all of the documentation that I have and can't find ANY reference to UOLOGIN, UOlogin, ... Is this documented anywhere? I tried to create a simple PROC (UniData 6.1PE) and it doesn't execute on login. The interesting thing is that if I create and direct catalog a program called UOLOGIN, I can't login anymore (with UniObjects). It's either a coincidence or it may mean that there is something special that needs to be passed back in order to complete the connection. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
I agree with you. I am a end-user and we do not have access to IBM'S secure technical notes. I understand that my company may be allowed to purchase software support to allow us to see these restricted documents. Ken Wallis [EMAIL PROTECTED] wrote: And the good reason why IBM restricts access to this information so only VARs and End-Users with direct support contracts can see it is? Why is this not in a publicly accessible piece of documentation? The number of times I have tried to register for an IBM techconnect ID and been refused because I'm a consultant not a VAR/End User is frustrating! :-( Cheers, Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Key Ally Sent: Saturday, 28 May 2005 9:08 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack James, Here's a link on the IBM site. h.x=50Search.y=11Search=Search - Chuck James Canale, Jr. wrote: I have looked at all of the documentation that I have and can't find ANY reference to UOLOGIN, UOlogin, ... Is this documented anywhere? I tried to create a simple PROC (UniData 6.1PE) and it doesn't execute on login. The interesting thing is that if I create and direct catalog a program called UOLOGIN, I can't login anymore (with UniObjects). It's either a coincidence or it may mean that there is something special that needs to be passed back in order to complete the connection. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
The most secure way would be to turn off the service. :) Of course, there are a couple of different ways a determined, advanced user could do to get access. Colin Alfke Calgary, Canada -Original Message- From: John Kent Does anyone have any suggestions on how to contain an advanced user from attaching the uniobjects control as a reference in excel and working out how to get access to the system. Uniobjects doesnt go in through a login paragraph. Thanks in advance jak --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
Twiddle the PAM config file if your on unix so that services don't go through the user login process. Send them off to something else... I don't know of anyway to keep them out of a Windows system though. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Doesn't UniObjects have to go through a 'login in' of types identifying the user, even though it is not executing the LOGIN paragraph? And if so, can you use the underlying OS to make files 'safe' from those users, restricting even read-access? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Kibbey Sent: Thursday, May 26, 2005 8:36 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Uniobjects hack Twiddle the PAM config file if your on unix so that services don't go through the user login process. Send them off to something else... I don't know of anyway to keep them out of a Windows system though. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
This is a hole in the Uniobjects security. A user who has a valid username and password to access a Uniobjects application can write his own VB program to do almost anything; modify files, write VOC entries, upload, compile and run programs. Using o/s security is fine but the user will have unrestricted access to all files that the application would normally use. This seems to leave UV/Udt systems that enable Uniobjects wide open to hacking. Try it! Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Well, let's not put this all on UO. Almost all of the connectivity tools in our market were written without any thought of security. It's generally assumed that if you have a valid password to the system that you are authorized to use whatever means available to get in. What I don't like is that some/most of the connectivity products in our market don't have any point to point encryption and pass all data in plain text - including user ID's and passwords. Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD .com Martin Phillips MartinPhillips-at-ladybridge.com |U2UG| wrote: This is a hole in the Uniobjects security. ... ... This seems to leave UV/Udt systems that enable Uniobjects wide open to hacking. Try it! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Just because this is a wider problem doesn't mean that UO shouldn't be called on it. Why security hasn't been an issue is beyond me - how many systems do you know of that allow a user to login and have free reign ? usually they are restricted to what they can access do by a menuing system of some sort that never allows standard users access to anything but allowed programs. If you're not worried about every shmoe with a password having access to your system why worry about session encryption ? Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tony Gravagno Sent: Thursday, May 26, 2005 02:14 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Uniobjects hack Well, let's not put this all on UO. Almost all of the connectivity tools in our market were written without any thought of security. It's generally assumed that if you have a valid password to the system that you are authorized to use whatever means available to get in. What I don't like is that some/most of the connectivity products in our market don't have any point to point encryption and pass all data in plain text - including user ID's and passwords. Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD .com Martin Phillips MartinPhillips-at-ladybridge.com |U2UG| wrote: This is a hole in the Uniobjects security. ... ... This seems to leave UV/Udt systems that enable Uniobjects wide open to hacking. Try it! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Just because this is a wider problem doesn't mean that UO shouldn't be called on it. So how would you go about it? UO is a tool for developers. As such, it's strength is that it is able to do anything a developer needs it to do. It is clean client/server middleware and so it can't launch a menu system or anything else that requires interaction at the server. So how can it tell the difference between a legitimate connection from a controlled application, and an illegitimate connection from e.g. a piece of VBScript hacked into notepad? The only way is to add a new security layer to the server. And if you insist on that there are a lot of applications out there that will simply stop running. Witness how many UniVerse sites have jumped to convert their old accounts into SQL schema with proper permissions and constraints. (I haven't seen any). So a hole it may be, but I guess we're stuck with it. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
So how can it tell the difference between a legitimate connection from a controlled application, and an illegitimate connection from e.g. a piece of VBScript hacked into notepad? The easy answer is that it cannot. We had to think very hard about this when we designed the equivalent of Uniobjects for QM (this is not a plug!). The only watertight solution seems to be to give the user the option to restrict what can be done over a client connection. Our highest level of restriction limits the client connection to calling only subroutines that are built with a special compiler directive. This works well for us. Perhaps UV/Udt need to do something similar. Don't forget to ban incoming connections to the appropriate port in your firewall if you use UniAdmin in-house and don't want hackers finding their way in from outside. A determined hacker will find a user name/password given long enough. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
The point isn't whether you can get in. The point is what you can do once you get in. Some connectivity tools only allow you to execute a routine that already exists as a catalog entry in the U2 environment, and merely scraps the data sent back. Those seem fairly inocuous. However I agree that this ability to execute *any* hacked script once you have a password is a serious security concern. If this was a Microsoft product it would be all over the news. There are plenty of clerks who you give a password to, in order to do things like process orders from home. You wouldn't want to walk in at 8am Monday morning to find that their bright teenager has used that password to transfer a million dollars into their checking account using your automated banking system. Right? Will Johnson Fast Forward Technologies -Original Message- From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thu, 26 May 2005 11:13:48 -0700 Subject: RE: [U2] Uniobjects hack Well, let's not put this all on UO. Almost all of the connectivity tools in our market were written without any thought of security. It's generally assumed that if you have a valid password to the system that you are authorized to use whatever means available to get in. What I don't like is that some/most of the connectivity products in our market don't have any point to point encryption and pass all data in plain text - including user ID's and passwords. Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD .com Martin Phillips MartinPhillips-at-ladybridge.com |U2UG| wrote: This is a hole in the Uniobjects security. ... ... This seems to leave UV/Udt systems that enable Uniobjects wide open to hacking. Try it! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
To answer both questions about unauthorized client access and then about encryption: Brian wrote: The only way is to add a new security layer to the server. I think the way to do this on the client side (wherever the UO DLL is kept and a connection initiated) is to have a separate DLL which fully encapsulates UO and exposes all of the methods and properties, but adds a simple layer of authorization. Any authorized application built with this component would incorporate the key to unlock access to it - any code attempting to use the component without a valid key would fail to initiate a connection, let alone get to a user login. Doing this manually would involve way too much work, and a simple wrapper used by legit apps would still leave the uniobjects.dll on the client system for renegade coders, so it should be done by IBM. Two DLLs can be provided, one with the key mechanism and one without, and existing apps can choose which they want and swap references and recompile as they wish. Do I think this will happen with UO or any other MV connectivity component? Nah. Gerry wrote: If you're not worried about every shmoe with a password having access to your system why worry about session encryption ? User/password authentication is pretty much the only thing most IT installations have for access control. When companies start using biometrics for fingerprint, voice, and retinal scans, things will get better, but even with this technology, an authorized user IS authorized when they have valid credentials. There's nothing you can do about this except implement server-side restrictions, field-level ACLs (not supported by U2 anyway), etc. If that privilege is being abused then less technical remedies need to be pursued, like job termination - or maybe baseball bats, an effective italian solution. The original thread point is that there can be abuse by people with credentials. My point on encryption was that even people without credentials can easily sniff the wire. Those are the people you really need to worry about. I'm not portraying either problem to be more or less significant, just pointing out yet another problem that's unfortunately industry-wide. Will wrote: The point isn't whether you can get in. The point is what you can do once you get in. That's yet another problem that's left to the app developers to solve. Related, but at another level, the database model itself isn't very secure either. Ask the MV DBMS vendors whether their product is SOX compliant and see what kind of response you get. Have a nice insecure day. ;) Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD .com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack {Unclassified}
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Friday, 27 May 2005 12:15 To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniObjects hack [snip] Gerry wrote: If you're not worried about every shmoe with a password having access to your system why worry about session encryption ? User/password authentication is pretty much the only thing most IT installations have for access control. When companies start using biometrics for fingerprint, voice, and retinal scans, things will get better, but even with this technology, an authorized user IS authorized when they have valid credentials. Things will get better? No, things will get much, MUCH worse! When someone finds out my password, then to repair the security breach, I have to change my password. When someone finds out the magic number which is the encoding of my fingerprint, then to repair the security breach I have to ... um, no I can't fix that problem. But they can't find out the magic number which is the encoding of my fingerprint, can they? Wanna bet? Wanna bet your whole bank balance, your drivers licence, your passport, your whole legal existence on it? Your soon-to-be issued USA or EU Passport will have an RFID tag in it containing some biometric information, probably a fingerprint. The RFID tag is _supposed_ to be readable at ~8inch / 200mm ranges, but it won't be long before some clever person creates an unobtrusive transmitter / receiver setup which will do it over ten times the distance. But it's encrypted you say. This is such valuable information that it'd be worth throwing a _lot_ of time, money computer hardware at it. Some of the Eastern European criminal gangs have not only all these, but access to some very, very smart people, too. Actually, the encrypted value may be good enough to fool some devices. Biometrics are a bad, bad, BAD idea My $0.12 worth Mike [snip] The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Uniobjects hack
How about running a monitor program constantly in the background. It monitors all new logins to U2. The new login process must send a sleeping pill to the monitor within a short time after login -- short being relative to your system performance. If the monitor doesn't receive this sleeping pill then it kills the new login. The trick here is to keep the requirement for this sleeping pill as secret as possible; and to invent one that cannot be easily spoofed; and to insure that the monitor is always active. Steve Johnson FXA Group Ltd Bangkok --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
