After the upgrade of weblogic to newer version I started facing an error with different application conectivity.
RequestDumpingFilter Response; Content=<?xml version="1.0" encoding="UTF-8" standalone="yes"?><StatusBadGateway xmlns="http://types.xxx"><BackendSystem>Infomatica</BackendSystem><BackendServiceCall>getUsage</BackendServiceCall><ErrorMessage>RuntimeException when calling getUsage. javax.xml.ws.WebServiceException: Old format work area header is disabled.</ErrorMessage></StatusBadGateway>
Does anyone knows the solution? How to fix this?
Issue is caused due to old headers in use even after upgrade, no common soap header format is in use. See below.
APPLIES TO:
Oracle WebLogic Server - Version 12.2.1.0.0 and later
Information in this document applies to any platform.
SYMPTOMS
WebLogic has recently been upgraded to WebLogic 12.2.1.2 from 9.2. Post upgrade, the webservice request is not working with
below header format exception.
Jun 12, 2017 7:04:03 AM CDT> - [Error in invoking service : java.rmi.RemoteException:
SOAPFaultException - FaultCode [{http://schemas.xmlsoap.org/soap/envelope/}Server] FaultString [Old
format work area header is disabled.
] FaultActor [null] Detail [javax.xml.rpc.JAXRPCException: Old format work area header is disabled.
]; nested exception is:
weblogic.wsee.jaxrpc.soapfault.WLSOAPFaultException: Old format work area header is disabled.
SOLUTION
Make sure common same SOAP header format is in use between webservice communications, else disable the work area header
validation using the flag below:
-Dweblogic.wsee.workarea.skipWorkAreaHeader=true
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'm having a weird issue with Apache CXF and large (375MB) MTOM attachments are empty.
Running it locally in Eclipse produces the desired results, but deploying it to our server just gives an empty attachment.
The server is written in .NET and doesn't support chunking. With Chunking enabled the client works, but when i disable cunking it fails.
Sadly i'm unable to debug on the server, so i'm restricted to trace logging.
I've tried every trick i've been able to google.
Disable schema validation (CXF-4551) (CXF-7758)
Manually copying the file to java.io.tmpdir before sending, to ensure it can be read.
Custom DataSource
Disable WS-Security
Disable logging interceptor
Nothing seems to make a difference.
Every run i just get something like the following
</soap:Body></soap:Envelope>
--uuid:40ef745b-ac3c-4013-bbe7-a9cc28880423
Content-Type: application/xml
Content-Transfer-Encoding: binary
Content-ID: <7611ca0a-22f8-4637-b4f7-a5dfe7f20b81-3#www.somewhere.dk>
Content-Disposition: attachment;name="32_2018-03-28_output.xml"
--uuid:40ef745b-ac3c-4013-bbe7-a9cc28880423
Trying with a smaller (2KB) file on the server works just fine. A 75MB file gets attached correctly, but results in a HTTP 400 from the receiver (which i suspect is because the file is not fully transferred)
Does anyone have any ideas as to what might be causing this ?
After much trial & error, i finally managed to "solve" this. I enabled schema validation, and the data now appears. This is the exact issue that both bugs in my original question claims to fix.
Client client = ClientProxy.getClient(port);
BindingProvider bp = ((BindingProvider) port);
bp.getRequestContext().put("schema-validation-enabled", "true");
I can't add a comment so I'm posting this as an answer.
Jimmy could you perhaps comment on the latest CXF issue and provide some more details? Which version of CXF, what kind of client you are using, real code samples ideally, client logs?
I am using openshift origin and JBoss developer studio 9
When i am trying to create new application using oc new-app in open shift command it working well but when i tried to create any project with jboss studio it give me the following error
"the body of the request was in an unknown format - accepted media types include: application/json, application/yaml
Could not create resource res in namespace '': {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"the body of the request was in an unknown format - accepted media types include: application/json, application/yaml","reason":"UnsupportedMediaType","code":415}"
Please note that this error occurred also when i tried to deploy an image from openshift and i am using all in one openshift origin vm
Any help highly appreciated.
You may need to update your release of developer studio which relies upon the openshift-restclient-java. https://github.com/openshift/openshift-restclient-java/pull/112 resolved an issue where the content-type was not being set.
I have a WCF service to consume in .NET. As per requirement the Action element in the header has to be "http://abc" and the To element has to be "ws://xyz" in order for the service to recognize and respond to the request. The soapAction of the operation is however blank in WSDL and it can't be changed.
My service configuration built programmatically is this:
text message encoding binding with Soap11 envelope version and WSAddressing10 addressing version
no security biding
http transport binding
The setup I found achieving this requirement is "ws://xyz" as the endpoint URL and Request.Headers.Action set to "http://abc" in BeforeSendRequest using a message inspector added using an endpoint behaviour attached to the endpoint. Then I also attach a ClientViaBehavior with the URL of "http://abc".
On my development machine this causes as required
<a:Action>http://abc</a:Action>
<a:To>ws://xyz</a:To>
However on the test server it generates
<a:Action>http://abc</a:Action>
<a:To>http://xyz</a:To>
I don't know exact configuration of the server but I believe it is Windows server as is my development box. Does the same code generates different messages on two different machines or how else would I achieve this? I should also say it worked fine for several weeks and stopped last Monday.
I have found the following later:
The test server has .NET 4.5 on it as well as another machine I tried it on (also failed). The dev machine where it works fine has just .NET 4.0 on it which would suggest it could have something to do with it. However I have no evidence it is caused by .NET 4.5 as it was installed several weeks before the problem appeared. Moreover there have been no Windows updates since it stopped to work!
I've also tried to set the To element in my ClientMessageInspector implementation but the protocol still gets flipped to http.
I think the BeforeSendRequest is not called due miss configration of your service bindings. Check if you have added the the extention configuration to you service endpoints you want to have the behavior.
My code is consistently generating the following error:
org.apache.axis2.AxisFault: Timeout waiting for connection
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:203)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:76)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:400)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:225)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:435)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:402)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
After extensive searching the solution appears to be here:
http://amilachinthaka.blogspot.com/2009/05/improving-axis2-client-http-transport.html
Except I cannot access http client directly (that is done in auto generated code).
Instead I have tried:
http://wiki.apache.org/ws/FrontPage/Axis/AxisCommonsHTTP
Which seems to help slightly. However it only delays the problem I always get the timeout. Also the instructions appear to be for an old version of Axis since Axis2 does not have AxisProperties. I am using version 1.5.1. Any suggestions?
I think this was a bug, see here and has been fixed with Axis2 1.5.2 (at least for generated code). With custom code, you need to tackle this problem manually.