My production server recently got a slew of access probes (to try and find a point to break in, to URI's like to /admin.php, /administrator, /wp-login.php, etc.), and I noticed that some of the REMOTE_ADDR's reported by Apache (IP4's) had two dots where there should be one.
What's up with this? Is this some way for servers to hide?
For one, it means that I need to log these to a wider field than expected. Expected would be xxx.xxx.xxx.xxx or 15 characters, but this might make it 16 or even 19.
[Edit: or better yet 50, see this]
The problem is happening in some code somewhere in your application (etc) that is doing formatting.
IP addresses are actually an array of 4 unsigned bytes. They are conventionally represented character-wise (for human consumption) in "ddd.ddd.ddd.ddd" form, but that is not the fundamental representation. The fundamental representation does not have dots in it at all.
It therefore follows that the extra dots you are seeing are some problem with either the way the IP addresses are converted to strings, or the resulting strings are incorporated into messages, or those messages are handled and ultimately displayed. The extra dots do not "mean" anything ... except ... possibly ... to say that some characters have been left out.
Without more information, we can't tell you where those dots come from, or how to stop them.
What's up with this? Is this some way for servers to hide?
Nope.
At the point that your systems first see those IP addresses, they are in 4-byte form, just like other IP addresses. The dots are not a new way to hide. Rather they are just a result of a local problem in the way things are being logged.
UPDATE
Looking at the evidence in your "half answer", one possibility is that you have some progress monitoring or debugging code somewhere that occasionally outputs a "dot" into the output stream. It looks like it would be on a different thread ...
So far my hosting company says only that I can clean up these values.
They are right. But you probably want to find where your application is injecting the garbage and fix that ... rather than massaging the log files.
What are you doing with that variable in your code? I expect it's being translated or parsed in some way that's adding the extra period.
It's extremely unlikely that Apache would report it that way, as that would be invalid as an IPv4 address.
Compare your output with the web server's access logs, which will have recorded the remote IP as Apache saw it.
Half of the answer is that php's $_SERVER['REMOTE_ADDR'] is untrusted because it comes directly from the http request as provided by the server to php it can apparently and from other reports be spoofed.
EDIT2: I have more recently found two more bad variables from $_SERVER with double dots, as follows:
SERVER_ADDR REMOTE_ADDR REQUEST_TIME_FLOAT
184..154.227.128 183.60.244.30 1391788916.198
184.154..227.128 183.60.244.37 1391788913.537
184.154..227.128 183.60.244.37 1391788914.368
184.154..227.128 184.154.227.128 1391086482.1889
184.154.227.128 183..60.244.30 1391788914.1494
184.154.227.128 183..60.244.37 1391788913.0523
184.154.227.128 183.60..244.37 1391788911.5938
184.154.227.128 183.60..244.37 1391788914.3977
184.154.227.128 183.60.244.37 1391788911..9855
So far my hosting company says only that I can clean up these values. That is easy, but cleaning up garbage is still garbage. If dots can and are being added, then the numbers can and possibly are be changed too I think. Humm?
See: this comment from the php manual.
Now that leaves the question where to find a trusted IP from the accessing client? Apache has it I'm guessing from the incoming http packet exchange with the client. (I'll ask this Q: in StackOverflow).
Related
I am wondering how, on a technical level, IPv4s and domains can be distinguished.
An IPv4 takes the form [0-255].[0-255].[0-255].[0-255].
A domain takes the form (a)+.b, where (a)+ denotes that this string occurs at least once and may repeat.
The values of a can be considered arbitrary alphanumericals (so yeah, mathematically, I am not super correct with the expression above), as can the values of b, though b has practically more restrictions because it must usually be registerd Top Level Domain (TLD), but apart from that, may be arbitrary alphanumericals, either.
In theory, the set of ip addresses looks like a subset of the set of domain addresses.
Edge cases like special characters and special addresses are not relevant for this question and can be ignored.
When I enter an IP or domain into my browser address field, the terminal, or an application, how does the system know whether I entered a domain that requires resolution, or an IP address that can be directly contacted?
Can someone, on a technical level, explain how the system handles these strings and what possible interactions can occur and whether (and why) this raises security issues, or not?
I was wondering, whether an attacker would be able to exploit this ambiguity and whether there are cases where exactly this already happened in the past.
I am wanting to block every country EXCEPT USA,Mexico, and Canada from my ecommerce site. From the research I have done, using an HTTPModule would appear to be the best method. However, this would require me going through a list of hundreds of ip ranges and woudl require quite a bit of code
Anyone have nay ideas on a quick way to do this?
Even if you did block IP address range this would change as the get reallocated or taken up. Also its possible to use a number of services to spoof IP addresses or even to go out through routers / gateways in other countries even if you're not in the places you want.
You could try looking at the locale and / or time-zones set on the client machines. whilst this is not infallible and can be worked around (if the client knows what you're doing to block them),
They are en-us, en-ca, fr-ca, es-MX, it's the letters after the dash that you want, which are the ISO 3166 Codes for Countries. This may give you a start, it's not a infallible, but you're not going to get that anyway, but its a very light weight way of removing a fair amount of visitors.
IMHO, the best approach: application and/or network firewall (appliance) rules (having said that, if you have one, this may even negate the need to do IP address filtering entirely)
IIS
I am currently implementing an EDI solution in BizTalk Server 2010.
This is the scenario:
BizTalk is responsible for the correct message routing between a X.400 mailbox and the customer's ERP software. It is also used to put information about the exchanged message into a SharePoint site using the SharePoint webservices.
I am using Role Links and the BizTalk party management to apply the correct settings (send ports, password in UNB6 segment, etc.).
Now I have the following question:
When I try to fetch an outgoing INVOIC message from the customer's ERP system, extract the relevant information in an orchestration and write it into the SharePoint site, the receive port using the EDI receive pipeline gets suspended with the following error message:
An output message of the component "EDI disassembler" in receive pipeline
"**********.Pipelines.FileNamePromotionEDIReceivePipeline, **********.Pipelines,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=****************" is suspended
due to the following error:
Error: 1 (Miscellaneous error)
33: Invalid occurence outside message, package or group.
The sequence number of the suspended message is 1.
This happens because the message uses a CR and LF as suffix after each segment delimiter. Now I could add the ASCII-hex-codes for CR and LF to the "EfactDelimiters" setting of the pipeline, but the problem is that there are other messages without the CR and LF, which then could not be received using the same pipeline. By the way, when I fetch one of those messages without CR and LF using the pipeline also without CR and LF set as delimiters, the receive port also gets suspended, this time with an error message resulting from the usage of dots instead of commas as decimal separator (although I have enabled the option "UseDotAsDecimalSeparator" in the pipeline). Again, only changing the EfactDelimiters helps.
I thought that the "Character set and separators" page in the party agreement was supposed to make exactly that possible: To set the delimiters individually for each business party. But the changes I make in these settings seem to have no effect whatsoever. I set the "UNA6 Suffix" to "CR LF" and the "Decimal Notation (UNA3)" to ".(Decimal)", restart the host instance... same problem.
Can anyone help?
I never used biztalk, but I know my EDIFACT, and as far as I know, those messages containing CR/LF are syntactically wrong. The UNA6 Suffix seems to be an addition by Microsoft, as I can find no trace of it in the official documents on EDIFACT at UNECE.
Normally, the chars you want to use as special chars in an EDIFACT message are set by the special (optinal) UNA segment, which always comes first. When you write, you set the separators / delimiters, I don't really know, what you mean by that, as it could refer either to setting the options for the created message (what delimiters are used in the message), setting the delimiters used for parsing by the receiving program, or it could refer to the chars that are printed in the UNA segment.
Know, in the UNA segment, there is no way that I know of, to indicate the use of any UNA6 suffix (as stated quite explicitly in the documents, the UNA segment has to be exactly 9 characters of length, see 8.3 Interchange formatting rules). That leads me to the conclusion, that you set the options for the created messages. I would not advise to use a UNA6 suffix, if you can avoid it. It might be nice for humans to read the message, but it does not belong there and is not useful for the machine to read.
If the receiving program has no option to allow optional occurrence of CR/LF, and you can not avoid a mix of those to kind of messages, I see no other way for you other than somehow insert a small program that gets rid of the CR/LF.
The most important principle is of course, to make the sending and the receiving program talk in the same syntax, otherwise it can't work. The same thing goes for the problem with the decimal separator. As of Syntax rules, 10.1, either the comma or the dot is allowed, which is a quite loose definition. If you want to be on the save side, send an UNA segment, specifying which one you use, and then only use that one.
I'm not really sure, how much this helps you with the specific problem, as it might be a thing that's only a question on how to configure biztalk, but I thing some background information should be useful.
I currently perform penetration testing of ASP.NET application and trying to exploit Padding Oracle Attack. This AFAIK is based on response code analysis, but both ScriptResource and WebResource axds of the system under test always respond with 200 OK, even if cipher has been invalid. In this case, however, the content of the response is an empty string.
Is it possible to use any of the axd as the oracle in this case? Maybe basing on response content difference.
The Padding Oracle Attack works by being able to distinguish between two cases:
The server failed to decrypt the data because, upon decryption, it did not found a properly formatted padding.
The server found a correct padding, but the decrypted data turned out to be random junk.
There may be several ways for an attacker to get such a distinction. A specific error code from the server is just the easiest to exploit; but any detectable difference is enough. The attack was first published in 2002 (yes, it took 8 years for people to notice that it could be applied to ASP !) and it has been demonstrated on a SSL connection with only a timing difference: the server was decrypting the data, and then was verifying the MAC only if the decryption went fine; the extra 2ms taken by the MAC computation were enough for the attacker to know whether the padding was valid, allowing for direct application of the Padding Oracle Attack.
To answer your original question, the content length can be used. Padbuster notes the status code but I think it detects entirely off the response length.
To answer your reply to Troy, a long ciphertext length does not indicate they are vulnerable. Typically a short ciphertext length does indicate they are vulnerable, but you need to dot net url decode the value then see if modulus 8=0 to see if it's vulnerable. In other words, the length will be a multiple of 8. Usually i'll see one block of ciphertext (16 bytes) end up about 25 bytes once it's dot net url encoded. The fix includes a HMAC (I think), which extends the length and should make one block cipertexts impossible. I can't say this with certainty, as I'm not sure how long the HMAC is and if it works after padding or not.
It sounds to me like the padding oracle patch may have been installed and as a result you're not getting the error codes you were expecting. Have a look at Do you trust your hosting provider and have they really installed the padding oracle patch and see if you can establish this.
I'm wondering how the browser, and/or DNS, handles a user entering an invalid character in a domain name.
Let's say that I own meat&potatoes, a well-known chain of fine dining restaurants. All of our marketing refers to us as meat&potatoes (meat + ampersand + potatoes, no spaces), and it's likely that fairly often, people are typing www.meat&potatoes.com into their browser.
How does the browser, and/or their ISP's DNS, handle this request? Are there any ways I can get the user to the correct domain without requiring them to make additional clicks / keystrokes?
Edit: In my limited testing, I've found that Chrome transforms the character into a URL-encoded version (e.g. %26 for &), and then sends a request somewhere that results in my ISP(RCN) giving me a search results page (because RCN is evil like that): www17.searchresults.rcn.com/… So, something is reaching the ISP.
Host names are limited (RFC1034 section 3.5) to letters (a-z), numbers (0-9) and hyphen (-).
Additionally, international characters are allowed by recent browsers using puny-encoding (RFC3492) - which basically applies to character values above 127.
I don't know specifically how browsers handle this, but I expect that they go by these two sets of rules, and gives the end-user an error/redirect for anything else.
And therefore it never gets as far as DNS / ISPs.
Unfortunately this means that there is currently no way to make "&" in a domain name work...