Why doesn't DNS spoofing work against HTTPS sites? How does using SSL protect aginst dns spoof? since DNS is at a lower level and it is always work the same whether the user is visiting an HTTP or HTTPS site.

Assume you managed to poison the DNS cache for securesite.com with an IP that you control. Now, when the client visits https://securesite.com, it will resolve to your IP address. As part of the SSL handshake process, your server will need to send a valid certificate for securesite.com which contains the public key.

At this point, you have 2 options.

1) Send the legitimate certificate. This will check out since the certificate is signed by a trusted CA. The client will then encrypt the master secret using the public key. It breaks down at this point, because without the private key, you cannot decrypt the master secret and thus you can't finish the connection setup.

2) Send a self signed certificate. However, since it is not signed by a trusted CA, a warning will show on the client's browser. If the client choose to proceed anyway, then you have successfully carried out the attack.

DNS spoofing will generally not work on HTTPS websites unless the client chooses to ignore the warning signs or if you manage to obtain the private key for the site.


How to exactly create a CVE? I found an heap overflow exploit for a vulnerability in git servers. This lead to lucrative operations on various bug bounty programs (GitHub already promised to put me in their top 10).
When it was corrected recently, the case of remote code execution wasn’t identified.
As result, many Linux distributions as well as mainline commercial products like Apple osx still ship affected versions.
So, I think it’s time to make a great publicity around the vulnerability and that a CVE shared across all can would be the best way to achieve this.
This would just take age if I need to contact them all.
Update :
For those seeking about the details, just wait my profile to appear on the main page of this site. I also won’t attempt anything as long as the issue isn’t fixed with the vendor.

As Ohnana also mentioned the way to request a formal CVE is through their intake form.

https://cve.mitre.org/cve/request_id.html

Details from a current snapshot of that website

Main Methods
Contact one of the officially recognized CVE Numbering Authorities (CNAs), which will then include a CVE Identifier number in its initial public announcement about your new vulnerability.

Or, contact an emergency response team such as CERT/CC, etc., post the information to mailing lists such as Bugtraq, or provide the information to a vulnerability analysis team.

Alternative Method
If you are unable to obtain a CVE Identifier number via the main methods above, you may request a CVE Identifier number directly from the CVE project. To reserve a CVE Identifier number before publicizing a new vulnerability, vulnerability researchers may contact cve-assign@mitre.org and we will provide you with our "CVE-ID Reservation Guidelines for Researchers" document. We will then work with you to assign a CVE Identifier number for the issue while you work through the process of publicly disclosing the vulnerability.

Please review the Researcher Responsibilities.
https://cve.mitre.org/cve/cna.html#researcher_responsibilities

Adding a link to the CVE FAQ.
https://cve.mitre.org/about/faqs.html


Do we need to include SIEM hosted in the cloud in CDE scope for PCI DSS requirement..? where no CD or transacation logs are being process or managed We have our cardholder data environment (CDE) hosted in on-premise model (private datacenter), except SIEM solution is implemented for logging and monitoring in private cloud. where we are forwarding only security logs and not forwarding any logs relating to cardholder data / transaction logs. do we still need to include the cloud hosted SIEM solution in CDE scope for PCI DSS requirement..?

The cardholder data environment (CDE) is limited to the network segments storing, processing, transmitting cardholder data. Your in-scope system components are beyond this CDE as systems providing security or other services are in scope for validation - i.e. authentication, update/patch management, orchestration, anti-virus, logging, FIM.

So this means your SIEM solution needs to be validated. The system should do at least the following:

Capture the appropriate logs
Logs should be reviewed daily
The system should generate alerts
File Integrity Monitoring should be in place to protect the integrity of the logs
Log rotation/retention policies should be in place and enforced
Users of the system should be managed and monitored appropriately
The system should be maintained up to date

Either you or the cloud service provider must evidence all the above or your cloud service provider can provide evidence to show the above has already been validated - i.e. by providing an Attestation of Compliance for the scope of the service provided.


OpenID Connect: API access using same identity provider Does OpenID Connect support the following SSO-like scheme:

Both website S and some meta-website M support login using OpenID Connect, e.g. with a Google account. Is it possible for M to access a user's data at S, with the user being authenticated for both services with the same 3rd party account (e.g. Google)? So M should be able to make authenticated requests to the API of the website S, with the identity of a user logged in with e.g. his Google account.
If yes, how would the workflow look like? (interactions between the involved parties, tokens to be obtained, ...) If not, are there other technologies which should be used for this case?

What I found so far, was to how to let a user authenticate at M using his/her account at S, but not using the account at another, 3rd organization.

NO

because the Session_State value(which is used to manage the session) is initially calculated on the Google's server. It is calculated by a salted cryptographic hash of Client ID, origin URL, and OP browser state. Since the Origin URL will be different between M and S, the same Session cannot be shared between M and S.

OpenID Connect Documentation here


Would it be a big security vulnerability if someone wrote a browser extension to retrieve personal information on Google's behalf? I am a 6th grader working in a project and came across the following question:

On most browsers, you can inject JavaScript code into the browser, for example by typing in javascript:alert('Injecting javascript code'). On Google Chrome, if you do this on Google Drive, instead of the title being "drive.google.com says", the title is "Google Drive". Would this be a security threat in any way if someone wrote a malicious extension to ask for personal information on Google's behalf?

It would be a security vulnerability, yes.

Executing javascript code in the context of a web page allows that code more or less full access to the content of the page, in this case Google Drive. Such code could leak content, and ask for information such as passwords.

This is generally referred to as Cross site scripting or XSS in shorthand.

The specific case of making the user enter the code is called Self XSS. Sites such as facebook warn against it if you bring up the console by pressing F12 in chrome:


Can a telephone caller be authenticated? If we assume that the human element is unable or not skilled enough to discover a phishing attempt (or some other malicious endeavor that can be perpetrated verbally), what forms of defense can be deployed to aid in the authentication of a telephone call?

Specific example - if a telephone call is coming from a spoofed number:

Can it be detected?
Can it be prevented?

Primarily interested in the userland (or the equivalent enterprise) context, meaning "below" the provider. Although any musings or explanations that involves or references the provider would certainly be interesting, even if not directly useful.

Media where I live enjoys claiming you can't "defend" against these types of attacks/spoofs using strictly technical means -- are they right?

In the plain old telephone system (and also avionic communication systems) authentication is built into the communication.

Key exchange is also done previously by meeting people. (In case of avionics by meeting pilots and the command center operators).

Authentication itself is done by human ear by recognizing the human voice.

(I am pretty serious. You cannot encrypt safety-critical hardware in avionics. A malfunction may happen in the air. The "safest" way is not to encrypt at all.)


Is using a website copier considered active reconnaissance in penetration testing? New to PT and would like to test recon skills.

First, is this considered passive or active recon? Second, would I be jumping into a legal gray area if I used a tool like this on a buiness' website? I'd like to practice but am having trouble determining this.

Generally speaking anything which sends traffic directly to a company's site is considered active rather than passive.

Now most organisations will realise that traffic to a public facing site is fine and not an attack (as long as it's not excessive enough to cause a Denial of Service) but it is a legal grey area as, for example, a spider could hit content that the company considers non-public and that could cause a response from them.

I'd recommend that while you're practicing you stick to one of the many test applications that can be downloaded for example the OWASP Broken Web Applications Project


Disturbing Notification I received an E-mail notification a couple of days ago welcoming me for signing onto Stockholm Arlanda Airport's wifi network.  My wife and I have never been to Stockholm.  I asked my neice's husband who is involved with IT about it and he didn't seem too concerned.  Felt someone might have mistakenly entered my E-mail address when signing on.  Figured I should double check in case.  Anything to be concerned over?  Any recommended security precautions?  Thanks in advance!

I agree with the comment; this doesn't sound like an issue to me. If the email legitimately came from Stockholm Arlanda Airport (you can check the email address*) and if the email doesn't ask for any personal information, I wouldn't worry.

I don't like putting my personal email address in captive portals; I don't want be on their email list for something I likely don't care about. I suspect that's what happened here - someone simply typed in your email instead of their own.

*Note, most modern email providers do filter spoofed emails, and the probability that's the case is low.


Is an index, nonce and HMAC good enough for session management? The scope is server-side session management with session payloads being sent to the client in a cookie.

I'm researching session management for web applications. I've been looking at a couple places, and from my understanding is we shouldn't use a secret as a session identifier(index). Because it can lead to timing attacks.

Let's say for the sake of performance sessions on the server-side are stored in cache/memory. And the index is reset(e.g: starts back at 1) every time the server restarts or they are all purged.

session_payload = index || HMAC(server_key, index)

But doing it like that would leave room for replay attacks, right? An attacker could generate a bunch of session payloads and store them for later to hijack sessions. Something is needed to make each session payload unique to prevent that, right?

So what about:

payload = index || nonce
session_payload = payload || HMAC(server_key, payload)

If my understanding is correct, the nonce just needs to be unique to make the session payload unique. Should it be just the output of a CSPRNG, RNG or the current time(milliseconds?, nanoseconds?)? What are the caveats of each?

So if the above is done right, it should be able to avoid:

Timing attacks.
Volume attacks.
Replay attacks.*
Tampering.

Right? And is there any other attacks I should be aware of? Please exclude session fixation, that can be mitigated via session payload regeneration on privilege escalation.

What I define by a replay attack, is adversaries could store pre-computed session payloads and hijack sessions later, hence the use of the nonce.

If you're storing session identifier tokens server-side, tokens from a cryptographically secure PRNG work fine, assuming you use constant-time checks (either through evaluating the full length every time or via hashing before comparison). If you want to make the lookup into your session collection faster, and you're willing to trade away revealing some info about the number of active sessions in exchange for the performance improvement of using an array lookup instead of either a hashtable or a binary search, you can add an index to the random token... but the index's only job is to be a performance optimization.

HMACing the whole token afterward shouldn't be necessary, since there's neither predictable or time-able data to tamper with, so tampering gets you nothing. Replay is eliminated by just using a decently-long token. Adding an HMAC will (marginally) increase server load for no clear value (it might reduce the already-minimal risk of compromise from an attack on something below the application layer, such as CPU caching, but it's also additional complexity and thus avenues for things to go wrong with minimal expected value).

You say this is for research, not implementation, but it's still not obvious why you'd try going this route. It looks like it started with a clearly terrible idea (use an index as a token), a failed attempt to patch that idea (hmac the index... oh wait, replay), and attempted to patch the bad patch. Security is often improved iteratively, but the basis of this whole approach is such a bad idea it's not worth trying to fix.

Assuming the MAC key is kept safe and that the nonce is stored and checked server-side, this does work. Neither the generation nor the checking of the nonce has many specific requirements so long as the tuple (index, nonce) are never reused; you could (if you didn't mind leaking even more info about how many sessions have ever been created) use a simple counter (long enough to prevent wrap-around) for the nonce. Assuming you were really wedded to this index-as-the-primary-identifier-of-session idea but wanted to stop the info leaks, you could even encrypt the token. At that point, though, your system is deeply over-complex, your token much longer than it needs to be, your server doing more computation on every request than there's a need for, and you've gained approximately nothing over a simple secure-random token + constant-time check.


How do banks determine when to ask for two factor authentication? I was playing around with trying to figure out how my bank knows when to give me a two factor authentication prompt. I had originally thought it was based on my cookies and maybe my IP address. But the results have baffled me.

In incognito mode, the bank asks me for a two-factor code every single time. This didn't surprise me because incognito mode doesn't have any cookies, so I would expect it to prompt me.

In normal mode, I went into "Clear browsing data" and cleared away all cookies, cached files, app data, passwords, download history. I cleared EVERYTHING. I browsed to the bank site, logged in and....NO two factor code prompted.

I repeated this many times, with the same results. My guess is they are doing some kind of advanced browser fingerprinting -- something more complicated than cookies.  What do you guys think is going on?

I know several banks use "profiling data" from previous logins in order to try to determine the identity of the user based on:

Credentials (obviously)
Secret question (not all banks use this method though)
IP address (Geo Location + time zone) and internet provider
The device(s) previously used to communicate with the bank:

a. Type of web browser, its cookies, plug-ins & add-ons

b. Screen resolution

c. Browser dimensions
Timestamps range:  Within what range a user generally logs in.

There are more factors than the above list but it is basically a risk engine that determines when two factor authentication should be triggered or not.


Polymorphic/Metamorphic malware is written on low-level or high-level languages? As a part of a course I study polymorphic/metamorphic malware. Every single paper and article I've stumbled upon mentions the techniques used by a malware to achieve polymorphism/metamorphism but non is mentioning the language(s) in which most polymorphic/metamorphic is written on or code examples of that particular technique.

My understanding is that malware can be written using almost any language, from Visual Basic, C and C++ to Java and Python. My question is: In order to achieve polymorphic/metamorphic behavior do you need a low level or a high lever language? Do we know which language most polymorphic/metamorphic malwares use?

Polymorphic/metamorphic is usually at least partially written in a low level language.

The purpose of polymorphic malware is to evade virus scanners.  It does so by making it hard to identify a signature for the file.  The simplest version, of course, is a loader which decrypts a section of code when it is time to run.  However, this has a limitation: the loader is now an easy signature to spot!

The solution is to write the loader in a polymorphic manner itself.  This is a sort of chicken and the egg problem.  However, we know the application EVENTUALLY gets compiled down to machine code, so polymorphic code developers will write machine code which can be mixed and mutated and still work.

This low level work is very hard to do in any language above assembly, because the higher level you go, the more of a signature you'll leave behind (high level languages were never written to avoid leaving signatures).

However, that doesn't mean the entire malware has to be low level.  Once you can make a poylmorphic malware that knows how to decrypt and encrypt code, it becomes possible to write the rest of the virus in a high level language, and just attach it to the low level polymorphic loader/encrypter/decrypter.

(And, of course, this battle will continue if the virus scanner looks at memory after decrypting, but I think just handling this "scan the file for signatures" Virus Scanner approach should get you going!)


Lamp server sandbox for testing malicious php script Fortunately despite recently becoming a full time web developer, security is something I take very seriously. There's a developer that I work with who's system was recently compromised with obfuscated php (Frequently using eval() and base64_decode()). At first glance it looks like the script might fail due to a missing token but would like to evaluate this script myself.

What's the best way to do this? I had thought about using an online php parser, parsing it on my localhost, or setting up a lamp virtual box but need to verify that any one of these methods is safe or legal.

If you simply replace eval() with something like file_put_contents() in each de-obfuscation step you will be able to get the actual malicious code and be able to analyze it. Just make sure you don't output the results to the browser because at some point actual malicious code will be executed in the browser and your machine might get compromised. Write the contents of each step in a plain text file and open them with a plain text editor in each step.


Hash the signing key of an authentication token in database I have clients which are all browsers. All clients render just a single page application getting data from a Web API. The design of the API follows REST principles.

I use token-based authentication without OAuth because I have no third parties for my API and I want to feel how security can hurt my brain ;-)

The format of my token I issue is Json Web Token (JWT): It contains the userId, lifetime (exp date), issuer and signing key (alg: HS256 which is SHA-256 hash algo)

The token is valid 7 days. So the user has to reauthenticate every 7 days. (Maybe thats not yet the final solution in this field...)

This is my authentication flow:

1) I use basic authentication over SSL for my login endpoint

2) If the user`s sent username and password are valid I put a token into the response

3) This token is stored in the local/session storage on client side

4) Each further request to a ressource endpoint of the server API must include a valid token else the request gets a 401 and sees the login view again.

5) Before I do further investigation with the token like checking its expiration date I need to know wether the authenticity of the token is still valid or a legit user has modified it. This assumes that the token was signed with a key before which we call MAC (Message Authentication Code)

I validate the token with the same signing key the token was signed during token creation. I store the signing key which is a bunch of randomly generated numbers in the user sql table belonging to the userId. The userId I get from the token see above. Or better said I store the hash of the key (byte array) in the user sql table hashed with BCrypt.

Question:

Is there something wrong I do?
Should I store the full token in the database instead of the signing key only and whats the advantage?

On your first point, there are some potential downsides and points to using basic authentication over SSL that you might want to consider.

Where you're using basic auth, your token based solution might not really be needed as once a browser has sent the basic auth credentials in the first place they'll send them again with every request to that realm, so you could just check them again and not bother about the token :)
Basic auth sends the user credentials in encoded format over the link, anyone who can see the data in transit can get the creds. Now SSL will of course provide some protection but it still carries a bit of risk, in some scenarios. You might want to look at digest authentication if you persue this authentication scheme
By itself basic auth doesn't include some authentication protections which could leave your application open to attack. For example there's no account lockout, no password quality requirement, no logout functionality, no password change functionality and no protection against the one user having multiple simultaneous logins.


Checking the primality of numbers for use in RSA How can I check the primality of extremely large numbers such as those used in RSA, in Linux?

RSA is guaranteed to use prime numbers. In fact, if the numbers were not primes, RSA key operations would simply not work (with overwhelmingly high probability). However, the OpenSSL command line utility has the ability to check the primality of a number using Miller-Rabin primality testing, the standard test algorithm for checking large primes for use in cryptography:

OpenSSL> prime
No prime specified
options are
-hex           hex
-checks <n>    number of checks
-generate      generate prime
-bits <n>      number of bits
-safe          safe prime
error in prime
OpenSSL> prime -generate -bits 256
315016830147073940139675761214468273143
OpenSSL> prime 315016830147073940139675761214468273143
ECFE08DCA281B26A5EDDE8DF7D2A33F7 is prime
OpenSSL> prime 10000000000000
9184E72A000 is not prime

I believe the default number of checks is 64, but you can increase this to improve accuracy using the -checks option. Each check runs one Miller-Rabin test round which individually has a 75% chance of detecting that a composite number is indeed composite. Specifically, the chance of failing to identify a composite number as such is 4-n, where n is the number of rounds used. With the default of 64 rounds, this is 4-64, or 2-128. To put that into perspective, if you put a composite number through 64 rounds of M-R primality testing, the chance that it is falsely labeled a prime is equivalent to the chance of correctly guessing a 128-bit encryption key on the first attempt.

I explained more about primality testing in OpenSSL in another answer.


Level 3 DNS default response for invalid host names I was recently flummoxed by an issue related to me setting my router's static DNS servers to what I understand to be Level 3 DNS servers, (4.2.2.1, 4.2.2.2, etc.).

For work I use a company VPN. On the VPN are various hosts that I ssh into to perform various work related tasks. Sometimes my VPN client will drop my connection, rarely. When my VPN connection is up the client sets things up so that my computer uses the company DNS server to resolve hosts. When the VPN is down my router acts as my DNS server.

Let's say one of the hosts that I ssh into is called internal.server

Recently my VPN connection went down and I didn't notice. I tried to ssh into internal.server and I got a ssh spoofing error. The key in my ~/.ssh/known_hosts file did not match the key that was presented by internal.server

To make a long story short, I realized that the 4.2.2.1 etc. DNS servers (which get used when my VPN connection is down) resolve just about anything that's not valid to 23.202.231.167.

For example:

$ nslookup blah.blah 4.2.2.1
Server:         4.2.2.1
Address:        4.2.2.1#53

Non-authoritative answer:
Name:   blah.blah
Address: 23.217.138.108
Name:   blah.blah
Address: 23.202.231.167

I have no idea what 23.202.231.167 is, but they're running an ssh server on port 22.

And finally, my actual questions:

Why do the Level 3 DNS servers resolve (literally) blah.blah (and just about any other invalid.domain I can think of) to that IP address? Couldn't the host at 23.202.231.167 be doing all sorts of horrible spoofing things to people that made typos in their host names?

Am I missing something?

You have discovered the evils of DNS hijacking. ISPs and others hosting DNS servers started abusing DNS in this way years ago to direct end users to search pages when they try going to a website that doesn't exist by returning their own IP rather than NXDOMAIN. It gets them a bit of extra advertising revenue, but as you've seen it's particularly annoying for anyone doing anything other than normal web browsing.

  Couldn't the host at 23.202.231.167 be doing all sorts of horrible spoofing things to people that made typos in their host names?

Absolutely. DNSSEC and DNS over TLS help here, but adoption is slow, and these won't fully solve the problem of typos anyway since typosquatters are the "legitimate" owners of their domains.

The best you can do is to configure your router or computer to use a DNS server you trust with DNS over TLS or DNS over HTTPS. Cloudflare (1.1.1.1) is a common choice as they helped kickstart encrypted DNS, and Google (8.8.8.8) and Quad9 (9.9.9.9) are other popular choices.


How is ZixCorp able to provide email encryption without a password? I am trying to understand how/if an email I received is being encrypted.

A financial institution sent me a verifiable email (i.e. not phising) asking me to fill out a pdf form to complete a transaction. The outbound email contained my account information and a completed pdf form in my reply would contain even more personal and banking information.

This email contained the words {secure message} in the subject and instructions to reply specifically to this email to ensure continued security. This message was sent to my gmail account and contained no PGP or S/MIME information. I have never set up any type of prior secure email configuration with this institution.

I replied to the sender expressing my concerns that this did not appear to be a secure means of communication. I was assured that the communication secure and used passwordless encryption provided by ZixCorp.

The company seems to offer 4 email security products:

ZixGateway
ZixAccess
ZixPort
ZixDirect

ZixPort pulls you to a secure portal to retrieve your message while ZixDirect prompts you for a password in your inbox, neither of which happened. The first two are only supposed to be for receivers with Zix email products. ZixGateway is just a public key-store the enforces rules compliance by chosing a best method of delivery including the above two options.

None of these seem to be describing the passwordless direct-to-inbox email my financial institutions claims is encrypted.

Does anyone know what could be going on? Is this type of encryption even possible?

Update 2014-08-05

Per makerofthings7's comment I checked the MX records for gmail.

$ nslookup -q=mx gmail.com
Server:     130.167.128.4
Address:    130.167.128.4#53

Non-authoritative answer:
gmail.com   mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
gmail.com   mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com   mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com   mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com   mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.

Authoritative answers can be found from:
gmail.com   nameserver = ns2.google.com.
gmail.com   nameserver = ns4.google.com.
gmail.com   nameserver = ns3.google.com.
gmail.com   nameserver = ns1.google.com.
ns2.google.com  internet address = 216.239.34.10
ns1.google.com  internet address = 216.239.32.10
ns3.google.com  internet address = 216.239.36.10
ns4.google.com  internet address = 216.239.38.10

There is no listing for zixvpm. Any ideas why this might be?

Two minutes of your time on Google (no fancy search terms, just "zix gmail") would have told you that Google have been doing some work with Zix to bring some features to their Gmail product... thus you can assume they have Zix integrated. ;-)

Reading the product description on the Zix website, you can inferr that both sender and receivers need Zix servers if the messages are to be seamlessly encrypted/decrypted... otherwise the recipient will need to take further steps.

It seems you just happened to be lucky you were using an email provider that has Zix integrated so that you could see the seamless decryption as Zix intended !


What can I do about the Intel Management Engine? I recently read about the Intel ME (Management Engine), which is a special area in new Intel processors that has complete control over the computer. Nobody knows exactly what it contains, and there are many security concerns about it. I learned about it here:
 https://stallman.org/intel.html

What can I do about this? Are there any ways to stop this, or is it hopeless?

Don't use the onboard NIC, which is how ME accesses the Internet.  Instead, use a USB LAN device, or even one plugged into a PCI slot -- ME doesn't know how to use them!


Does public wifi pose a security risk to existing logins? I'm taking a trip soon and want to figure out how safe it is to use public wifi for services. A common piece of security advice I've found about public wifi (example) is don't log into things, because it's easy for others to snoop on what you're doing. More specifically, they say don't type your username/password into a login form and hit the submit button, or access any sensitive data like bank accounts.

But what if I logged into a service on my private home network, never cleared the session and want to continue using the service from public wifi after I leave the house? I'm thinking like Dropbox or Pandora or Netflix. If I don't need to type in my password and hit send, is that safer/safe enough? Would it make a difference if it's going through a browser or a dedicated app?

EDIT:
While I appreciate the answers so far they seem geared towards real computers and I want to clarify I'm thinking about my Android phone. Thus my question about apps, because I have no idea how to tell if an app is using HTTPS or what.

If the site you are visiting uses HTTPS for the entire site (not just the login page) and you check that it actually is using HTTPS, with a valid certificate (e.g., no warnings about a bad certificate) and it is the URL you want to go to, then you are safe.

(Except against extremely strong adversaries like governments who have the ability to coerce Certificate Authorities into signing fraudulent certificates or giving them the ability to sign them.  But at this point, these strong adversaries can do these malicious changes at the ISP level, so you are screwed either way).

If the site isn't using HTTPS, any data you send or receive may be eavesdropped or easily changed by an attacker.

You should also be extremely careful about downloading and installing anything that didn't come over HTTPS when on public wifi (though you probably should be cautious about this regardless).  E.g., if you install a browser plugin or command-line instructions that came over regular HTTP, it would be possible for an attacker to modify the plugin (to for example run on all webpages and send every form submission to some random domain it controls to steal your passwords / credit card info / etc).

  EDIT: While I appreciate the answers so far they seem geared towards real computers and I want to clarify I'm thinking about my Android phone. Thus my question about apps, because I have no idea how to tell if an app is using HTTPS or what.

You could try using a network packet catcher (like wireshark) to see if the apps are communicating using only encryption (e.g., look for HTTPS protocol).  Most major vendors should be using HTTPS for their apps if they use HTTPS for their website everywhere else, but you can't be sure (and its safer to assume it doesn't).  You mentioned Dropbox, and Dropbox for example states they use network encryption (TLS) everywhere between their apps, so you are safe to use Dropbox (assuming they are checking certificates correctly).

If you are unsure of a mobile app you can often use the mobile HTTPS site in your web browser instead.


Why does error-based SQL injection works only with certan fields? I'm currently investigating the latest vulnerability affecting Joomla CMS.

You can find here a description of the vulnerability, however my question is merely on error-based SQL injections and is context independent.

The base URL I use  to access the vulnerability is:

https://example.com/index.php?option=com_contenthistory&view=history&list[select]=SQL_INJECTION_HERE

The injection I use is in the form:

(select col.a Array from (select count(*), concat(0x3a, 0x3a, (select user()), 0x3a, 0x3a, floor(rand()*2)) a from information_schema.columns,  jml_users  group by a) col) ,'A' union select uc.id

The example above works fine: executing it a few time randomly produces Subquery returns more than 1 row and the expected Duplicate entry '::joomla@localhost::0' for key 'group_key' error messages leaking the MySQL user used by Joomla :) !

However, I cannot access all the database content. Some fields will always produce the Subquery returns more than 1 row and never leak the information they contain.

This limitation is reproducible when connecting directly to a MySQL prompt.

I did not encounter any description of this (quite annoying) limitation in the articles I read on the subject. Is it something known? Is it specific to my MySQL version (5.6.14-enterprise-commercial-advanced)? Is there any workaround?

Here are which requests work using this injection and which doesn't, associated to their column types:

What works:

Using MySQL internal functions like users(), database(), etc.
Using system variables like @@version, etc.
Accessing short sized column contents like these ones all from the *_users table: *id (int(11)), email (varchar(100)), password (varchar(100)), registerdate (datetime), etc.

What does not work:

Accessing longer sized columns like (still belonging to the *_users table) name (varchar(255)), username (varchar(150)), params (text), otpKey (varchar(1000)), etc.

Here it becomes clear that the thing somehow keeping the error-based SQL injection to work properly is the field size (not matter the content size, the column could be empty).

The solution then becomes crystal clear: add a substr() call to the SQL injection and now the whole database content becomes accessible :) !

http://example.com//index.php?option=com_contenthistory&view=history&list[select]=(select col.a from (select count(*), concat(0x3a, 0x3a, (select substr(name,1,100) from jml_users limit 0,1), 0x3a, 0x3a, floor(rand()*2)) a from information_schema.columns i1 group by a) col),'A' union select uc.id

500 - Duplicate entry '::Noob::1' for key 'group_key'

Owned :)! (I do still wonder though if this limitation is a general one or is limited to this version of MySQL server).


how does tor protect data packets? When you're using tor can't the third parties copy all the data that's going back to your device and decrypt it later, let's say I downloaded some doc files, the data has to come back to your device through your isp servers right. If your government wants your isp to keep copies of all the data packets to be reviewed later can't they just break the encryption later? I'm sorry if this question sounds stupid but I'm still a noob and I'm using tor from a week.

The idea of encryption is that you can't break it. At least, not without a lot of computing power and/or a lot of time (say, 80 years). So, you should be good to go. :-)


How can reverse proxies be used to bypass acceptable use policies of a company? I am wondering how reverse proxies can be used to bypass company acceptable use policies?

What can be done to prevent it?

Detect It

Regardless of either a forward or reverse proxy analysis of the network traffic with something like Wireshark will allow you to detect it, which is the first step to preventing it.

Proxies designed to bypass filtering or access control will exhibit these types of behaviours as to bots and generally anything trying to hide it’s true purpose:

Long URLs with web site names in them either in the front http://www.google.com.proxy.com/ or trailing like http://proxy.com/http/www.google.com/
SSL/TLS tunnelling
Connections to IP addresses instead of DNS host names
Connections to where the HTTP request Host: header does not match the host name
Non-HTTP connections out on HTTP ports
Connections to TCP/UDP port over 1023

This obviously could include a lot of legitimate traffic however knowing what type of traffic currently goes in and out your network will allow you to detect any anomalies.

Prevent It

Assuming you are starting from no control on your network I would look to build up the following in to enforce strict compliance:

Develop a corporate Managed Operating Environment (MOE) – know what software is installed on your clients/servers, enforce removal of software that is unknown or not permitted.
Use a firewall with good logging and filtering capability on edge network and try to put choke points in so to minimize where you have to look.

Tune firewall rules and logging.
Only log what you need to prevent overload of data that you can’t possibly review.
Use a whitelisting approach. i.e. Block everything coming in and going out by default and allow only known approved  traffic.

Use proxy servers for granular HTTP/HTTPS control.

Choose one that supports category based filtering (which is a dictionary and sometimes other smarts to categorise URLs, they often have a category just to block know anonymising proxies).
Proxy servers can implement SSL interception for blocking tunnelling applications (some legitimate application use this).
Block non-HTTP traffic over HTTP ports.
Block HTTP/HTTPS traffic directed to IP addresses instead of DNS host names.
Regularly review reports on the web traffic, look for suspect host names and uncategorised websites.

Implement an intrusion prevention system

While you might find you are unable to do all of these, any will definitely help.

Hope that helps.


Configure SSL to prefer RC4 ciphers over block-based ciphers - BEAST Our PCI scanners just informed us that we have BEAST (Browser Exploit Against SSL/TLS) Vulnerability

Apparently, the remediation is as follows:

  Affected users should disable all block-based cipher suites in the
  server's SSL configuration and only support RC4 ciphers, which are not
  vulnerable to fully address this vulnerability. This vulnerability was
  addressed in TLS version 1.1/1.2, however, support for these newer TLS
  versions is not widely supported at the time of this writing, making
  it difficult to disable earlier versions. Additionally, affected users
  can also configure SSL to prefer RC4 ciphers over block-based ciphers
  to limit, but not eliminate, exposure

So, basically, we have to only (or at least prioritize) support for RC4 ciphers.

How do we actually go about doing this on an existing certificate?

EDIT: forgot to add that this is an Apache (centos) server

The cipher suite is (mostly) orthogonal to the certificate. The RC4-based cipher suites are:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA

Both require a certificate with a RSA key, and "suitable for encryption" (that is, a certificate which has not been marked as signature-only). There is high probability that your certificate is already fine for that. Beyond that, the certificate is not related to the choice of symmetric encryption algorithm.

The configuration of cipher suites employed by your server depends on the server type. If your server is IIS, see this previous question which describes how it is done.

Apparently, there was an old draft from a decade ago, which defined three additional RC4-based cipher suites:

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA
TLS_DHE_DSS_WITH_RC4_128_SHA

The first two use a key of only 56 bits, which is not enough for serious security (although it may deter some low-power amateurs); these were defined in order to comply with the US export rules which were briefly in force at that time. The third cipher suite provides the only way to use RC4 with a large enough key, when your server asymmetric key has type DSS; it also enables Perfect Forward Secrecy, which is neat.

These suites are not standard (they are not in the IANA registry) but some browsers use them, in particular Internet Explorer. I suppose IIS can be made to support them.

(Certificates with DSS keys are pretty rare nowadays.)


Seems my CNAMEs got "curled". Somebody please explain this to me According to my CloudFlare firewall logs, somebody went through each of my subdomains. My website is not advertised, it doesn't even show on Google unless typing the exact domain name into it. I think I know where they found it listed, though.

Fortunately, the connections were refused by CloudFlare due to the client using Tor, I had already blocked it. It would appear that they gave up at this point as no further log entries appeared. They were apparently using Curl, according to the user agent supplied in the logs.

The person went through each of my valid subdomains, starting with the database. Excluding cPanel, Webmail and my FTP; I assume the reason for this is because they knew full well that the login for those services would be secure. So they were looking for an insecure vector.

I have since taken measures to stealth the restricted services, including the default ones provided by the web host.

Can somebody please explain to me how exactly this unscrupulous fella found my CNAMES? And does it thus qualify that he also knows the A Records?

Thanks!

Can somebody please explain to me how exactly this unscrupulous fella found my CNAMES?

No one can know, after the fact, how an UNKNOWN entity managed to get your UNKNOWN content.

There are a lot of ways to find out names in a zone, there are even tools for this.

This could be a good introduction on the subject: https://blog.appsecco.com/a-penetration-testers-guide-to-sub-domain-enumeration-7d842d5570f6

In summary it lists the following:

using search engines (the site: operator)
passive DNS services (that record huge volume of DNS queries, including possibly yours, hence "divulging" to others the name you have resolved yourself); some ISPs are also sharing DNS queries data (which is one of the strong motivation for people advocating to use DoH)
Certificate Transparency Logs
dictionary based enumeration, and other similar string manipulations
DNS zone transfers
DNSSEC walking (trivial with NSEC, possible but far more complicated with NSEC3)
various useful "side" information: DNS TXT records for SPF, DNS SRV records, various HTTP headers, etc.

You can certainly add others, like: domains are listed in the parent zonefile, which at least for all gTLDs, is free to get; once you have a domain name you can apply the previous points.

A tool that implements various ways: https://github.com/OWASP/Amass

This other article also lists some tools: https://geekflare.com/find-subdomains/

People also often forget how "chatty" by default their OS is, specially on smartphones. And what various browsers plugin can do and record...

In the same way, it is known for example that any link exchanged in Skype will get immediately scanned by some robot (in theory to identify if the link is risky or not). Which means that suddenly a third party will access your site (and hence know a website name) where you imagined no one else knew about it.


Why use a proxy to hide OAuth client credentials in password grant calls? In a November 2014 article by Alex Bilbie, OAuth users were advised against making the client send its credentials (client_id and client_secret) when performing Resource Owner Password grant calls. The idea as I understand it is that for the client to be able to add its credentials to its requests, those credentials must be written in its source code (often HTML/JS) and therefore accessible to possible attackers, which could then use them to perform calls to the API impersonating the client.
In another blog post's comments, the author added:

If I can view source and copy the client credentials there’s nothing stopping me building my own app that can authenticate against your OAuth service and then call the API.

The proposed workaround is that the client shouldn't call the API directly but instead a thin proxy which would be responsible for appending the client credentials to the request and then forwarding it to the API.
As a naive OAuth newbie, I don't understand why this would keep attackers from performing calls to my API. If the client doesn't have to add its credentials to its requests, nobody does. As the proxy automatically adds the credentials, any request sent to the API is then treated as coming from the authorized client.
Someone asked Alex Bilbie this very question in Twitter. Here is his answer:

how would you secure the proxy? Can't the attacker just send a request to the proxy and have the secret happily filled in?
the point is that you’re hiding implementation details of your backend and therefore retaining more control

I would be grateful if someone could elaborate on this answer, as I cannot see what I could gain (security-wise) from hiding implementation details while at the same time removing the need for a client to authenticate itself.

After reading the linked blog post and after cross referencing his issues with the OAuth 2.0 RFC I have a few issues with his concerns. In the first section of his blog post, he has two major issues with using OAuth within a single page web application using the Resource Owner Password Credentials Grant:

The client_id and client_secret are baked into the Javascript.
An attacker can also access the access_token and refresh_token from the Javascript.

Addressing the first problem, section 4.3.2 of the RFC lists the requirements for requesting an access_token using the Resource Owner Password Credentials Grant flow. These requirements don't include a client_secret because the provider trusts the client. If this flow was used for untrusted clients, the client wouldn't need a client_secret because the client could just authenticate to the provider using the users username and password. This flow basically replicates traditional password based authentication schemes.

The second problem does exist, however the author doesn't really explain the impact. To gain access to the user's access_token the attacker either needs physical access to the user's computer or to exploit a separate vulnerability like cross-site scripting within the web. An access_token is basically equivalent to a session cookie except the browser doesn't have built-in mechanisms like the secure and http-only cookie flags to protect an access_token.

Together this means that there isn't really a valid reason to send the API requests through a thin proxy because the application shouldn't expose any secret data that a web application wouldn't normally expose.


How is tivoization implemented in hardware? I am trying to understand how Tivoization worked; but the Internet is filled with discussions about the legal aspect of the matter, rather than technical details of how it was implemented.

My understanding is that the hardware would refuse to load binaries that were not digitally signed with the private key of the manufacturer. I am assuming that the public key had to be hardcoded or stored somewhere.

Why was it not possible to circumvent tivoization by simply overwriting the public key? What kind of storage mechanism guarantees that it would not get overwritten?

If it was hardcoded, then it is a simple matter of finding the offset in a raw binary file and overwriting that data with another key.

It could have been stored in a security module (like a smart card), but to the best of my knowledge those will dearly protect private keys (storing them in a way that does not allow them to be retrieved), whereas public keys are regarded as "just data" and can be easily extracted and modified (if you have the required permissions).

Tivoiazation was added to the Series 2 line.  I tracked down a 2003 TiVo community thread discussing the new protections:

  The ROM checks for a signature on the inital ram disk (initrd). The
  ROM uses TiVo's public signature to make sure it was signed by TiVo's
  private signature. If it passes, the initrd is loaded. Next, linuxrc
  (in the initrd) checks files in the system directories against a list
  of signatures contained in the initrd. If the signature doesn't match,
  it tries to restore it. If that fails, it won't boot. It also deletes
  unauthorized files, and removes "dangerous" items from the environment
  (like BASH_SHELL). It then passes control to the usual Linux startup.

By the end of the thread we find someone has successfully flashed a unit and is offering physical disks with patched versions of telnetd and ftpd.  Here he posts his success with at least on variant of the series 2:

http://www.dealdatabase.com/forum/archive/index.php/t-25116.html

I also found this thread:

http://www.tivocommunity.com/community/index.php?threads/hacking-your-series-2-dtivo-just-got-a-whole-lot-easier.265929/


RSA or ECDHE for key establishment? Recently, i have been looking at PKI and certificates, and TLS 1.2 as part of my study of cryptography. I have the understanding that the public key included in the certificate of a website is the key that is used to establish a session key between two parties.

But on certain websites, when i opened google chromes security overview by clicking on the green https padlock, chrome informed me that the key exchange was done by ECDHE with P-256 (Eliptic Curve Diffe Hellman, curve P-256). But, upon opening the full certificate details for the website, the public key in the certificate was an RSA 2048 bit public key. But, this confused me, as i thought it should be an ECDHE key and i am not sure whether the key exchange is done by ECDHE, as chrome says, or RSA, which is the public key in the certificate, which i thought was used in the key establishment.

Any help would be appreciated.

You are mixing up key exchange and authentication. Key exchange is done so that both parties agree on the same encryption keys. Authentication of the server is done to make sure that the client is talking to the correct server and not to some man in the middle. The RSA/ECC key in the certificate is used for authentication. In case of RSA key exchange the RSA key in the certificate is also used of the key exchange but with DHE and ECDHE key exchanges the certificate key is not used. This means you can combine ECDHE key exchange with both RSA and ECC certificates.

For the deeper details see How does SSL/TLS work?


Would the Cloudbleed have been prevented if Rust was used? Would the Cloudbleed have been prevented if Rust was used? I know it is not the same as Heartbleed, but Rust would probably have prevented Heartbleed.

From the detailed description of the bug it is visible, that they've used already a high level tool to create code but that the did not use the tool properly. To cite:

  The equality check is generated automatically by Ragel and was not part of the code that we wrote. This indicated that we were not using Ragel correctly.

Thus, would Rust have prevented to use a high level tool improperly? Probably not. But if the tool would generate Rust code instead of C code, would then the buffer overrun have been detected? This is likely since protecting against buffer overruns is one of the goals of Rust. But since the tool does not generate Rust code one cannot say for sure how this code would look like and if it really would have been prevented the problem.


Is secret key for HMAC in form of UTF8 characters good enough? There is a popular JWT library on nuget. I am analyzing an application that uses that library and it stores a secret key as a string. In the code of the library I see that it uses the MS HMACSHA256 that accepts byte array as a key. So the library does Encoding.UTF8.GetBytes(key) to pass the secret key to the library.

Since UTF8 encoding means some structure usually (e.g. some byte sequences won't match to any of the printable characters), compared to some Base64 that can have any random byte sequence, won't it mean that this key is more predictable that it should be?

Can it still be secure enough provided the proper generation of this key, and how should it be generated in this case?

I'm assuming here that key is something static at system level, and not something an individual user chooses - if so, it is very strange that it is read as UTF-8 rather than as Base64 because UTF-8 will be an inefficient storage mechanism for the key as it won't be using the full keyspace. I would put this down to developer naivety rather than anything done out of reason.

This method would make more sense if it was for a user chosen key, as they may have entered unicode characters as they key, and therefore if it is stored and read as UTF-8 it can then be put into a key-stretching function such as PBKDF2. Here the goal isn't efficient storage, it would be simply making sure that a user chosen key has enough entropy to be useful.

  won't it mean that this key is more predictable that it should be?

When the key goes into the HMAC function, it is hashed along with the message. The fact that it is from a UTF-8 string should not make the resultant HMACs more predictable nor should it make brute-forcing the key any easier. As long as the original string has enough entropy in it to begin with, it won't matter what format it has been converted to for storage.

  Can it still be secure enough provided the proper generation of this
  key, and how should it be generated in this case?

From this answer, a 128 bit random value generated via a cryptographically secure pseudo random number generator would be recommended for the key. The CSPRNG would generate a byte sequence, so this could be Base64'd and then stored as UTF-8, albeit with the keyspace never being completely filled. It would be better if the UTF-8 step could be completely removed though because it adds unnecessary complexity.


Check for insecure CORS settings with cURL I'm trying to verify the CORS settings of a website using cURL. The following command should let me check whether the CORS settings can be considered as secure or if requests may be made across origins.

I'm performing a preflight check, but the same should work with normal request and the origin header.

Preflight:

curl -H "Origin: https://example.local" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS -D - -o /dev/null\
  -x http://127.0.0.1:8080/\
  https://example.com

GET with Origin:

  curl -H "Origin: https://example.local"\
  -D - -o /dev/null\
  https://example.com

Now what I do not understand, is that the target application simply answers with the content as usual. No Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers headers.

So I effectively can't decide on whether the CORS settings are secure or not. I tried to proxy the requests through Burp (with the two methods below), but something's wrong there and the request never reaches Burp.

Method 1 cURL:

curl [...] -x http://127.0.0.1:8080/ [...]

Method 2 CLI:

export https_proxy='https://127.0.0.1:8080/'
export http_proxy='http://127.0.0.1:8080/'

curl [...]

export https_proxy=''
export http_proxy=''

What may cause the odd behavior of the web application with my OPTIONS pre-flight requests and the GET request with the origin header.
How can I successfully proxy the request through Burp to verify the request itself?

You should only specify the origin header in your request. The application will respond with the Access-Control-* headers. Try only specifying the origin header and see what the result looks like.

As far as if the headers are not returned at all, the web server doesn't have to respond with a CORS policy. If it doesn't then the browser will not allow cross origin requests as per usual. CORS allows the server to enable cross origin requests given certain criteria.

The main issue that I find when doing testing for CORS issues is that the Access-Control-Allow-Origin header is populated by what is sent in via the Origin header in the request. This defeats the entire purpose of CORS. An attacker shouldn't be able to define allowed origins.

There are several different Burp extensions that will report on CORS related misconfigurations and security issues. There is also this post on the Portswigger blog detailing some common misconfigurations.

http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html


What's the best way to transform sensitive account numbers I work on a web application that manages information about transmission setups and processes client transmission statistics to generate billing charges for the services used by these clients.
The team that supports these clients is able to view setup information, including account information and user access controls meet requirements for their production usage of this information.
For testing, data is moved to testing/development environments where the account numbers need to be 'sanitized' or 'transformed' in the best way to avoid the testing/development environments from exposing these account numbers.
I have done work with encrypting data and hashing data and I am looking for suggestions/comments about what are best practices for the 'sanitization/transformation' of these account numbers.
Thanks for any feedback you can provide.

If you must absolutely use production data in DEV, you may produce a table matching actual account IDs with random ones, then destroy or adequately protect the table after transferring data.

 REAL ID  |  FAKE ID
 --------------------
 0000001  |  3287638
 0000002  |  5917382
 etc.

Beware DEV data may include other information connected to the account number (e.g. an email) allowing a malicious insider to retrieve the account number from public data. Another risk is that malicious insiders try brute-forcing all  accounts in production with configurations found in DEV.


Bank asked for a cross login? I was creating a new bank account here in the US at HSBC's popular online bank...

You know the step where you have to verify the account you're sending from, by receiving two small test payments?

I was astounded to see HSBC have a new system:

You give them the login for your current online bank.

Below that is a user/pass field, which they apparently use at your online bank, spoofing a browser.

I actually TRIED IT, cleaning up afterwards.

Incredibly, the next step they echo to you the two-factor questions ("by text, email .." etc) - you read that right.

Then they echo through to you the code ask!

648315 was the code actually texted to me by my credit union; I typed it in there.

(Note the reassuring message: "Your login details won't be saved in our system"!)

So,

Is this common now?!  Conversely, is it brand new?
Would it actually be illegal in some way?
It seems incredible that other banks wouldn't block them once they heard of the practice, or at least complain bitterly.

I cannot fathom this happened.  But there it is.

If you want to try it, seeing the screens, go ahead and pretend to open an account there. You're not actually obligated (even for marketing garbage) until a few steps after that step, so really it's harmless to get to the point of seeing that screen.

Funnily enough it didn't work in my case: the end result was "Sorry, you'll have to use the 'small test deposits' method ...".

The process did clearly work technically through all steps: incredibly I saw the (raw html, handled a bit badly) from my credit union asking "text? email?" .. and I literally got the SMS etc. from my bank.  (Perhaps it failed in the end due to IP, or their scraper failed or whatever - who knows.)

(Unfortunately, looks like my bank does not list recent IP attempts.)

Is it just me or is this totally wrong ?!?

Disclaimer: IANAL

  1    is this common now?! conversely is it brand new?

First time I read of it, but I know that many online banking system propose to aggregate your other bank accounts on their site. Mine proposed to but I declined so I cannot tell exactly how they manage to prove the third party bank that the client allows them to gather account elements. The account number is certain, I do not know for other credentials. The goal is to collect all of your banking informations, because this does have value for announcers.

  2    would it actually be illegal in some way?

As already said IANAL. But I cannot imagine why it could be illegal: they ask you some information saying how they will use it. You are the information owner and can choose to share it with them or not. The only point that could be illegal would be that they declare to not store an element and actually store it. Being professional, they also have to protect your sensitive data, but provided it is not transmitted in clear text nor stored, I assume that it is enough.

  3    it seems incredible that other banks wouldn't block them once they heard of the practice, or at least complain bitterly.

Not that simple. The other bank has a contract with you allowing you a number of operations provided you can prove that you have an account, a password and a unique code sent to a device or mail address. You are responsable for securing those elements and implicitely ask them to honour any request presenting them. They would probably be more happy if you used their own system to connect to your other bank accounts, but I cannot imagine a legal point for preventing you to use any third party added value system.

Now for my opinion. On a security point of view, a secret should never be shared by more than 2 entities. So I would never post my credentials for a site on a site of a third party company, whatever the reason. I know that this will prevent me to use some sexy added value aggregators and I accept it. At least I will try to keep that security policy as long as I will be able to...


How can I detect (or inventory) all DLLs that don't use ASLR? Based on this IE zero day, I'm interested in listing all DLLs in our systems that have been compiled to not work with ASLR.

Ideally, I'd like to analyze a static file and not load it into memory to detect if it's compiled without ASLR protections.

Lastly, once I have a list of files that are incompatible with ASLR, what can I do to prevent or control them from loading short of uninstalling it?

If you just want to know if one DLL supports ASLR, then load it into CFF Explorer, go to the Optional Header section, then click on the DllCharacteristics row. If "DLL can move" is checked, then it's ASLR-enabled, otherwise it's not.

If you want to do a lot of them, I would write a Python script that enumerates all DLLs in a target directory, then checks them using the pefile module. This gives you access to all sorts of information, including the DllCharacteristics field of the PE header, which you can check to see if IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE is set. That'll tell you whether it's ASLR-enabled or not.

In terms of preventing them from loading, there's not much you can do. However, you can use EMET to set Mandatory ASLR on a process to enforce that every DLL loaded gets ASLR enabled, regardless of whether it's set in the PE file or not.


How can I analyze password recovery tokens? All websites that support authenticated user interactions have a password recovery feature. Usually they will email the password reset link through which you can easily recover your account by typing a new password. So, when pentesting some of these websites I've noticed that the password recovery token seems to be somewhat guessable. Some of the websites use MD5 or Base64 encoding for their password recovery tokens.

So, my question is whether is there are any standard procedures we could use to determine the strength of a token, or the method through which token has been generated?

Example of password recovery link:

http://example.com/users/password?recover_token=qQGgQrwzzz1SV1X9xznc

(Where the password Recovery token is qQGgQrwzzz1SV1X9xznc)

If you do not have access to the source code, you will have to make multiple attempts to see if there are any patterns in the token generation. If it is a basic incrementor, this may be easy to defeat. You can take the length of the token into account as well.

Here are some OWASP guides on the topic, which may be of use:

Testing for weak password change or reset functionalities (OWASP-AT-011)
Testing for Vulnerable Remember Password and Pwd Reset (OWASP-AT-006)
OWASP-Security101 Password Reset Options

These will help you with the testing part, but you may want to open a question on the cryto or math SE on how you would actually go about pattern prediction.


Assuming no MITM, is Gmail communication 100% secure and private? I sometimes have to use my personal Gmail account from my company workstation, where I know for fact they are using content-aware firewall(s) like Palo Alto, and potentially other nasty things like transparent proxies.

Assuming:

the Gmail certificates that I installed in my browser are authentic, because...
the browser image itself is authentic, because...
my company sys admins are not engaging in any DNS hijacking to carry out silent MITMs between me and real Gmail servers,

Then:

Can things like the email Subject, the Recipient list, send/receive dates, etc be read by any 3rd party along the way?

(My understanding is, the https protocol guarantees 100% privacy or secrecy from any eavesdroppers but I'm not fully up-to-date on the current state-of-art in Computer Security.)

Can things like the email Subject, the Recipient list, send/receive dates, etc be read by any 3rd party along the way?

Nope, unless you have been coerced to install some 3rd party cert on your computer. Some companies don't allow you to use the Internet unless you whitelist one of their certificates (and all https traffic is decrypted-reencrypted and sent along). In such a case, they can read everything you can (and taint the data too).

Another  thing that is possible is that you have added a malicious cert to your exceptions list without knowing what was going on. This happens -- user visits website, user gets ssl error, user adds exception. If that cert was a * cert or something like that1, then you're in trouble. Of course, you can easily check this in your browser certificate list.

However, since you've explicitly mentioned that your certificate list is pristine and there is no MITM going on, both of the above are ruled out.

Unless, of course, Google really is working with PRISM ;-)

1. I'm not entirely sure if browsers still accept * certs (CAs don't hand them out though). Firefox still seems to allow them. Either way, a similar attack can easily be done wth multiple-domain certificates: I can use an unsigned cert on manish.com that works for manish.com,*.google.com. Any visitor who whitelists my cert will be MITM-able.


Is eCryptfs vulverable when storing known file trees? I use the standard Ubuntu eCryptfs setup to encrypt my home folder. As far as I can tell it encrypts the files and their names, but the directory hierarchy is essentially the same.

Every git repository contains the same hooks folder with the exact same number of files. The .git usually has the same number of files and folders in it. It should be possible to write a small script that searches for git repositories and tells you which the hooks folder is and so on. Then you have only limited possibilities which hook is which, which might be even so see by the file size.

Then you know the contents of a file and the encrypted version. Would that make cracking the encryption feasible? The only solution is a completely encrypted disk with LUKS?

Known-Plaintext Attack

A known-plaintext attack is a technique for determining the key of an encrypted block of data based up a known plaintext that was encrypted to a known ciphertext.  Some modern symmetric encryption algorithms are susceptible to this type of attack.  There are also [chosen-plaintext attacks] where the attacker chooses plaintexts to be encrypted to a known ciphertext.  This is often to gain knowledge of the encryption scheme, spot patterns in the encryption, or recover the encryption key.

Ubuntu uses AES 128-bit encryption (by default) for encrypting their home directories with eCryptFS.  While 128 bits is not the "most secure" option of AES it is more than adequate, and is largely considered to be secure against all known cryptographic attacks.  There are no known known-plaintext attacks for AES with any keysize.

I believe its safe to say that your home directory is secure while using eCryptFS.  Here is a more detailed explanation on eCryptFS itself.


How to check whether the erase was secure enough? Edit: this is not about how to securely erase, but how to check whether the erase was secure enough.

I have over written my SSD with very large video files, in order to overwrite any sensitive data I may have had, before selling the SSD.

I use the Mac program Disk Drill to try and recover deleted files, but it didn't find any file to recover.

Does that mean my SSD is safe to sell?

What if I use another similar program, will it be able to find something, or do they all look for data the same way?

Some drives conform to higher ATA standards than others. An ATA secure wipe (if available) will tell the controller to "release the charge in the NAND chips", effectively making it appear that there is no data on the drive. This can brick drives, as some overwrite firmware as well.

More importantly, a study done by the University of California San Diego showed that an ATA secure erase command may not sufficiently destroy data: http://nvsl.ucsd.edu/index.php?path=projects/sanitize

Some older consumer SSDs (and some newer ones) are SEDs, or Self Encrypting Drives. Each write to drive is first passed though the drive's controller which encrypts data before it is written. The advantages of these types of drives is that by changing the key used for encryption, one can have some level of confidence that the data is not recoverable. Data is unrecoverable by consumers.

As others have pointed out, with SSDs, there are other "reserve" blocks of memory which do not tend to be overwritten when preforming a disk wipe (especially generic disk wipes). This again should not be of significant worry for consumers as consumer level disk recovery software would be unable to recover from those special blocks.


Spoof texting a regiatered number to yourself and relying....having a conversation I feel like I am going crazy. A friend was at my house and received text messages from a number from a person i know. She had a conversation with this number for basically a week. She is now saying that she set it up to make it look like it was that person texting her. The messages were even coming in when she was asleep.. Is this possible??

Yes, this is completely possible; your friend most likely set up a bot to reply to her when she said certain things, in order to simulate a conversation. Tell your friend nice prank :D


How to store passwords in database so that they can be retrieved? I'm developing a password manager web app. It's just for fun: I'm not exposing anybody's passwords.

My idea was to use hashing+salting, and that's what I did for the master password. But then I realised that I have to retrieve accounts' passwords in order to use them (and I felt a bit stupid), so that hashing is not an option.

Obviously symmetric encryption is useless in this case because we have the same problem with the decryption key. And asymmetric encryption could be an option but not very practical (the user has the private key and he has to use every time he wants to get a password: not practical).

I don't know how can I use these cryptographic tools (or others) to solve this problem.

Summary: I have to store passwords in a database but I have to be able to retrieve them in plain text.

The normal mechanism for a password manager is to have some sort of "master key" and encrypt the data (symmetrically) with that key. The master key, in your case, being derived from the master password through proper password hashing (so it becomes, in this case, password-based key derivation). So use bcrypt or PBKDF2 to turn the user's master password into a key K, and keep all the data for that user encrypted with K.

Making that as a Web application is of questionable wisdom. Even if you do it all client-side in JavaScript, that JavaScript is still code sent by the server, and code that sees all passwords for all users, so the server becomes a very sensitive and juicy target (if the server goes under hostile control, that would turn into an orgy of password theft).


What is the purpose of using hex escape sequences when writing buffer overflow exploits? I was trying to overwrite fp function pointer to 0x8048424(win() location) so that function win() will be called to solve this problem(machine is little endian)

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
  printf("code flow successfully changed\n");
}

int main(int argc, char **argv)
{
  volatile int (*fp)();
  char buffer[64];

  fp = 0;

  gets(buffer);

  if(fp) {
      printf("calling function pointer, jumping to 0x%08x\n", fp);
      fp();
  }
}

I am able to do this by overflowing buffervariable and then overwriting fp
by doing python -c "print'A'*64 + '\x24\x84\x04\x08'" | ./stack3.

But my question is why we need hex escape sequences?I have saw this notation in many tutorials but none of them explained it purpose

I read about this and found that they can be used as escape sequences. for e.g \n(which is a newline character) can be written as printf("\x0A") and it will do the same thing. So it makes sense.

But when overwriting memory why we need this? I didn't understand it's purpose here in buffer overflow
Why we cannot simply use python -c "print'A'*64 + '0x24840408'" | ./stack3. I mean we are just writing a memory address to a pointer variable.

PS  My question is related to this question but unfortunately it doesn't answer my question that Why do we need \x notation in first place

A hex escape sequence \x{whatever} represents a single byte of data. That byte can represent different things depending on the program reading it. For instance, \x78 could represent the character "x", the number 120, 'the 120th byte of the following section', or any special meaning assigned to it in context. If you write the string of characters "0x24840408", it'll be interpreted as the string of bytes \x30\x78\x32\x34\x38\x34\x30\x34\x30\x38 (you may notice that the characters "0" to "9" are represented by \x30 to \x39). When you write character strings here, they're simply interpreted as the corresponding string of bytes, the computer doesn't look at what characters those bytes represent. When your debugger prints out the address "0x8048424", it's not printing what's actually stored in memory - it's trying to be helpful by interpreting the four byte sequence \x24\x84\x04\x08 that's actually there and printing a string of characters humans can understand (Also it can't print \x24\x84\x04\x08 as the characters it represents because three of those characters are either unprintable or invisible).

It would be possible for a program to convert the other way and turn "0x24840408" (or indeed "0x8048424") into \x84\x24\x04\x08 in memory, but the python interpreter doesn't do that by default because it's not often needed outside of exploit development. If you really do mean 'put this four-byte value into memory verbatim', that's what escape sequences are for.

So, to summarise:
"0x24840408" is represented in memory by \x30\x78\x32\x34\x38\x34\x30\x34\x30\x38
\x24\x84\x04\x08 represents "$[three unprintable characters]"* (ie. \x24 represents $ - but we don't care what string it represents because we're interpreting it as an address)

*actually it'd usually be "$[one unprintable character]". \x08 as a character represents 'backspace', so it should remove the \x04 before it. But that's not really the point.


Bot detection ideas [php] I am looking for bot detection ideas. I don't mind bots crawling my site, that's cool, the problem is when they start posting stuff. I recently had to erase 400 accounts because of a bad boy like that. I need to disable bots to post any data to my database, that being account registrations, comments, user messages etc. So what are my options?

Captchas aren't really an option, we don't live in 1990 anymore. Another method I found that seemed interesting was a db of known bots, as well as searching the user agent string for bot spider crawler etc, which seemed pretty promising, but then there's that hardcoding names part which I don't like for obvious reasons and I guess that wouldn't work as well.

I'm looking for something that doesn't need to be updated and will pretty much work until the end of time. My idea was to create a check-for-bot method which would be called on all posts (POST requests that insert into a table) and record the time of the post and the IP of the user/bot and whenever a record exists its time of creation will be compared to current time and stuff like that, but that would fail too because there are networks that use the same IP and may cause an issue there, especially with wifi, you know how it is nowadays.

Does anyone have any idea, possibly similar to mine, or even better? I really need to stop those bots from keeping posting stuff to my site but I need it to be a neat way too.

Thank you for your time reading this, even if you cannot help me!

I use a Bayesian scoring approach for a lot of my corporate sites. Some of the measures are a bit extreme, but I've found over time that most of the bot writers cut corners. That's not to say they haven't spent some time trying to figure out what's going on with my code.

I keep score per user, and a score per message. Also on some sites I'll keep score for an IP range by looking up the IP's registrant (via ARIN or something like that).

To begin with I set a timestamp. I pass it forward clear and hashed with a salt that I know part of myself (private key) and part of it is generated on the fly (temporary). This way it changes with every post.

On the next page I compare the timestamp with the hashes. If they're within a reasonable range of human interaction, then they're allowed to pass. If they're not, then they're obviously going to get negative points.

On registration I look for things like:

phone numbers that don't contain numbers
names that contain strings of numbers
email addresses for domains that aren't registered (or have no MX record in DNS)
I check their IP against their supplied country. (this one can be a bit tricky, so don't score it too high in the event they travel)
Websites that aren't registered - fake websites or websites like google, yahoo, or facebook (without a directory)
If they setup their profile so they have an offsite link to someplace I don't want or that is off topic they get a negative score
Additionally I block one-time use e-mail accounts and several of the free accounts where they don't have a clear policy about abuse.

In posts I and in their profiles:

I do a dictionary attack on posted content to check for variations of words. You have to be careful because a pattern in regex like !cialis! will match specialist.
If the posts are of a great length, I'll measure the amount of time the person has been on the site (logged in or not with a cookie) the length of the post and the average typing speed per industry. (Tech people type faster.)
I don't trust posters who are new to the site

Overall

I maintain a whitelist and a blacklist - The whitelist looks for exploited accounts as well.
I check referrers on handlers for forms. If they're not using the site (with the preceding page's hash) then their comment is flushed.
I check if their SESSION_ID is in the sessions table or not. If it's made up, then they're flushed.
I check user agents that are empty or things like cURL or Java.
I also check their contents with a ratio of vowels to consonants. If they don't fall within a normal range then they're flagged.
I check for words of enormous length without spaces. (This depends on the accepted languages)
And obviously things like semicolons followed by an exploit. (eg. ; UNION)
After all of that I do things like setup honeypots to non-visually-linked directories and scripts, so only someone looking at the code or mining for forms would find them. If someone from an address posts a link to one of the hidden forms they go into a database (replicated to my other sites) that contains known bad offenders.

Obviously blocking IPs might get a few false positives (for instance about 10 years ago I positively penetrated a competitor's site at one of the firms I was looking at with a <marquee> tag non-closed that made the content on their page walk off of the screen. They blocked all traffic from the firm's dynamic IP luckily we were using ADSL for that line and smart enough not to use our fixed ISDN line). We were using a secondary marketing approach to review their contents when I noticed an exploit on a hunch. (I told their programmer how to fix it.)

If you're trying to deal with a botnet that's a whole other animal, but most of the practices I've outlined above will work as well.

Check for proxies if you're only receiving malicious additions from proxies
Check for random IPs around the world within a reasonable amount of time (like someone has shared a login with a bot-net).
Try to use unique identifiers in cookies and urls to track people's movements throughout the site.

Normal posters will have a definite, noticeable pattern to their habits. Non-normal posters do as well. You just have to be diligent and spend a little time tracking their habits in databases.

For me, I always notice the patterns when I'm looking at a MySQL log of sessions, IPs, and traffic. I can usually catch the botnet setup session, then expect the worst. Most of the time it's script kiddies.

If you're worried about brute force, run something like iptables or apf. It will also stop some of the faster bots that try to post multiple pages at the same time, or the ones that post over and over to the same form without visiting any other pages.


Brute Forcing DVWA with Hydra I am attempting to brute-force 'DVWA/vulnerabilities/brute/' with Hydra, rockyou.txt password list.
I tried using this command:
hydra 127.0.0.1 -V -l admin -P rockyou.txt http-get-form "/DVWA/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:F=Username and/or password incorrect.:H=Cookie: security=low; PHPSESSID=0tp8jmqci1c8qblpgocgkuck0p"

And the output of this is:
[80][http-get-form] host: localhost   login: admin   password: iloveyou
[80][http-get-form] host: localhost   login: admin   password: princess
[80][http-get-form] host: localhost   login: admin   password: 1234567
[80][http-get-form] host: localhost   login: admin   password: 123456
[80][http-get-form] host: localhost   login: admin   password: 12345
[80][http-get-form] host: localhost   login: admin   password: 123456789
[80][http-get-form] host: localhost   login: admin   password: password
[80][http-get-form] host: localhost   login: admin   password: 12345678
[80][http-get-form] host: localhost   login: admin   password: nicole
[80][http-get-form] host: localhost   login: admin   password: rockyou
[80][http-get-form] host: localhost   login: admin   password: abc123
[80][http-get-form] host: localhost   login: admin   password: daniel
[80][http-get-form] host: localhost   login: admin   password: babygirl
[80][http-get-form] host: localhost   login: admin   password: monkey
[80][http-get-form] host: localhost   login: admin   password: lovely
[80][http-get-form] host: localhost   login: admin   password: jessica
1 of 1 target successfully completed, 16 valid passwords found

16 passwords that doesn't even work...
I tried changing '127.0.0.1' with 'localhost', changing Cookie...
What am I doing wrong ?

Check if DVWA application is set up correctly. For instance, call http://localhost/index.php or http://localhost/about.php. If the application is set up correctly, you will see corresponding text from PHP. Otherwise you will see errors like 500 or 502. The reasons can be for instance incorrect integration of web server with PHP, or incorrect connection of DVWA to database.
In case application is set up incorrectly, the response will not contain the expected error message. Hydra will consider this as success, no matter what passwords you will provide.


Does Google/Dropbox/Github Two-Step Verification count as Two-Factor? This considers the route where somebody does not use the SMS option, but rather using TOTP, and the site offers a generated seed to input.

Two factors questionably at use:

password: something KNOWN
TOTP: does this count as something you HAVE?

What proof is there that I am using my cell phone to generate the TOTP codes? You can write the algorithm in maybe 30 lines of most languages, what if I have a script on my computer do it? Or have the same seed/script on all of my computers? Does this still count as a HAVE?

Extra followup if this use of TOTP does not count as two-factor (if I'm allowed followup questions): Is any use of TOTP acceptable for HAVE?

TOTP is an extension of the HMAC-based One Time Password algorithm (HOTP). Both TOTP and HOTP require an secret key to be incorporated into the algorithm. Devices and tokens that implement TOTP (Yubikey, Google Authenticator app) are designed to protect the secret key against extraction.

For example, Yubico mentions:

  Secure manufacturing process
  The YubiKey is manufactured in Sweden, in a fully access automated process, using YubiHSM technology to
  ensure that no staff or IT administrators can have access to
  encryption keys.

  Easy to program own secrets The YubiKey requires no special hardware for programming, enabling you to easily program and control your own
  encryption keys. If required, Yubico offer optional password write
  protection of the settings, but all YubiKeys sold on our web store can
  be re-programmed. For security reasons Yubico firmware is not
  upgradable, it’s a write only device and the encryption key can
  never be read out from the device. [Emphasis mine]

  Tamper proof casing The YubiKey is based on standard components, high-pressure moulded into plastic, making it practically impossible
  to tamper. If tampered, it will require sophisticated equipment to
  read out the secrets and cannot be done without physically destroying
  the device. Each YubiKey is seeded individually, so any breach would
  be for that unique Yubikey only, there is no systemic breach. If lost
  or stolen, the user administrator can easily disable the YubiKey so
  that it no longer can be used.

If we assume that the secret key cannot easily be extracted from the token (and the above examples indicate that we can make that assumption), then it counts as "something you have". Even though the token may be mass produced, once combined with the secret key it becomes unique for the purposes of two-factor auth.

Edit:
Thank you to Terry Chia who has pointed out that the Google Authenticator app stores the key in cleartext in a sqlite database on the device. This was reported in a bug report in March 2013. Google promptly noted that this is a "won't fix" issue:

  Reported by wolfka...@gmail.com, Mar 26, 2013 What steps will
  reproduce the problem?
  1. Open the databases database from within /data/data/com.google.android.apps.authenticator2/databases/database...

  klyu...@google.com
  Thank you for your report. This is working as
  intended/designed. Step #1 assumes you have root access or have
  otherwise compromised the security of the Android device. Security of
  data stored on or processed by such devices cannot be guaranteed. ...

I'll note here that you can and should encrypt your Android device, and doing so will mandate a password to unlock the screen. This will protect against key extraction, among other things.


Using Noscript while opening links I opened two emails. Supposedly one was from Zendesk (the other I did not realize was from another source. Attention was elsewhere). Anyhow, I clicked on the unsubscribe button. Normally, this a good policy for legitimate sources. Men don't always multitask very well :/

In this case, I clicked on the one from the supposedly non-legitimate source. I was wondering, since I have noscript on at all times, could I possibly get infected? All I got was a spinning circle (in the tab) with the new tab internal address.

Note: I obviously have the scripts enabled for my email provider. But not for random websites.

According to the Zendesk email, they claim that the person/group had some malware. Something about a file or something. Now, I have zero clue whether that email itself is legitimate at this point. Have I dealt with Zendesk in the past? Yes. With which email account? I cannot remember.

In any event, the email does not come with an attachment as Zendesk claimed it would. Anyhow, this is what they wrote:

  Your computer(s) may be infected with a virus if you recently:

  Opened a file from "Joyce Lim" named "info.xls", "information.xls",
  "infos.xls", "mail.xls", "market.xls", or "marketing.xls" related to a
  job opening entitled "Need mail and other lead generation
  consultation." Enabled macros from the file, or already had your
  macros enabled

I am currently running MBAM, and will run superantispyware afterwards, and then Avast. Finally, I will run norton power eraser.

You're most likely fine although depending on the attack (how targeted, how much the attacker knows about their audience). If you didn't open any attachments you most likely do not have malware on your computer because a javascript to sandbox escape zero day is very very valuable and would likely be weaponized by or at the government. As long as you don't have any vulnerable extensions (any extensions which interface directly with an unsandboxed application are dangerous and can potentially be exploited for RCE) you are likely safe on this front.

The worst case scenario is that the unsubscribe page had some malicious content in it that attacked your other accounts using iframes or some other CSRF approach. With javascript disabled except for special domains your are still quite vulnerable to some attacks however these only would affect vulnerable websites and the accounts you use on them. So worse case scenario your account on a website has some XSS injected into it. Without javascript exploiting an XSS is more difficult however if it's stored you may eventually end up signing in without noscript and then it's game over because pretty much any action you can take on the site the attack can now as well.

The issue with these web to web attacks is that once you're infected it's really hard to know and it's up to the site operators to detect and fix these vulnerabilities. Keep noscript running but I wouldn't be too worried since it's out of your hands at this point.


Setting the HTTPOnly flag for PHPSESSID cookie I am getting this message from my security audit:

Cookie name: "PHPSESSID"
Cookie domain: "xxx.xxx.xx.xxx"
If possible, you should set the HTTPOnly flag for this cookie.

How can I set the HTTPOnly flag for this cookie?

You have at least 3 ways to achieve that:

In the PHP configuration file (php.ini), look for session.cookie_httponly setting and set it to True.
If you don't have access to PHP configuration, you can try to overwrite this setting at runtime:

ini_set("session.cookie_httponly", 1);

If it doesn't work, you have to manually overwrite that cookie:

session_start();
$params = session_get_cookie_params();
setcookie("PHPSESSID", session_id(), 0, $params["path"], $params["domain"],
    false,  // this is the secure flag you need to set. Default is false.
    true  // this is the httpOnly flag you need to set
);

setcookie() definition:

bool setcookie ( string $name [, string $value = "" [, int $expire = 0 [, string $path = "" [, string $domain = "" [, bool $secure = false [, bool $httponly = false ]]]]]] )


Deploy intranet application with SSL certificate My company has an intranet application build on the WAMP stack - Windows / Apache / MySQL / PHP. This application is installed on a server at each customer's site, and is accessed via LAN IP address. For example: http://10.0.0.100/myapp.php or http://192.168.1.19/myapp.php

How can I secure the web application so that it uses a valid SSL certificate? Issuing an SSL certificate from mycompany.com will not help because the web application is accessed from an arbitrary LAN IP address.

Self-signed SSL Certificate

It is possible to use self-signed SSL certificate as a workaround. That is not a long term solution, and I want to avoid users seeing this

AFAIK setting the exception in each users browser is the only way to get rid of that message when using a self-signed certificate.
But: If your company has a wildcard certificate you could define a sub domain, that is just accessible in local net.

If your company doesn't have the wildcard certificate, you could still create the sub-domain, acquire a free SSL certificate (there are some certificate authorities lately offering ssl certificates for free) for the desired sub-domain for internal use.


Bypassing XSS filter replacing characters? Is it possible to bypass an XSS filter that replaces the malicious characters?
I've prepared this filter:

searchTextField.replace(/</g, " ")
    .replace(/>/g, " ")
    .replace(/"/g, " ")
    .replace(/'/g, " ")
    .replace(/=/g, " ")
    .replace(/0\\/g, " ")
    .replace(/\\/g, " ")
    .replace(/\//g, " ")
    .replace(/  +/g, " ");

The output appears inside span tag like TextHere. My simple question: Can it be bypassed?

Yes. This is exploitable in some browsers via UTF-7 techniques, and other older browsers via surrogate Unicode characters (some old browsers let you use weird "equivalent" characters for < and >, for example).

Don't use blacklist filtering. Filtering and encoding are hard problems and you shouldn't try to tackle them yourself. You need to be able to contextually encode content for the specific content type and context you're outputting content to. Consider using a library such as OWASP Reform, which supports PHP, Python, Java, ASP, and ASP.NET platforms.


Is my ISP BGP/DNS hijacking? I've noticed some very suspicious activity from my ISP.

Sometimes I would notice that when I ping google.com it would resolve to an IP which is owned by my ISP. I currently don't have an example since it is resolving normally at the moment.
However, here's a weird thing. My ISP's DNS servers (41.128.225.225), 8.8.8.8, 8.8.4.4 and 4.2.2.2 are all pinging at about 12ms. Here's a traceroute of all these IPs which shows that the traffic never leaves the ISPs network.

ISP DNS:

Tracing route to 41.128.225.225 over a maximum of 30 hops

  1     4 ms     4 ms     3 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    11 ms    11 ms  172.18.1.85
  4    11 ms    11 ms    11 ms  41.128.225.225

Google DNS:

Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops:

  1     4 ms     4 ms     3 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    12 ms    11 ms  172.18.1.97
  4     *        *        *     Request timed out.
  5    12 ms    12 ms    12 ms  172.20.2.14
  6    48 ms    15 ms    13 ms  172.17.1.10
  7    13 ms    13 ms    12 ms  google-public-dns-a.google.com [8.8.8.8]

Level3 DNS:

Tracing route to b.resolvers.Level3.net [4.2.2.2]
over a maximum of 30 hops:

  1     6 ms     3 ms     2 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    13 ms    11 ms  172.18.1.81
  4    14 ms    35 ms    16 ms  b.resolvers.Level3.net [4.2.2.2]

All the 172.16.0.0/12 are in the ISPs private network which means none of this traffic left into the outside world.
Can someone confirm if this is genuinely suspicious activity by my ISP, and is there something I can do about it?

Yes, your ISP is very clearly hijacking not only the DNS for google, but also DNS requests you try to send to outside DNS servers.

You are correct in your analysis that the traffic to Google is not leaving your ISPs network.  Your traceroutes also show that your DNS queries to Google Public DNS, as well as to Level 3's open resolvers, are not leaving your ISP's network.

Furthermore, the DNS A records returned all point to an IP inside your ISP's network, regardless of which DNS provider you query.  i.e., the A record provided is hijacked, as that is not the A record that Google themselves provides, but rather one that your ISP has provided in its place.

It would appear that your ISP is hijacking the actual DNS queries in order to prevent you from circumventing its hijacking of the DNS records.

No BGP tampering is required for them to do this. All they need to do (and likely all they are doing) is route all packets destined for UDP 53 to their own nameservers. A simple setting in their own router.