 |
|||||
|
As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Join the TIBCO Community
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community. | |||||
Focal Point 
Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point IBIC_pass Exposes Mainframe Password
Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point IBIC_pass Exposes Mainframe Password Read-Only TopicGo | Search | Notify | Tools |
| IBIC_pass Exposes Mainframe Password | Login/Join |
| Member |
We use WebFOCUS client 5.3.2 with a MVS Reporting Server. User authenication at WebFOCUS sign-on time is via the User's mainframe ID and Password. WebFOCUS captures these values and stores them in &IBIC_user and &IBIC_pass respectively. Is there a way to configure WebFOCUS so that &IBIC_pass is not visible or available? This seems to be a security breach in that anyone who knows how to access &IBIC_pass can literally get the password of any WebFOCUS User in the entire Entrerprise. WebFOCUS 716 MVS DB2 AIX UDB | ||
|
| Expert |
Ed, A minor item compared to the fact that a certain university in Northern USA has their WebFOCUS portal open to the Internet and you can even access the adhoc fex page. Just suppose some person with dubious intentions wanted to write a piece of code such as - CMD ERASE C:/*.* into the adhoc fex. Who do you think the Uni would blame? I can now imagine all the Unis in the US of A running around to see if they have this similar exposure. How did I find this particular Uni? A google search for a WebFOCUS problem! Sorry for highjacking your topic but I just wanted to point out that security (as you know) is very important and not something a lot of sites think about! The Uni in question appears to have plugged their little hole now. T
| |||||||||
|
| Expert |
yikes Ed, get in touch with Jim Thorstad at IBI in ny, he's the guy who gives the security talks at summit, or open a case with CSS and request that the css rep contact Jim for you. hmm. no secrets google can't uncover
| |||||
|
| Expert |
I have let someone at the Uni know that they have this breach and I have rechecked and it isn't plugged!! It wasn't me that found this hole either, I just feel that the community should know about these things when they expose their reporting portal to the wider internet. T
| |||||||||
|
| Virtuoso |
IBIC_user and pass are usually configured with a (dontpass) option. This implies that they should not be available beyond the web application. Has someone messed with the site.wfs or another .wfs file and removed the dontpass option? As far as the CMD ERASE stuff, the server can be configured to not allow op system level commands, thereby preventing this type of attack. "There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott | |||
|
| Gold member |
Tony, Considering that it required a Technical Memo 4608 issued on 7.1 before this security hole was identified and plugged, it's not surprising that the adhoc fex application is still accessable by non-managed reporting users at a number of installations across the globe. I know our university was bit by this for a period of time after our initial install. Perhaps Kerry can offer a suggestion of the best way to forward security notifications uncovered by colleagues to the appropriate IBI customer contact? Dan Kenny University of Nebraska at Omaha Prod: WF 7.1.6 Linux BID/MRE/Data Migrator Test: WF 7.6.1 Linux BID/MRE/Data Migrator | |||
|
| Virtuoso |
Ironically, I was checking my SITE.WFS file to see how I plugged this hole to share with everyone on Focal Point and I discovered that I actually only narrowed the hole, not plugged it. Go figure. It is plugged on our production servers now.  I did this by using the following code in the SITE.WFS config file. <ifdef> IBIF_adhocfex <htmlform> &APPROOT/baseapp/wfverr98.htm <exit> <endif> Simply put, if the IBIF_adhocfex variable exists, deny the request and send back an HTML page containing a customized error message. I permit no usage of the IBIF_adhocfex variable on our production boxes. I don't think this will work for everyone since DevStudio uses this variable at times if not all the time. Does anyone else have a better or more elegant solution? I could not find the Tech Memo on Tech Support. Thanks! Mickey
| |||||
|
| Gold member |
The TM4608 has you invalidate a lot of IBI variables - it also knocks out your ability to run the New Century Corp demos  -- I ended up punching a hole through for IBIAPP_app directory ibinccen......
<if> IBIMR_user EQ NULL OR IBIMR_user EQ ""
<if> IBIF_adhocfex NE NULL OR IBIF_adhocfex NE "" OR \\=
IBIF_ex NE NULL OR IBIF_ex NE "" OR \\=
IBIF_focexec NE NULL OR IBIF_focexec NE "" OR \\=
IBIF_raw NE NULL OR IBIF_raw NE ""
<htmlform> &IBI_HTML_DIR/errorpage.htm
<exit>
<endif>
<endif>
Dan Kenny University of Nebraska at Omaha Prod: WF 7.1.6 BID/MRE/Data Migrator Test: WF 7.6.1 BID/MRE/Data Migrator | |||
|
| Powered by Social Strata |
 | Please Wait. Your request is being processed... |
Read-Only TopicFocal Point Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point IBIC_pass Exposes Mainframe Password
Focal Point Forums WebFOCUS/FOCUS Forum on Focal Point IBIC_pass Exposes Mainframe PasswordCopyright © 1996-2020 Information Builders
| View $GS_USERNAME's Public Profile |
| Add $GS_USERNAME to my Ignore List |
| View Recent Posts by $GS_USERNAME |
| Notify me of New Posts by $GS_USERNAME |