I am trying to install a PHP Java Bridge as per the instructions on http://php-java-bridge.sourceforge.net/pjb/index.php on Windows 7
I have PHP working fine on via IIS installed at c:\php
I copied the JavaBridge.war to c:\php which proved to get a good result from the test (running from c:\php)
java -classpath JavaBridge.war TestInstallation
I installed Tomcat 7 and copied the JavaBridge.war to webapps, which the service extract automatically and I am able to get the expected result from
http://localhost:8080/JavaBridge/
All Ok Great!
However when I do the same with the JavaBrigdeTemplate621.war, the browser
http://localhost:8080/JavaBridgeTemplate621/
returns an error
HTTP Status 500 - php.java.bridge.http.FCGIConnectException: Could not connect to server
I have not included the whole page as its very verbose, but the last root cause entry is
root cause
java.io.IOException: PHP not found. Please install php-cgi. PHP test command was: [php-cgi, -v]
php.java.bridge.Util$Process.start(Util.java:1145)
php.java.servlet.fastcgi.FCGIProcess.start(FCGIProcess.java:68)
php.java.bridge.http.NPChannelFactory.doBind(NPChannelFactory.java:94)
php.java.bridge.http.FCGIConnectionFactory.runFcgi(FCGIConnectionFactory.java:88)
php.java.bridge.http.FCGIConnectionFactory$1.run(FCGIConnectionFactory.java:109)
I've tried restarting IIS as well as Tomcat several times
What am I missing (It's Hot and it's Friday ....)
I notice that
\webapps\JavaBridgeTemplate621\WEB-INF\cgi\x86-windows
has a text file called php-cgi.exe.MISSING.README.txt
where as
\webapps\JavaBridge\WEB-INF\cgi\x86-windows
has php-cgi.exe, php5ts.dll and php.ini
Is there another manual step required to get those in there not documented in the instructions?
Not reading the instructions clearly enough. I missed that you should copy the automatically created folder (from war) into the IIS web apps folder. I was trying use Tomcat as the HTTP server instead of IIS. Once I copied them to IIS and accessed via default port 80 (not 8080) it worked fine.
Hope my conversation with myself is of benefit to someone else
Related
I am trying to understand/reproduce Log4shell vulnerability, using this poc and also information from Marshalsec.
To do that, I've downloaded Ghidra v10.0.4, which is said (on Ghidra download page) to be vulnerable to log4shell. Installed it on an ubuntu VM, along with java 1.8 (as stated in POC), and loaded the Poc + marshalsec snapshot.
Tried to start Ghidra, it said java 11 was needed, so although I've installed java 1.8 I still downloaded java 11 and, when you start ghidra, it says the installed version is not good enough and ask for the path to a java11 version; so I just gave him path to the jdk11 directory and it seems happy with it. Ghidra starts alright.
Then set up my listener and launched the poc, got the payload string to copy/paste in ghidra, and got a response in the ldap listener saying it'll send it to HTTP. But nothing more. The end.
Since the HTTP server is set up by the same POC, I thought maybe I just couldn't see the redirection, so I started the http server myself, started the ldap server myself with marshalsec, and retried (see pics below for exact commands/outputs).
Setting http server:
Set listener:
Setting LDAP server:
Send payload string in Ghidra (in the help/search part, as shown in kozmer POC); immediately got an answer:
I still receive a response on the LDAP listener (two, in fact, which seems weird), but nothing on the HTTP. The the Exploit class is never loaded in ghidra (it directly sends me a pop-up saying search not found, I think it is supposed to wait for the server answer to do that?), and I get nothing back in my listener.
Note that I don't really understand this Marshalsec/LDAP thing so I'm not sure what's happening here. If anyone have time to explain it will be nice. I've read lot of stuff about the vuln but it rarely goes deeply into details (most is like: the payload string send a request to LDAP server, which redirect to HTTP server, which will upload the Exploit class on the vulnerable app and gives you a shell).
Note: I've checked, the http server is up and accessible, the Exploit.class file is here and can be downloaded.
Solved it.
Turned out for log4shell to work you need a vulnerable app and a vulnerable version of Java; which I thought I had, but nope. I had Java 11.0.15, and needed Java 11 (Ghidra need Java 11 minimum, only vulnerable version of Java 11 is the first one).
Downloaded and installed Java 11, POC working perfectly.
I have an working installation of Graylog 2.1 on Debian 8, but I had to install Graylog on CentOS 7 because my datacenter uses this distribution and I want to have same environment to avoid problems when I need to ask changes in production.
I follow guideline of Graylog for CentOS 7 available in http://docs.graylog.org/en/2.1/pages/installation/os/centos.html and installed Graylog 2.1.2. MongoDB, ElasticSearch e Graylog are running and answer to local requests via terminal. However, web interface is not available. Login page is presented, but when I try to connect using admin user, I receive this answer:
Error - the server returned: 404 - cannot POST http://mydomain:9000/api/system/sessions (404)
Below are lines that I changed into server.conf of Graylog (I replaced real IP address here):
rest_listen_url = http://4.8.15.16:9000/api/
rest_transport_uri = http://4.8.15.16:9000
web_listen_uri = http://4.8.15.16:9000/
I have searched for references about this fail and created a graylog-settings.json file based on suggestion of Graylog github issues, with this content:
"custom_attributes": {
"graylog-server": {
"rest_transport_url": false
}
}
But event after restarting server, the problem continues. Graylog log only shows INFO records, then it seems to me that requests are not reaching server. I would like to know if this is due to network configuration or can be solved by an adjustment of Graylog.
Your rest_transport_uri looks odd in comparison with rest_listen_uri. Make sure that you actually need to set rest_transport_uri at all and that it is the correct setting.
I don't know where you found information about graylog-settings.json, but that file is only being used in the official Omnibus package (i. e. the OVA and AMIs).
I am using apache Archiva v. 2.2.0 under Windows Server 2012 R2, Java version 1.8.0_60 inside VirtualBox. It used to work for quite a long time before Windows autoupdate.
After Windows autoupdate I am getting an error message when going to archiva url: HTTP ERROR: 503 . Problem accessing /. Reason: Service Unavailable, Powered by Jetty://.
The Apache Archiva service is running. No error logs are generated. Restarting or even reinstalling of the service has no impact.
After rolling back of Windows update I restore the normal operation of Archiva, but mysteriously, just once, i.e. stopping and restarting of Archiva will cause the same HTTP ERROR 503.
The log file do not indicate any problem or error cuase.
Thank you for any tips.
I faced a similar issue.
I restarted archiva using ./path/to/archiva/apache-archiva-2.2.0/bin/archiva console
for you, since you are using windows .\bin\archiva.bat console
In my case I've found out that the jetty configuration file jetty.xml in ARCHIVA_BASE\conf got corrupted.
Solution:
Stop archiva service
Replace jetty.xml with either a fresh one or from last known working
backup. A fresh copy of jetty.xml can be downloaded from archiva web
site as an apache-archiva-2.2.0-bin.zip. File location within the
zip file is apache-archiva-2.2.1\conf\jetty.xml
Start archiva service
For me it was complaining about ClassDefNotFound errors, this was because I didn't set my JAVA_HOME properly (on Mac OS). After fixing this, the program worked. Maybe that was your issue.
I created this simple dynamic web project (glassfish 4.1.1 latest atm) using eclipse java ee Mars.2 that I installed 2 days ago.
Checking on the admin, the app is deployed and running fine. I could not access the web app using the localhost:8080 url but it works when I use <computername>:8080.
I could access the admin using localhost:4848.
I tried disabling the firewall but the problem persists. What could be the problem?
The error is:
404 Not Found
No context found for request
In eclipse I see the log int he console that says: Automatic timeout occurred
As I pointed out in comments, you can configure listeners in Configuration -> needed configuration -> Network Config -> Network Listeners. However, it is still rather strange that your localhost doesn't work with 0.0.0.0 IP address, since it is a special address which means "listen on all available IPs on given port". Perhaps your network is somehow misconfigured.
As a newbie to Enterprise Applications I'm trying to get it done.
I developed an Enterprise application in Netbeans 7.1.2. It runs successfully using the default Glassfish server. With the need to change the server, I downloaded and installed Tomee+ server, and made some changes to make Tomee Manager Interface work on my system.
I deployed the .ear file (Glassfish server output) into Tomee+ by placing it in the Tomee webapps folder, with the server in the running state. It gets automatically deployed and appears in the Tomcat Web Application Manager interface.
Then, by providing the suitable path in the address bar, like http://localhost:8080/app-war/faces/app.xhtml, it provides the frontend screen but the backend process is not working if I click the submit button. Instead, it simply provides a status page, like HTTP Status 500 - javax.el.ELException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization.
My question is: what went wrong with the steps I took for deploying it in Tomee+ server?
no more verbose stack?
btw can you try to:
1) check you have in tomee.xml the line
2) put your ear in /apps/ instead of webapps/
The point is by default (can be configured with the snapshot/next release) tomee extracts the ear in a folder simply removing the extension (webapps/your-ear/ for instance) and then tomcat takes this folder as a webapp so your deployment is no more the one expected. That's why moving it over a folder not managed by tomcat (apps) is often enough.
That's said, Glassfish transaction management is sometimes too tolerant (why i ask the full stack you got).