HTTP reverse shell through corporate proxy

How does the shell detects what is the proxy and its address?

It does it the same way as any other applications on your OS. On Windows an application can check registry settings for IE proxy, and get relevant proxy settings from other browsers. Or it can use Wininet API, which would handle proxies automatically (including things like NTLM authentication).

On Linux it can check the env variables such as "http_proxy".

A less typical, but still possible ways would be to do port scan (proxy typically listens on 3128 or 8080), or watch the traffic for proxy connection requests.

How does the reverse shell executes the commands?

There are several ways. For example, a reverse shell script/binary can do HTTP GET example.org/cmd.html, pass everything to a shell/powershell/Python, save the output of the executed shell to file, and POST it to example.org/output - those requests are valid HTTP requests, and will go through HTTP proxy. This will not work for interactive shell (for example using vi), but it is not really needed for an attack.

To build on top of that, the commands and responses could be encrypted with a symmetric key (thus making signature-based detections impossible), or could be embedded into regular traffic (for example into EXIF tag of an image).

However if the proxy supports HTTPS proxying through CONNECT command, it is much simpler. A reverse shell then issues CONNECT example.org:443 and has a direct TCP connection through the proxy, which could be used for a direct shell access (including the interactive shell).


Deep Packet Inspection SSL : How DPI appliances prevent certificates warnings?

These devices work as a man in the middle, that is the communication is no longer end-to-end. Because the SSL encryption is terminated at the DPI device and re-encrypted the client does not see any information of the original encryption, especially:

Ciphers and protocol versions might be different, that is the client does not notice if the original server used weak ciphers because the traffic between the client and the DPI solution is protected with a better cipher or protocol version. On the other hand it also allows a DPI solution to make sure that the connection to the server uses strong encryption no matter what the original client would do.
Certificate validation is done inside the DPI device and a new certificate will be created (signed by the DPI CA). This means the client will not see problems of the original certificate like a weak signature algorithm. On the other hand the client can not be tricked into accepting invalid certificates because the DPI device could enforce strong validation.

Unfortunately there were several cases in the past where DPI devices made the whole system less secure because the failed to properly validate certificates, used a common proxy CA between all devices of a single vendor or similar.

For more information about this topic I recommend to read the extensive article SSL/TLS Interception Proxies and Transitive Trust from 2012.


Disabled Network Discovery for port 5357 but it still shows up as open in NMap scan

Depending on your network configuration, requests may not be always answered by the host the request was sent to. For example, a firewall, router or switch may be configured to forward any traffic to TCP port 5357 to 203.0.113.1:5357.

As a result, when conducting a port scan for any host in this network, TCP port 5357 appears to be "open" for every host, but in reality, every request is answered just by one host.

In your scenario, it might very well be that port 5357 on one specific host (e.g. 203.0.113.29) is closed. nmap would still consider it as "open", because a request for 203.0.113.29:5357 would receive a response.

nmap is simply not able to tell whether or not the response came from the host or not.

How can I make sure this is what is happening?

You can use Wireshark or similar tools on 203.0.113.29 and see if packets sent to this host on this port actually arrive there. If they don't, but nmap still considers the port as open, then you are not communicating with this host.


Is it any more or less secure to delete all my cookies vs. individually logging out?

Logging out is supposed to expire the cookies/sessions, but that depends on the server-side coding.

If the cookies were stolen and you only deleted your cookies, then the stolen cookies might still be valid.

The choice of deleting vs logging out has more to do with what you are trying to defend against. Cookies contain more data than just the session info.

The best method is to do both: log out to end the session and then delete cookies to remove any potentially sensitive data.


In RSA there are three important components:

A public exponent
A private exponent
A common modulus (used both with the private and public keys)

So, then, the public key consists of the public exponent and the modulus, while the private key consists of the private exponent and modulus.

But the way things are typically implemented, the public exponent is almost always 0x10001 -- the same value for every key. So only the modulus is unique.

You can see, then, how swapping the private and public key would be problematic here. If everybody's secret was 0x10001, that wouldn't be very secret. So instead we keep the less-easily-predicted exponent secret, and call that one the private key.


Can I use GitHub and be PCI DSS compliant?

Note : not a QSA, but I do have some PCI experience.

There is nothing in PCI about storage of source code - there are requirements about change management, which github would help with, but nothing about where source code should be or any requirements to keep source code private (it allows use of open source, after all).  Given a private repo and assuming you do not store authentication information (keys, appids, passwords, api keys, certificates), PCI governed data or PII in GitHub repositories (which you shouldn't be doing anyways), you are probably fine using GitHub.  Talk to your QSA if you want to be sure.


The security measures which are the primary subject of your question here (MAC filtering, non-standard IP addressing) basically equate to "security through obscurity".  They are very weak against a dedicated attacker, and so should not be relied upon as the only security functions in your system.

That said, even security through obscurity has its place in a proper defense-in-depth approach.  Anything you can do to make it harder for an attacker to compromise your system, while not having too much impact on the usability of the system, may be considered worthwhile.

My own home setup uses all of the things you've mentioned, and then some:

MAC address filtering
Non-standard network ID (doesn't even end in .0)
Restricted (smaller than /24) subnet
Reserved DHCP addresses for all registered devices
WPA2 security on the Wi-Fi network
63-character random-generated PSK
WPS disabled on the APs

Those last three items, plus reasonably strong physical security on the house, are the real things keeping unauthorized users off my network from the LAN side.  As long as WPA2 remains fairly secure, nobody's going to be sniffing my traffic over the air let alone joining my network any time soon.  If there ever comes a time that WPA2 is broken, and a suitable replacement is not available, I'm fairly comfortable that any wireless attacker (unless they are deliberately targeting me personally, or specific data residing on my network) is likely to move on to another victim before they bother trying to get into my network.

The only real down-side to these extra security measures is that it can be a bit of a hassle to get new devices onto the network - especially smartphones and tablets.  For most people, adding a new device goes like this:

Select Wi-Fi network, enter PSK from memory, hit "connect".
(There is no step 2.)

For me, it goes something like this:

Log in to the router's configuration page
Figure out how to obtain the MAC address from the new device.  Add it to the MAC address filter on the router.  If there aren't any slots left in the filter (it seems Linksys routers are limited to 32), pick an idle device to remove from the filter to make room.
Pick an IP address to assign to the device, add it to the DHCP reservations on the router.  If no IPs are free, pick an idle IP to un-reserve and reassign.
If the new device is a laptop or desktop, plug in thumb drive, copy and paste PSK to the new system, click connect.  If it's a smartphone, tablet, or other limited-function device, load the text file with PSK on my laptop, enter the 63-character random PSK manually on the new device, and click connect.  Repeat this step until successful.

So, adding a new device can be tricky - occasionally to a problematic degree.  Fortunately, it's not something that happens often.  Other than this, the added security measures really have no impact on the usability of the network for authorized users.

What do all of these extra measures actually buy you?  Perhaps just a warm fuzzy feeling.  Is it worth it?  That's for you to decide.


How to design SIEM RFP, keeping in view large database requirements?

Looks like a good start from a db outward view by analyzing logs. You'll have the inevitable tradeoff of performance vs amount of logging so give actual numerical requirements in your RFP. You should also take into account the environment around the database. One example is validate the software that accesses the database had static scanning done to find sql injection vulnerabilities. Another is to make sure the SIEM is also monitoring the surrounding systems so events can be correlated. The SIEM should should also accept inputs from third party db security tools.

http://chuvakin.blogspot.com/2010/11/how-to-write-ok-siem-rfp.html recommends you don't write an rfp at all, and suggestions if you do have to. Ones I particularly liked was explain the mission (eg compliance vs risk management). Another is be specific - vague specs will just get unenforceable 'yes' answers.


How to connect to AP when attacker is deauth'ing my device?

Fighting interference is difficult. These frequency bands are unlicensed, which gives everyone the same right to use them (subject to regulatory rules regarding power limits, etc).

There are devices like WIPS (Wireless Intrusion Prevention Systems) which can help you. I think they could be expensive for a home use. Anyway, they are able to detect and prevent this kind of attacks. There are different DoS attacks. Yours seems like this one (but there are more):

802.11 Deauthenticate frames can be used to disconnect an individual station, or every station associated with a given AP. Sending a continuous stream of these forged frames is known as a Deauth Flood

Most WIPS can recognize these DoS attack signatures.

There is a wonderful article explaining all of this and from where I taken some info: How to prevent DoS attacks. Read it carefully.

If you can't get a WIPS, which is understandable, you can try to "fight" it configuring your AP with different ESSIDs on different channels as a workaround. I know is not the best solution but it works. You can do this only if your AP support multiSSID (or if you have more APS).

If you set up 4 different networks on different channels and you configure all of them on your devices, after being kicked from one, you'll connect automatically to other. The attacker needs to setup another different attack for the other channel, so he is not going to be success if he is not able to send 4 attacks at the same time, which usually requires 4 different wireless devices to perform the attacks.

All of this is assuming your DoS attack is bassed on death packets on which the attacker needs to set a channel on its monitor mode card to perform them. If you are suffering other kind of DoS attack, then this workaround maybe couldn't work. But the most common DoS attack is this "deauth framing" so maybe can work in your case.

Good luck!


Is a VPN still effective after a hacker has known my IP address?

Your IP address is something relatively easy to retrieve by different means. It's not a security problem if someone found yours. Your IP is just the address of your computer (or more likely your router).

Let's say that your computer is your house. The IP of your computer corresponds to the address of your house. You have to give the address of your house to access multiple services, there's nothing wrong with it. If you take care to lock your doors and close your windows, a burglar will have a hard time to get inside. It's the same with your computer, you have to keep it locked by frequently updating its software. In your house, you do not open your door to an unknown person, even more if this person wants to make you an offer too good to be true. It's the same with your computer: don't read e-mails you do not expect (especially their attachments, they could be trapped) and use an ad-blocker.

Using a VPN will just give you a false sense of security. That will not significantly improve your resistance to a hacker determined to harm you. That will not protect you against random threats (such as viruses or phishing attacks). Using a VPN is like telling people you're named John Doe: you will appear suspect and this will not stop a burglar to pay a visit to your house.


What is the most secure way for two people to communicate?

Before looking at specific technological solutions, you need to do some thinking about your threat model. Who is the "enemy"? What do they want, and what resources do they have?

For example, keeping the content of the communications secret is one thing, hiding the fact that you are communicating is another, verifying the identity of the other person is yet a third.

And keeping secrets from your mom is one thing, keeping secrets from the Politburo Standing Committee of the Communist Party of China is another.

You also need to understand your resources. Can you establish a short-term secure channel to the other party (so you can exchange keys)? Can you use cut-outs? Can you arrange to use a different computer each time you communicate?


How do ISPs send their own pages when a user is trying to access a blocked site?

ISPs cannot inject their own pages into HTTPS traffic. They can block the traffic and cause the page to fail to load, or they can attempt to hijack a HTTP->HTTPS redirect before the encrypted connection is made, but they cannot modify the contents of the page itself once the connection is established. The only way for them to do this would be if you had installed a root certificate made by them, effectively telling your browser to trust your ISP act as a Certificate Authority for arbitrary websites (a bad idea).


What makes an Android application vulnerable to Cross-site scripting (XSS)?

The specific example is not Cross Site Scripting, it is Cross App Scripting. With a specially crafted intent, an Android app could force another app (Chrome in this example) to execute some script in its (Chrome's) context.

This could abuse some privacy and authentication mechanisms. If I am not missing something, this vulnerability (fixed in Chrome quite a while ago) allowed a malicious app to hijack an opened web session with the user's bank and approve money transfer.

This is a bit of exaggeration, normal banking Web sites are protected from such attacks: they require user confirmation (i.e. re-enter password) to complete any sensitive operation.

The problem with Chrome was that it allowed a 3rd party app to impersonate itself via intent extra, and did not perform enough validation. This was not a security hole in the Android OS, and not an exploit that could be statistically used against random apps on your device, to find one that was not protected.


What influences the speed of rendered php page using encryption

If I am to believe the documentation (a bold notion indeed), the openssl_private_decrypt() function does symmetric decryption with RSA, using OpenSSL (the library) for the actual cryptographic work. On your VPS, you can run the following command to benchmark OpenSSL:

openssl speed rsa

This will give you the speed of RSA private and public key operations on your machine. On mine, I get 833.7 private key operations per second for a 2048-bit key; 15 successive calls would hardly be noticeable. However, your VPS might be
considerably feebler than my 3.1 GHz E3 Xeon. Also, you might have used an oversized private key (computation time is mostly cubic in the key size). If the benchmark shows that the RSA decryption speed is indeed the problem, then you may do the following:

Use a smaller key. The normal RSA key size is 2048 bits; there is no need to go beyond that (2048 bits are enough for security for, at least, the 30 next years). 1024 bits are no longer recommended, though this is not breakable yet (it can plausibly be done with existing technology, but it will entail building a quite expensive dedicated machine). If you are short on CPU power, you might want to try a middle-ground, e.g. a 1536-bit key. Do NOT go below 1024 bits.
Add a bigger CPU. RAM is not relevant. Having more CPU helps only for parallel processing, i.e. several users accessing the server simultaneously.
Do something else. You do not describe your usage context, but chances are that if you need to do 15 RSA decryption on a single page, then you are doing something wrong. For instance, I surmise that you may have noticed that RSA encryption works only up to a limited size (117 bytes for a 1024-bit RSA key), and that you might have decided to encrypt a longer message by splitting it into 117-byte long blocks and applying RSA on each of them separately. This path leads to suffering. Don't do that. Do hybrid encryption (but if I have to tell you that, then you don't know enough to do anything secure yet).

(Every time I look at what PHP does with crypto it fills me with dread, disgust, and a sense of impending doom. People who can design a function called openssl_public_decrypt() for "decrypting data with the public key" are people who apparently heard before 1993 but did not bother to check whether science had somehow progressed in the last 20 years. Are you sure you want to use such tools for anything which requires actual security ?)


Keycloak's Angular quickstart : XSS vulnerable?

First of all, yes, an XSS vulnerability will allow an attacker to access the bearer token in the authentication header. But this alone isn't the full story.

Your decision, if you want to transfer the bearer token as authentication header or as cookie, is based on multiple factors:

How large is your token? Cookies are limited to 4kb. If you transfer many and/or large claims in your token, this space might not be enough. In such a case, the authorization header is the logical alternative.
Are you protected against CSRF? When you transfer your authentication tokens as cookies, you open yourself up to potential CSRF attacks. If you go this route, you must be even more careful to verify your application's resilience against CSRF.
Why do you fear that your bearer token is stolen via XSS? May sound like a stupid question, but it is highly relevant. Your application has a sever issue, if you are vulnerable to XSS, period. Stealing your bearer tokens is only the tip of the iceberg. Yes, adding the http-only flag to your sensitive cookies is a second line of defense, but your first priority must be ensuring that you do not have an XSS vulnerability in the first place. Putting your bearer token in a http-only cookie is no excuse for a lack in protection against XSS.

In summary it can be said, that both options (cookie and authentication header) are accepted methods and both have their benefits and drawbacks. Which one is the better choice, depends on the surrounding factors.


Building an VM with Vagrant and connecting with ssh+2FA to protect a bitcoin wallet?

Authentication is about making sure that the peer (say, a connecting client) is who they claim to be; this is the normal first step which enables authorization, i.e. the process of deciding whether the access ought to be granted or not. The important point is that such a thing makes sense only when there is a system which acts as gatekeeper for an important service, e.g. the system contains sensitive data.

A VM image, that the attacker might possibly steal a copy of, is not such a system. By definition, an attacker who steals an image of a VM can inspect it at will, booting it up, seeing its file, reading its memory, and so on. To make an analogy, imagine the VM as a city; the SSH and 2FA and whatsnot is a big fortified wall encircling the city, with sturdy doors and dozens of guards armed with swords and pikes; they will grant access only to people who know the passcode and are vouched for by a citizen. For the attacker, stealing the VM is like having some choppers and landing a few platoons of marines on the city central plaza; the efficiency of the wall and the guards against such a scenario is, at best, questionable.

So yeah, against an attacker who can read all the stored data (that's what happens with a stolen VM image) you need confidentiality, and that calls for encryption. You can actually forget this VM business and SSH; for the security you want, it totally misses the point.


If you are using VeraCrypt to protect the partition that your Windows installation is on then an attacker would have to overcome that encryption before they could try to get your EFS private key.  If you're using a strong password for VeraCrypt that possibility should be low.

However, if an attacker gets through VeraCrypt and gains access to your unencrypted Windows partition then they could attempt to crack your account login password.  Once they do that they can log into your account and have access to your EFS private key and thereby all your EFS protected files.  There may be other ways to extract your private key, but this seems to be the easiest route.

Edit: removed claim that admin changing user password would allow access to private key.  See comments below.


How secure are the passwords stored at Google Passwords?

Based on the information which I've found on-line so far, the following statements are true:

Passwords are always encrypted source.
Chrome uses your Google Account to encrypt your synced passwords source.
Whether or not you use a passphrase, your synced data is protected by encryption in transit.
Your Chrome sync passphrase is stored on your computer and will never be sent to Google.

You can decide to encrypt all synced password with a separate sync passphrase instead. If so, you can use Google's cloud to store and sync your data without letting Google read it.

Related:

How secure is Chrome storing a password?
Is saving passwords in Chrome as safe as using LastPass if you leave it signed in?


Benefits of identifying clients based upon the "X-Forwarded-For" or similar HTTP header in addition to Client IP

Any of those HTTP headers can be used for access-control purposes, however I would not rely on either the presence of those headers, or the validity of their data.

The most I would ever use them for is logging.  There are no guarantees that any of those headers will be present, or even if they are, that they will contain valid data.  I know there are X-Forwarded-For spoof plugins for Firefox, and probably for other browsers, too.  This makes the information useful only at a statistical level - trending, pattern analysis, etc, there can definitely be some value in collecting and logging those headers. Just don't do any thing that relies on them

Any sort of reliance on HTTP headers for any kind of authentication or access control would have to be classified as worst-practice behavior.

There are much better ways to control access and authentication.


What you want is format-preserving encryption. There is unfortunately no ready-to-use standard for that, but some reasonable constructions are known. I would recommend the Thorp shuffle which is an extremely unbalanced Feistel scheme; given enough rounds, this can implement a permutation which is close to the optimal (except that a Feistel scheme is necessarily an even permutation).

Be aware that implementing your own cryptographic algorithm is fraught with perils. If you are not comfortable with the article quoted above, find someone else who is. (Fortunately, in your specific scenario, if you use a weak cipher the penalty is limited: attackers may guess the number of records or predict the next primary key value.)


Should I worry if my credit card payment processor's server allows only weak SSL cipher suites?

Of course you should worry. If the credit card payment processor is not able to fix well known and obvious security problems (A few days ago RC4 got explicitly prohibited for use with TLS by the IETF) which are even visible world-wide from outside, how will be the status of their internal security? Note, that it might be not that bad to offer RC4 for compatibility with older clients (see the other answer about PCI requirements), but in this case it offers only RC4 to all clients.

Not only you should think in this way but attackers will also think this way and will check the providers server and infrastructure for less obvious but maybe even more serious security problems. And they will probably find them, it would not be a first. This in effect can put your customers and also business at risk too.


ISO/IEC 27005:2011 is the ISO standard providing guidelines for risk management and contains a lot of advice for the assessment part of that process. A ridiculously abbreviated summary might be:

Identify the risk by:

identifying your assets
identifying the threats to each asset
identifying the existing controls protecting each asset
identifying the vulnerabilites in each asset that the threats might exploit
identifying the consequences of harm to each asset

Analyse the risks by:

determining likelihood of harm (i.e. loss of Confidentiality, Integrity, or Availability)
determining the impact of harm
combining those values to assign a level of risk

Evaluate the risk by comparing the level to your acceptable risk threshold

You would usually do the identification step by taking inventory of your assets and interviewing their owners and maintainers about them.

The analysis stage is usually qualitative and fairly simple. For example, you might assign values of Low, Medium, or High to both likelihood and impact of each risk, then have a simple table showing the consequent risk value. High likelihood and high impact means a high risk, and so on. This seems rather simplistic, but it's very hard to give precise quantitative values to likelihood and impact across all your risks. What's the likelihood that my office will burn down next week? Spock might estimate the probability as 2.457% but I'm human, so the best I can do is estimate it is "Very Low". Your circumstances may be different, of course.

Finally the evaluation stage is simply comparing the level of risk to what you find acceptable, to see if the risk needs treatment. Again, it's a little simplistic, but the reason you're doing analysis is to determine a) what risks you need to treat and b) what order to do them in.


Can a bad guy be judged for gaining access to sensitive information?

The bit that's going to bite you is going to be the following:

If the attacker can be pinned down, and you end up going to court, do you have all the requisite "court tested" components in place.

For instance, are your logs stored in an malleable medium?  For each transfer of those logs were they checksummed with the minimum checksum required by law?  Do you have a clear chain-of-custody for that evidence up until the point you turned it over to the authorities? And ultimately the most important part, will the authorities consider the case?

If not and the above pre-requisites are met, you might be able to prosecute them civilly if they are within the court's jurisdiction.  I am not a lawyer, and not a native of your country for what it's worth.


What are the 'P' values in some cipher string?

P521 is an elliptic curve

“P521” is a dead giveaway for an elliptic curve which SECG and TLS formally call secp521r1 and which NIST FIPS 186-4 calls P-521. An elliptic curve is a mathematical domain used by elliptic curve algorithm such as ECDH and ECDSA.

Curves are generally known by a name that includes some information about the type of curve and the key size¹. The letters “sec” stand for SECG (Standards for Efficient Cryptography Group), and the specifically for the curves described in SEC2. The following P is because the curve is over a prime field (a finite field whose number of elements is prime). 521 is the bit size associated with the curve. The R indicates that certain parameters of the curve were generated at random, and the final 1 is because this is the first (and so far only) secp521r curve.

Curve parameters are typically chosen in such a way as to make calculations faster, given mathematical constraints to ensure that the parameters have the required security properties. In particular, it helps if the size of the field differs from a power of 2 by as few bits as possible, because that allows fast modulo reduction. It happens that 2521-1 is prime. There's no prime that's nearly as nice and has 512 bits or a little less.

In terms of sizes, today, 256 bits is considered enough for elliptic curves for ephemeral key exchange (ECDH) and signature (ECDSA). As usual, larger sizes give more resistance (but being more resistant that “unbreakable in practice” isn't a practical benefit) at the cost of less performance.

Elliptic curves and TLS cipher suites

A TLS cipher suite is a set of parameters that describe how the TLS protocol sets up the keys that are used for the communication. See How does SSL/TLS work? for more information. For example, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 means to perform a key exchange using elliptic-curve Diffie-Hellman (ECDH) with single-use (E for ephemeral keys), verifying the server's signature with RSA, and using AES-128-CBC to encrypt the secure channel and HMAC-SHA-256 to authenticate it. The client and the server negotiate which cipher suite to use at the beginning of the TLS connection (the client sends the list of cipher suites that it supports, and the server picks one and lets the client know which one). The choice of elliptic curve for ECDH is not part of the cipher suite encoding. The curve is negotiated separately (here too, the client proposes and the server decides).

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 is not a thing that's different from TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. It means to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 with secp521r1 for the ECDHE part.

Most TLS server software allows the administrator to configure which security parameters it's willing to support. Sometimes this is done independently for each piece (which key exchange types, which key agreement algorithms, which hashes for signature, which elliptic curves, which hashes for HMAC, which symmetric ciphers, which AEAD algorithms, …). Here you select which elliptic curve to support separately for each cipher suite. The choice of which parameters to configure together is a matter of convenience vs flexibility.

¹  More precisely, it's the size in bits of the coordinates of points on the curve. But for all common curves, that's also the size in bits of the private key.


How to scan 20k hosts to check if they're up?

There are tools made for large-scale scanning that have implemented optimizations exactly for solving this problem. One of the best known and most developed options is masscan. It can reach speeds of 10 MPPS (Million Packets per Second) and can scan the entire IPv4 internet in ~6 minutes. It even has flags that let you benchmark on your local network without spamming the whole internet.  Masscan has optimizations that don't require your OS to maintain full TCP/IP connections just to see which hosts are responding.


No to both. Details:

PGP encrypts a random symmetric key with Bob's public key, and then uses that to encrypt the message. Since you don't have that key, you can't check to see if the plaintext and ciphertext correspond under it.
The public key of a message only reveals who can decrypt it. All you learn is that whoever encrypted it knew Bob's public key, which doesn't really narrow it down at all.


Exchange Autodiscover XML question (Exploit related)

It's likly exchange is just getting the wrong config/setup wrong you can FORCE the correct settings this way without local administrator

This is how I setup autodiscover

the xml file is placed on your local disk some place and edit the path to your exchange XML server RedirectUrl

autodiscover.xml

<?xml version="1.0" encoding="utf-8" ?>

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">

<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">

<Account>

<AccountType>e-mail</AccountType>

<Action>redirectUrl</Action>

<RedirectUrl>https://mail.COMPANY.com/autodiscover/autodiscover.xml</RedirectUrl>

</Account>

</Response>
</Autodiscover>

the reg patch is just modified to reflect the path to the XML file above

autodiscover.reg

REGEDIT4

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\outlook\Autodiscover]
"COMPANY.com"="H:\\COMPANY\\Outlook\\autodiscover.xml"

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\outlook\Autodiscover]
"COMPANY.com"="H:\\COMPANY\\Outlook\\autodiscover.xml"

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\outlook\Autodiscover]
"COMPANY.com"="H:\\COMPANY\\Outlook\\autodiscover.xml"

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\outlook\Autodiscover]
"COMPANY.com"="H:\\COMPANY\\Outlook\\autodiscover.xml"

restart outlook profit


Security Implications of Caching Randomness

Assuming you have plenty of good, random bits, the pitfalls associated with caching randomness all stem from the potential for malicious access. That is, there isn't anything inherently wrong with caching randomness, however it creates a larger attack surface. If the developers have reason enough to believe that the memory is a safe storage location then this approach is safe.
One way of thinking about this is looking back at the historical use of the one time pad (OTP). OTP was used by militaries to encrypt and decrypt messages and is still considered unbreakable to this day. The codes in this case were stored on paper (analogous to your cache). However, the rules required for this process to be unbreakable include:

The key must be truly random.
The key must be at least as long as the plaintext.
The key must never be reused in whole or in part
The key must be kept completely secret.

As long as you can guarantee the same for your cached random bytes, then the randomness is fine.


There must be string manipulation routines or sth in mysql. Then you simply do a

union select substring(group_concat(table_name),1,10) from information_schema.tables#

or something like that and then you execute the query for each slice...


Is encrypting and subsequently sending a known clearext string after a Diffie-Hellman bad design?

Designing your own protocol for something secure is generally a bad idea.  Don't roll your own.

It's probably not a significant weakness.  It does expose yourself to a known-plaintext attack, but luckily AES is secure against known-plaintext attacks.

Granted, using a CRC to test that communication is working properly is not a good idea (unless this is only done at a network layer on the sent ciphertext), as CRCs aren't cryptographically secure.  You really should use a keyed-MAC to prevent tampering (and sequence numbers/timestamps to prevent replay attacks).


How to mitigate evil twin WIFI social engineering attack?

As with any social engineering attack, one of the best ways to mitigate it is through training and communication. Explain the problems to users and nurture in them an attitude of cautious skepticism towards ANY unannounced changes in the way your systems operate.

The ideal default user behavior should be, "Hmmm, that login page looks different. I don't remember a notification that said this was changing. I am going to ask support/management about this before using it."

This is an idealistic description; reality will always be harder and require layers of security controls.


How does HSBC's "Secure Key" actually work?

There are two standard ways to build such a device:

Time-based.  The device has a secret key K (known only to the device and to your bank).  When you press the button, The device computes F(K, T) (where T is the current time) and outputs it as a 6-digit code.

Your bank, which also knows K, can compute the same function.  To deal with the fact that the clocks might not be perfectly synchronized, the bank will compute a range of values and test whether the 6-digit code you provide falls anywhere in that range.  In other words, the bank might compute F(K, T-2), F(K, T-1), F(K, T), F(K, T+1), F(K, T+2), and if the code  you provide matches any of those 5 values, the bank accepts your login.

I suspect this is not how your device works, since your device always gives you a different value every time you press the button.
Sequence-based. The device has a secret key K (known only to the device and to your bank).  It also contains a counter C, which counts how many times you have pressed the button so far.  C is stored in non-volatile memory on your device.  When you press the button, the device increments C, computes F(K, C), and outputs it as a 6-digit code.  This ensures that you get a different code every time.

The bank also tracks the current value of the counter for your device, and uses this to recognize whether the 6-digit code you provided is valid.  Often, the bank will test a window of values.  For instance, if the last counter value it saw was C, then the bank might compute F(K, C+1), F(K, C+2), F(K, C+3), F(K, C+4) and accept your 6-digit code if it matches any of those four possibilities.  This helps ensure that if you press the button once and then don't send it to the bank, you can still log on (you aren't locked out forevermore).  In some schemes, if there is a gap in codes (e.g., because you pressed the button a few times and then didn't send the code to the bank), you will need to enter two consecutive valid codes before the bank will log you on.

Based upon what you've told us, I would hypothesize that your device is probably using the sequence-based approach.


How a spoofing email site such as emkei works

The spoofer will try to scan every ports of a smtp server to catch the mx

The MX is detected by doing a DNS lookup and the MTA is then using port 25 on the server(s) returned by this DNS lookup. No port scanning is involved.

  However, as it is explained in this post (Spoofing email From address), it is not that easy.

This post shows several ways, some easier and some harder. And it shows that the easiest way is to just find out the MX for the recipient domain (DNS lookup) and connect with your SMTP client (or telnet) to this domain - the same way as a SMTP MTA would do when delivering a non-spoofed mail to this domain. There might be problems if the acclaimed sender domain uses SPF or DKIM and the recipients SMTP server checks for this - but most domains still don't use such protection and many servers don't check for this.


Roommate Frequently Hacked -- How Do I Protect My Network/Devices?

You can use DNSCrypt to protect against DNS poisoning, HTTPS Everywhere in case you forget. Maybe install Tunnelblick and setup a secured OpenVPN server on a remote machine/network you know is likely to be healthier. Good luck.


Why change a salt when the password changes?

From a coding perspective it's actually harder and less efficient to get the existing salt and re-use it than it is to just generate a new one.  Using the old salt requires a round trip to the database or file, and requires extra complexity and code maintenance over simply creating an entirely new salt+username combo, which you have to have code for when the first password is set.

In other words, it's easier, faster, and safer to just use the same code you already have that creates a new salt, so why do anything else?  From a security perspective, less code to maintain is more secure.


How to establish a secure channel with authenticated and authorized access to a remote entity

You need to ensure the following items for the approach to work:

There needs to be a way to ensure that the tokens can't be replayed even if by just A.
There needs to be a way for Y to invalidate the tokens. Otherwise A's token will provide them with access even after Y has revoked it.

Also, Is it necessary for the tokens to be only decrypted by X? What if the tokens are just signed by Y and X can read them. This will make the design easier while ensuring that nobody other than Y generates the token.


How could an hard-token be packaged such that the recipient could trust it?

Tokens are built to be tamper resistant so that you can't just open it up and mess with the circuitry and inner components.

The pin for the tokens are also delivered via another channel(Either the token or the pin is handed in person by the bank, RA or the institute that's responsible for the tokens) so that an attacker can't access both the pin and the hardware token.

Also the key used to generate OTPs "can be" based on the entered pin so with a wrong pin you'd get invalid passwords generated, so without having the right pin a guy getting access to the hardware token cannot do much(he will have access to a part of the key that's used to generate one time passwords).


What happens when a spoofed source IP packet is dispatched out of a private network with NATing

There are three likely behaviors as the packet is sent from the LAN to the router:

The router apply reverse route filtering and drop the packet.
The router does not filter. Instead the router treat it like any other packet from the LAN, which means the source IP is replaced with the IP of the router, and the router create a connection tracking entry.
The router does not apply filtering or NAT. Instead the router forward the packet with spoofed source address.

In the first case, nothing more happens. In the third case, the packet may be dropped or forwarded by the ISP. In one of these cases the spoofed packet makes it all the way to the target. But no reply will be coming back to this router, because it would go to the spoofed IP.

The most interesting case is the one where NAT is applied to the packet. The ISP will no longer be able to drop the packet based on the source IP, because in this case the source IP is in fact valid as far as the ISP is concerned. But this is not very harmful because the packets can be easily filtered based on source IP once they reach the destination (assuming the flood is large enough to be noticeable at the destination). It also cannot easily be abused in a reflection attack, because the replies go back to the NAT router.

What happens to any replies coming back to the NAT router is more interesting. They will match a connection tracking entry. But after the NAT has been applied, the destination address will not be inside the LAN, but externally. At this point there are a few possible outcomes:

The router may refuse to forward the packet because it would be send back on the interface from whence it came.
The router may forward the packet back on the outside network as soon as it has applied NAT according to the connection tracking entry.
The router may attempt to perform NAT on the packet again, because it would be leaving on the external interface.

The first case where the packet is dropped, is not particular interesting or harmful.

The second case where the packet is forwarded back on the external network is more interesting. This is the case where the NAT prevented any spoofing from taking place in the first place, but a side effect of this is that on processing the reply, it actually produces a packet with spoofed source IP (effectively the source and destination IP of the original packet has been reversed).

If the ISP does not filter the packet due to invalid source IP, the return traffic will then be forwarded to the IP which was spoofed in the first place. And on arrival will look pretty much the same as it would, if no NAT had taken place at all.

But since this involves three trips across the external connection of the attacking network, the rate of attack traffic is limited compared to what it could have been.

If the router tries to NAT again, stuff gets a bit interesting. The issue here is that it isn't the first packet of a flow, so the NAT layer may not know how to deal with it. So the packet may be dropped because of NAT being applied without having seen the first packet of the flow.

It is also possible that a connection tracking entry is created. Since that newly created connection tracking entry was obviously not applied to the first packet of the flow, there is no way this could work at all for a TCP connection. But other protocols could possibly work even in such a scenario. However since this particular packet is due to spoofing, nothing good will come from NATing it.

If we assume this was a TCP SYN-ACK packet, and the router does NAT it again in spite of not making any sense at all, then the SYN-ACK will be forwarded by the ISP. The SYN-ACK will trigger a RST response (assuming the destination is functional), the RST will then go back through both connection tracking entries and get forwarded to the host from where the SYN-ACK came and clean up the connection.

As you can see, there is lots of ifs in this flow. And there is likely some possible outcome, which I have not considered.


Are There Reasons to Sign Files Transported via TLS?

TLS ensures integrity of data while in transport. If the file was "generated" by the server without the need for any external input data (e.g., Adobe PDF files can be "generated" on the fly, by combining document templates with other data / metadata), and the server is your "final authority" on the matter, and you've deployed defenses against SSL/TLS MITMs, then you probably don't need any further digital signatures.

If you consider other scenarios such as these below, you would need proper digital signatures signed at each point in the document (or file)'s lifecycle where you need to ensure integrity:

The origin of the file is not the server itself but another user - who stored / uploaded it into the server? In this case, would you like to be sure that the file is "as it was originally sent by the first user?" or even "as it was originally created by its author?".
The file was generated from external input. e.g., a document from a document store where it was stored after due process (e.g., a registered document) with or without additional annotations. In this case, even though the file was generated by the server, the original data may need integrity guarantees embedded in the document. It is possible to do this by signing just the underlying data - not necessarily the file itself.
If it is a device to device communication and there are no other external factors - even then, typically you will have components that originate the data -> some 3rd party components -> transport (usually a 3rd party component) -> recipient with similar stack in reverse. Now your originating and receiving components may or may not want to trust what happens in between (including the possibility of SSL/TLS MITMs) - and hence want "end to end" integrity guarantees; not just transport integrity.

Conclusion: Do you trust every single component between your originating component and your receiving component? If you do, then you're fine. If not, you want to sign the data/file when it's leaving your control and make sure you got it without changes when it reaches your control at the destination.

PS:
Points 1 & 2 came up when we were designing the MCA21 system for company registration & annual returns filing (www.mca.gov.in).
Point 3 came up in a startup where we were designing a large network of firewalls coordinating their defense.


This system allows people to sell their votes.

Take the envelope and show it to the vote buyer, who now knows the voter's three numbers.
Vote.
The vote buyer can now check how you voted by checking each of the three numbers.
If you voted as the buyer wants, you get paid.

The flaw here is that it assumes that the voter wants to keep the voter's identity private.  But in a vote selling situation, that is not true.  The voter wants to let the buyer see the voter's vote.

The typical approach to avoid this with online verification is to arrange things so that the voter can change from the original plan and vote different numbers.  However, that is still subject to the problem that the vote buyer can usually detect the different numbers.  Because when the buyer checks the agreed combination, there's no vote there with the desired ballot.  But with your system, it's not even that difficult.  Each number is unique and only one of the three would count.  So a buyer can easily check all three.


What are the privileges of shell spawn by a shellcode?

Well, what to say except that you are fully right?

The spawn shell will have the exact same privileges as the process from which it is spawned, no more, but no less either. All the interest is here: the greater privileges the vulnerable application has, the greater privileges your spawned shell will have.

However, once you have a shell running on the machine, nothing prevents you from trying to run local privilege escalation exploits. But this will be done at a second step:

First step: spawn a shell which will have the same privilege as the end-user or the web-server running the vulnerable software,
Then, as a second step and if you need to (you do not necessarily have to increase your privileges, it all depends what your final goal is), you will try to use other exploits in order to increase your current privileges. The main difference is that, having an interactive shell running on the machine, you will now be able to take advantage of local exploits instead of being limited to remote ones as in the first step.


Is it dangerous to use default router admin passwords if only trusted users are allowed on the network?

As you correctly noticed CSRF attacks are a possibility. Prevention of CSRF attacks is possible with a CSRF token, but this is nothing you can do as the user of the router. So if you are a router vendor you should definitely implement CSRF protection but as a user you have to live with what the vendor offers you and many vendors don't have proper CSRF protection.

Beyond CSRF there are other attacks which can be used against the router. Similarly to CSRF, many of these use the browser as the trampoline, i.e. just require a visit to some web site which has exploits embedded (like embedded in advertisements) and don't need a compromise of the user's computer. Noticeable among these are cross site scripting (XSS) and DNS rebinding attacks. Here again the vendor could implement proper protection in theory, but in practice it is often not done.

And then even trusted users might have their system compromised through a variety of ways. In this case the attacker is inside the trusted network and knowledge of default passwords makes it a lot easier to hijack the router and make the attacker's control over the network more permanent and less obvious this way.

This means even if you think you have proper protection, you should change the password away from the default in the spirit of defense in depth. The more unknowns an attacker has to find out to infiltrate the network, the harder you make it for him, and the better you secure your network. And of course this also applies not only to the password but general router security, i.e. some routers have bugs or even backdoors where you don't even have to know the user's password for a takeover. And it's not only routers but you also have to watch out for other devices like printers, scanners, smart light bulbs, TV etc.


Session Fixation - Setting path to root without /

Your content is going into an HTML attribute, encoded in a URL. That gives you two possible forms of encoding:

URL-encoding: %2F. Although this should in principle work, both IIS and Apache block the use of URL-encoded slashes due to some past security issues.
HTML-encoding: &#47;, or rather as it is itself in a URL, %26%2347%3B.

(Although... since you appear to have an injection into HTML attribute, is there any reason not to go straight for the more-damaging and better-supported %22%3E%3Cscript%3E...?)


I don't quite understand the principle of "use after free" and CVE-2010-1119

This is a very complex question, and I'm not sure where you stand technically.  I'll lay out some background to help you get to the point.

Basic refresher

A computer has a couple of important parts: a Central Processing Unit (CPU) and Random Access Memory (RAM).  Essentially, a CPU reads a few bytes of memory from RAM, performs the instruction they contain, modifies some data, reads a few more bytes, performs the next instruction, and so on.  Most all modern computers work on this basic principle.

RAM is simply a chip with a lot of bytes of storage.  The RAM chips in a typical PC might have 2 billion bytes (2GB).  And each byte of that RAM has an "address", which is just a number that lets the CPU access that specific byte.  The computer can store either data or program instructions in a byte, then come back later and read them.  A computer can also store a value in one set of bytes that contains the address of a different set of bytes - this is called a pointer.

Of course, your desktop computer is a lot more complex than just one program.  It loads many programs into different sections of RAM, and the CPU rapidly switches between all of them to do your tasks.  One main program the computer runs is called the Operating System (OS) - Windows, iOS, Android, Linux.  One job of the OS is to allow these programs to share the CPU without letting them crash into each other.  The computer has only a limited amount of RAM that has to be shared by all the running programs.  So instead of using any piece of RAM, each program must ask for RAM from the OS.  The OS assigns an area of RAM for the program, and the program can do what it needs with it.  But if it tries to access RAM that is not assigned to it, or tries to violate the privileges assigned to it, the OS will terminate the program.

But the OS handing out memory is kind of slow.  Inside a program, a memory manager is responsible for the same task.  When a program needs memory for a small task, like creating a window, the program's memory manager keeps track of RAM addresses that are assigned, and which are free.  It keeps them in a table of pointers.

Object Oriented programming

Objects are a way for a programmer to logically group data and instructions for working with that data.  Objects can represent anything the programmer needs, such as a Window or a Button or a Customer or a Link.  A Window object might store an X and Y coordinate on the screen, maybe have some scroll bars, plus a "Draw()" method for painting the contents when the window becomes visible.  A Button object might have an X and Y and height and width dimensions, text for a label, and a Draw() method for painting itself on a screen.

Within an object oriented program, a program will create and destroy thousands or even  millions of objects continually while it runs.  Creating an object uses a command called "new", which is simply asking for an area of RAM to be assigned to that object.  The memory manager returns a pointer to the address of the RAM allocated to the object, and the program keeps this pointer associated with the object.  When the program is done with the object, it calls "delete" to get rid of it.  The memory manager then marks that RAM as freed-up, and will be able to assign that RAM to some other object request.

Some languages like Java and .Net run in a special runtime environment that automates the task of freeing memory after the objects are deleted.  This automated task is called garbage collection.  In other languages, like C and C++, the programmer is responsible for some memory management.  And sometimes, the programmers make subtle mistakes.

The setup

When a program creates an object with new, the object name is associated with a pointer to the address in RAM assigned to contain the object's methods and data.  The program can make a copy of that address, too, so that other objects can refer to that object.  An example might be a Window object containing pointers to Button and Hyperlink objects.  Perhaps the Button has a Hyperlink associated with it.  So the Window may have a pointer to the Button, and the Button has a pointer to the Hyperlink. Meanwhile, the memory manager's table looks like this:

RAM Addresses:
1000-2000 assigned to MyWindow
2000-3000 assigned to MyButton
5000-8000 assigned to MyHyperlink

The code might look like this:

MyWindow::Draw()
{
    ...draws frame and scrollbars here...;
    MyButton->Draw();  // Calls address 2000 to tell the button to draw itself.
}

MyButton::Draw()
{
    ...draws button and colors it in here...;
    MyHyperlink->Draw(); // Calls address 5000 to tell the hyperlink to draw itself.
}

The bug

What if the Window object deletes the Hyperlink object, but doesn't tell the Button object?  The Button still has a pointer to the Hyperlink's old memory address, but the memory manager has been told to delete the Hyperlink, and to free that memory up so it is available to some other object.

MyWindow::DeleteLinks()
{
    delete MyHyperlink;  // Frees the RAM from address 5000-8000.
    Draw();              // Calls MyWindow::Draw to repaint the screen.  Inside
                         // Draw, it uses MyButton's address of 2000 to tell
                         // the button to draw itself.  And inside
                         // MyButton::Draw(), it will still call MyHyperlink->Draw()
                         // at address 5000, even though we just freed it!
}

Surprisingly, this usually works long enough to pass a test!  When the memory manager is told to delete the MyHyperlink, it simply marks the space available, like this:

RAM Addresses:
1000-2000 assigned to MyWindow
2000-3000 assigned to MyButton
5000-8000 is free

But the bytes still hold their old values from when it was a Hyperlink.  When MyButton->Draw() is called, the old MyHyperlink-Draw() function is still in RAM at address 5000.  So the testers don't see any bugs, and the product goes to market.  There is now a "use-after-free" vulnerability in this program.

The crash

Let's say there's a web page that makes the program create a button with a hyperlink, then destroys just the link, then creates a new Image object.  The memory manager allocates the new Image in memory marked as free, which now includes the address space where the Hyperlink used to be.  The Button's pointer to the Hyperlink is still pointing at 5000, which it thinks is still a valid Hyperlink.  But when the Button uses the pointer to call the Hyperlink, it's instead incorrectly calling bytes stored in the RAM that used to be a hyperlink, but are now in the middle of image data.

RAM Addresses:
1000-2000 assigned to MyWindow
2000-3000 assigned to MyButton
3000-10000 assigned to MyImage, but MyButton still thinks that 5000 is MyHyperlink.

The program crashes, because address 5000 points squarely into the middle of a picture of puppies.

The exploit

A hacker notices this crash, and decides to exploit it.  He places instructions in a specially built picture file so that when the picture is loaded, and MyButton->Draw() is called, it will execute the instructions contained at byte 2000 of his image.  His image contains specially crafted code at 2000 (usually something like a NOP slide) that will divert the instruction pointer to his malware stored elsewhere in the picture that was downloaded.  Once that code executes, he owns that computer.

The first thing a hacker generally tries to do once his code is executing is to exploit a second vulnerability in the operating system to try elevate its privileges.  That way it can then download more sophisticated malware files, and write changes to files on the disk so that the next time the computer boots, it runs again.  It could hide itself using a rootkit.   It could run a bot client, or a keylogger.  It could send spam.  It could launch DDoS attacks.  It could install Cryptolocker and blackmail the owner.


Which SPF quantifier applies when an SPF include is used?

With the include mechanism the "included" SPF statement is not literally included in the original one but only the result of it is used. From section 5.2 of RFC 7208:

  In hindsight, the name "include" was poorly chosen.  Only the
     evaluated result of the referenced SPF record is used, rather than
     literally including the mechanisms of the referenced record in the
     first.  For example, evaluating a "-all" directive in the referenced
     record does not terminate the overall processing and does not
     necessarily result in an overall "fail".

This means, that the result of the "included" SPF statement is treated as a match, not match or permerror similar to every other SPF statement.
The standard even explicitly contains a table how the result of the "included" SPF statement affects the main statement:

+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism  |
| of:                             | to:                             |
+---------------------------------+---------------------------------+
| pass                            | match                           |
|                                 |                                 |
| fail                            | not match                       |
|                                 |                                 |
| softfail                        | not match                       |
|                                 |                                 |
| neutral                         | not match                       |
|                                 |                                 |
| temperror                       | return temperror                |
|                                 |                                 |
| permerror                       | return permerror                |
|                                 |                                 |
| none                            | return permerror                |
+---------------------------------+---------------------------------+


Is the payload for DOM based XSS defined to originate from only inside the browser or even outside of it

DOM based XSS vs Reflected XSS

  Should I interpret this as Reflected XSS means being able to injecting <script> tags in an HTML context, and DOM based XSS means being able to inject payload inside an already existing <script>?

No.

Reflected XSS means that your injected payload is reflected into the answer delivered by the server and executed by the browser (it doesn't matter where the payload is inserted, as long as it is interpreted by the browser).

With DOM based XSS, the payload may or may not be delivered in the reply of the server, but it will not be executed by the browser as-is. Instead, the JavaScript code delivered by the server will take it, and insert it into the DOM, thus leading to its execution.

DOM based XSS and Server Interaction

  Since the payload is going from the victim's browser to the server and coming back to the browser, how is this not reflected XSS instead?

Because the fact that it goes to the server and back is not relevant for the attack.

What is relevant for the attack is that the JavaScript delivered by the server reads out the URL and inserts it into the DOM, thus executing the injected code.

If you keep reading, OWASP also describes this:

  The server responds with the page containing the above Javascript code. The browser creates a DOM object for the page, in which the document.location object contains the string:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

  The original Javascript code in the page does not expect the default parameter to contain HTML markup, and as such it simply echoes it into the page (DOM) at runtime.
  [...]
  In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side.

So OWASP also specifically states that a DOM based attack can go to the server and back.


When I run this command in OpenSSL, it also creates a file called `serial_number.pem`

From the documentation of ca:

-outdir directory The directory to output certificates to. The certificate will be written to a filename consisting of the serial
number in hex with .pem appended.
...
new_certs_dir
The same as the -outdir command line option. It specifies the directory where new certificates will be placed. Mandatory.

So yes, this is the documented and expected behavior.


How can hackers find buffer overflow without source code?

There are a number of ways. Probably the most common ones, though are fuzzing and reverse engineering.
Fuzzing is a form of automated security testing where a program that consumes untrusted input (such as a file parser, driver that accepts IOCTLs from less-privileged code, network server, or network client that connects to untrusted servers) is repeatedly subjected to algorithmically-generated inputs. There are several variants of fuzzing, such as mutational fuzzing (where valid inputs are mutated randomly before testing) and generational fuzzing (where the fuzzer is given a description of the expected data format and then generates inputs that approximate, though do not necessarily follow, that format). Fuzzing can also be anywhere from completely random changes to fully deterministic for a given data specification, though most fuzzers are somewhere in between (they use some logic to determine interesting locations within the input, and interesting values to change them to, but the actual details are randomized). This randomness means that fuzzing usually can't exhaustively test a program, but it's a highly effective way to find vulnerabilities nonetheless.
The program being fuzzed is run under a debugger that will detect when, where, and why it crashes (or exhibits other undesirable behavior, such as becoming unresponsive or using exorbitant memory). Even without debug symbols (much less source code), it is usually possible to determine what kind of exception the program encountered, which security researchers can use to estimate the likelihood of exploitability (for example, an NX violation where the process tries to execute a non-executable address, or a write access violation / segmentation fault where the program tries to write to a read-only or unmapped address, are both likely to be exploitable). In every case of a crash or other indication that the program failed to handle the input, the fuzzer logs the crash dump, type of failure, and specific input that caused the issue. However, it's highly unlikely that a fuzzing input will be a useful attack by itself (except possibly to crash the program for denial-of-service), so weaponizing the vulnerability (Exploit Development)usually takes more work.
Reverse Engineering is the process of figuring out the details of something's design, without the actual designs. In the context of software specifically, it often involves disassembling binary code into human-readable assembly language, and possibly "decompiling" to produce a higher-level programming language that is easier to understand and navigate. Neither disassembly nor decompilation can reliably generate the original source code. For example, things like comments are inevitably lost, many languages do not maintain data type info in their compiled form, optimizations can rearrange code and collapse constants and so on in ways that are harder for humans to read, and there are simply multiple ways to express some programming concepts (for and while loops are logically interchangeable even though they look a bit different). However, there exist tools that do a decent job with most programs, and some people are skilled at reading the output of such tools much the way they would read actual human-written source code. (Also, some languages are extremely easy to decompile, although those languages usually include built-in protections against buffer overflows in particular.)
Exploit development without source code usually requires some amount of very focused reverse engineering, where the vulnerable code is examined in detail to determine what input will have the desired result. This is often a somewhat interactive process, involving running the program many times under a debugger, single-stepping through the vulnerable code to see exactly what the registers and memory layout look like, and then altering the input to make the vulnerable program do the desired thing (typically loading a "shellcode" or similar, to enable executing an arbitrary program). This process is the same regardless of whether the vulnerability was found via fuzzing, reverse engineering of the whole binary, or something else.


To solve this issue you need to modify this line:
myuser ALL=(root) NOPASSWD:/myuser/program.pl,/usr/bin/perl
Into this one:
myuser ALL=(root) NOPASSWD:/usr/bin/perl /myuser/program.pl


Requiring an on-site visit to reset a password or get VPN access

As someone who writes these kind of policies I'm always interested in how admins manage to circumvent the organizational controls that I want to implement.

Why would an on-site visit be required?
If someone new starts working for an organization - no matter if it's a consultant or an employee - it's really complicated to authenticate an account creation request. Sure, there are certificates and public keys and whatnot, but a lot of admins that do day-to-day IT service work struggle with putting a lot of trust in these means of authentication. Besides the lack of expertise, there might be a lack of technical capabilities to make use of these means. On top of that there might be some risk of private key compromise or well executed social engineering.

So what's an easy and cheap way to make sure you are giving access to the right person? Make them come on-site, identify and authenticate them. Afterwards, check their device into the directory service. There's little to no additional cost for you as a company, and risk of impersonation can be reduced by a lot.

My guess is, that you are working with companies that have a policy that is set up like this, but they also employ admins who are too lazy or have other controls implemented that make it unnecessary to actually - for instance - verify your identity document(s).


What is the point of hosting database externally?

They're using id.avast.com as an authentication provider, not just an external database.  So RCE doesn't get you access to it (assuming it's a different host machine), SQLi certainly doesn't, and since it's on a different domain (origin), neither does XSS.  They've now significantly isolated their password hashes from the forum software.

Using an authentication provider is very different than just moving the database to another host.  (And also consider there are many threats other than RCE.)


Are there any security advantages to forcing a password-character limit on reset, but allowing unlimited character in password-login?

It would have a slight advantage that bots or attackers that haven't done their reconnaissance properly may be wasting time on password guesses with passwords that the system can't possibly accommodate. If an attacker can register for their own account, they should have checked the maximum password length and other password rules by trying to reset their own.

This depends greatly though whether truncated passwords are accepted by the input field.

Also note that limiting password lengths in the first place isn't great, and could be an indication that the password is being stored insecurely.


novice level: catching HTTP request/response

Encryption (https) is the best way to prevent a "man in the middle" attack that you're describing. It is possible to MITM encryption but it's rather difficult to pull off, even for seasoned veterans.

Assuming the communication as it stands now is in plain text (not encrypted) then yes, people can use a MITM attack to get the client to think they are the server, and the server to think they are the client. That would allow them to see traffic from both sides, hence man in the middle. The even easier method would be to simply "sniff" the traffic which means that the traffic isn't directed toward the attacker from either computer, but rather they simply take a copy of the traffic as it passes through the network. Sniffing is not as easily detectable as MITM but if the attacker attempts to spoof an the client IP that they were sniffing in order to send malicious traffic, that normally is much easier to detect.

The simple answer for prevention is encryption stops 99.9% of these issues. The long answer is convoluted and sounds very similar to a conspiracy theory, just know that no method of prevention is perfect. Eliminating low hanging fruit fends off most attackers out there, there's too much easily hackable stuff out there to spend time on one target... unless there's sufficient motivation.


How does Amazon prevent mischief in their AWS Lambda service if I am allowed to execute code on their machine?

Simply, the environment within which you are executing your commands is sandboxed and is unable to affect the host OS or other users' commands. Unless there's a vulnerability, of course. From https://aws.amazon.com/lambda/faqs/:

  Q: Can I access the infrastructure that AWS Lambda runs on?

  No. AWS Lambda operates the compute infrastructure on your behalf,
  allowing it to perform health checks, apply security patches, and do
  other routine maintenance.

  Q: How does AWS Lambda isolate my code?

  Each AWS Lambda function runs in its own isolated environment, with
  its own resources and file system view. AWS Lambda uses the same
  techniques as Amazon EC2 to provide security and separation at the
  infrastructure and execution levels.


What are the steps of hashing and steps of verifying password using salt and key?

Let me correct this. Notice the bold parts, and removed steps

1- During registration:

user insert password
hashing function generates unique salt
hashing function adds the salt to the password
hashing function generates a hash from password + salt
the hash and the salt are sent to the application database

2- During login:

user insert password
the application retrieves the salt and password hash for the username
hashing function adds the retrieved salt to the entered password
hashing function hashes the salted password
the application compares the two hashes for the user (the one registered in the application database and the one derived from the input)
if both hashes are the same then the login happens

This way you only ever store a hash and a salt, which makes it impossible to find the password from what's stored in the database, as long as the choice of hashing algorithm is secure and the password is hard to guess.


Am I traceable if the VPN I am using keeps turning on and off?

You are traceable. You used the correct idea when you described it as "switching networks". As you are streaming, your computer continually reaches out to the server to get the next bits. Your computer does not care what network it is on, it is just reaching out to the server, and the network and all the hops between you and the server are responsible for getting the traffic there.

So, if you start off using a VPN, then the packets travel over the VPN network. If that network goes down, then the network adjusts to keep the stream going on the new non-VPN network. This stream is unprotected in any way.

All streams are logged. The VPN provider logs the streams going through it, and the ISP logs the streams going through it. The server also logs the connections made, so it will see that the stream keeps switching networks.


What's wrong with my own authentication scheme?

Yes, this is insecure as specified.

Your design seems to be vulnerable to Cross-Site Request Forgery (CSRF also known as XSRF) attacks (need to add a CSRF token with all POST actions that is displayed with the form and stored in a session cookie).  Basically, if a user goes to some other website (email, forum, blog) while logged into your website, their browser may be forced (by javascript, by a secret form) to make an unintended POST request to your website doing some action that I don't want.

Your scheme also isn't particularly specific.

How are passwords dealt with (bcrypt or PBKDF)?  Or at the very least a salted hash?  Are they checked with a constant time string comparison right?
How is data protected over the network during transit (HTTPS?),
How is data inserted/pulled from the database? Prepared statements (also known as parameterized queries) everywhere? (Great!)  Or do you execute a string with an SQL command containing user input (Vulnerable!)?
How are tokens are stored in the browser (Secure HTTP-only cookies?)

Quite possibly they could be other flaws in the implementation as well.


CloudFlare probably injects a header called X-Forwarded-For or X-Client-IP that you could read. However, [a] this can be faked and [2] it won't stop any attacks at layers 3 or 4 because the traffic really comes from CloudFlare.


Ethics question, post-publication of 'DIY hack' that implies security hack

From what I understand of your question, my opinion is No.

You describe a web based brute force tool, sans the brute force capability. In short, what you describe is a couple of lines of code that almost anyone could make in a couple minutes. There exist many web based brute force tools, so if this particular script didn't exist, it wouldn't make much of a difference, as most attackers probably have their own tools they are familiar with and wouldn't need to use yours.

Most web based login functions are pretty basic and easy to reverse engineer due to the nature of the web. Most sites are HTML/JS that do not use compiled code, and most don't obfuscate their scripts.

If the design of the login function is so secret that the details cannot safely be disclosed, then there are much larger security implications than some script floating around. You shouldn't need to hide the process of authentication in order for it to be secure, this is considered security through obscurity and has no place on the internet.

The server side should be enforcing login rules that limit the number of unsuccessful attempts. It really makes no sense to move security away from the server to the client as there is no realistic way of controlling what a client is doing.


Is it safe to create live usb on an infected system?

It is definitely not safe. You cannot trust any drive that has been written from an infected machine.

There is no way to ensure the integrity of the live USB.


Download Torrents on University network without detection

It depends on who "they" are.

If you're torrenting, the university can use commercial traffic inspection tools to identify p2p protocols.  The tools are signature based, and the signatures are proprietary, so the exact methods used and methods to circumvent them vary.

If you're torrenting illegally distributed copyrighted content, then the rights holders will be able to participate in the Torrent, identify the IP, date and time of the connection.

If you want to evade the university, you can use a VPN service.  This will encrypt the content and evade most modern tools.  It is still theoretically possible that the university can detect you though.   They can e.g., perform traffic analysis on your VPN connection.  E.g., they can tell that you're connected to a VPN service, and that there are gigabytes of data being streamed to and from your systems in torrent-sized chunks.  Knowing how universities operate, the onus would be on you to explain what you're doing.

If you opt for the VPN, the VPN provder would be identified by rights holders and might protect you from further investigation.  The rights holder could however force the VPN provider to reveal your identity.

To the best of my knowledge, no VPN provder has been forced to reveal the identity of an illegal content torrenter... yet.


If you're trying to eliminate malware, a simple format is sufficient.

Zero-wiping the disk or repeated over-writing with fancy patterns is about preventing humans from using advanced data-recovery techniques to read the data.  There's nothing magical about a pattern of bits that makes it malware, it's the structure surrounding it: the directory entries pointing to the files containing it, the fact that it's marked as executable code, the registry entries for running it, and so on.  Eliminate all that, as happens during a format, and it's just a harmless pattern of bits.


Does PCI DSS require an SAQ for each site?

Quick answers from a mobile device:

PCI is an organization-level commitment, so it is one per legal entity that has a CDE or merchant or processing agreement or other engagement with cards.

Not really either of those, but the latter is closer. Each requirement has to be met across the full scope. That one ordinarily does IT planning on a per site basis is immaterial.
It sounds like what will be needed is some partitioning and segregation at the sites so that a scope can be reasonably defined.

Scope has to come first, then risks can be assessed for a given scope. That said, defining scope is complex and understanding risks can help enormously in incentivizing all parties to reduce and enforce the smallest feasible scope.

You can use the SAQ for a gap analysis as soon as you have a scope.


What is the difference between "local" and "Adjacent" threat agents?

You cannot assign an Attack Vector (AV) to a component, only to a specific vulnerability to that component.
If the vulnerability can be exploited by using an SSH connection from a local network, set the AV to adjacent
Depends on where the connection of the attacker is coming from. If it' coming from the internet, use Network. If you need to be already in some LAN, use adjacent.

The CVSS user guide gives you some nice flowchart telling you how to decide which values to use in your CVSS vector


Scanning a network via a hardline connection to a wired-switch NIC in promiscuous mode

Yes it is answer 'C'. Switches forward traffic based on mac address. So if we have port fa0/1 and port fa0/2 and you are attached to fa0/2 with a MAC of BB:BB:BB:BB:BB:BB and fa0/1 has a mac of all A's. Anything destined for a mac of address of all A's will only be forwarded out port fa0/1 and nowhere else because these messages are Unicast meaning destined for only 1 host. You would however receive the broadcast messages.

Each port on a switch is on its own collision domain. Back in the days of the 'hub', multiple nodes shared the same collision domain and in this case you would be able to listen to all traffic passing through that collision domain.

So the reason it is not B is because traffic is destined for 1 port and 1 port only so you would only receive information from the port you are connected to.

There is something called SPAN (Switched Port Analyzer) from Cisco devices in which you can mirror traffic from a vlan or multiple ports and send it to the port you are connected to thus receiving all of the traffic.


Downsides to SSHing from a root account to a less privileged account on another server

Could SSHing as root be a risk

The main risk of SSHing as root is that if there is an exploit for your SSH client then it if the exploit was used against you then the attacker could get root access to the client machine.

As there are very few reasons to use SSH as root it is usually best to avoid running SSH as root.

Ways around reasons to use SSH as root

If you are using an authentication token you can allow a standard user access to the token instead of running as root.


Is it possible for users to insert forbidden characters into sites with htmlentities or mysqlescapestring?

While mysql_escape_string() is an alright method of preventing SQL injection,  parameterized queries are a much better approach. mysql_escape_string() is still not perfect; for example the following is vulnerable to SQL injection:

$q="select * from user where uid=".mysql_real_escape_string($_GET[uid]);

The PoC is simple:

http://localhost/vuln.php?uid=sleep(30)

Use parameterized queries!

htmlentities(),  or htmlspecialchars() will prevent some types of XSS.  They won't prevent XSS in DOM events.  This method won't prevent injecting events for example: value='junk' onclick=alert(/xss/).   htmlspecialchars($var,ENT_QUOTES) is a little better,  because it prevents DOM event injection, but you can still hijack an event (see the "it's a DOM event" blog post).

So these two functions will partially mitigate two vulnerabilities out of a couple thousand.  To call out some of the big offenders that will not be mitigated by mysql_real_escape_string() or htmlentites() we have: Directory traversal (and LFI/RFI for PHP), LDAP injection, XPATH injection,  HTTP Response Splitting, Log file injection...  and the list goes on.

Escaping input has nothing to do with removing "forbidden characters". It's about converting escape characters (or sequences of characters) into their "character literal" such that attacker controlled data is still interpreted as data, and not executable code.


Could the Fleximobile iPhone spyware be installed on a victim's iPhone just by having them connect it to a hacked computer via USB?

Not sure where you got that page, but I read the whole page including their FAQ:

  How can I tell if FLEXImobile is installed on my phone?

  FLEXImobile is not a virus and must be deliberately installed onto the Target phone directly, with a unique set of steps and configurations. It will not perform any functions that were not configured by human intervention. However, it does not install any visible program menus, folders or icons. Once installed, it may only be accessed or uninstalled by equally deliberate human intervention.

That means, if we can rely on them (which I think so), that it can not be installed through the computer.


As we all know that what is the SOP? As its very popular. But my
question arises when, pentesting this functionality.
AS SOP provide the website to call the resources only from its domain.
Ex. http: //example.com/ have the SOP functionality then Only
resources can call from this (example.com) domain.

Before you go ahead and try to pentest, you need a more than vague understanding of how it works. Mozilla's  MDN webdocs provide a very good starting point.

How the attacker might get damage this? I think its very simple
functionality. So i want to know about what vulnerabilities can arise
here?.

The same-origin policy (SOP) is a browser-level security control that dictates how a document or script belonging to one origin can interact with a resource from some other origin. Basically, SOP prevents scripts running under one origin from reading data from another origin. There may be cases where an app needs to allow other origins for resource access. This is achieved by using Cross Origin Resource Sharing. There can be potential security issues due to CORS mis-configurations. There are basically two ways in which CORS allows cross origin communications:

Access Control Headers: For every cross domain request the resource server issues access control headers in response which indicate if the requested access can be provided. TO gain a full understanding of how and when these headers are used and how they are interpreted by the browsers, I point you back to the MDN references.

Recently the guys at PortSwigger came up with a blog post, highlighting vulnerabilities arising due to CORS mis-configurations.

HTML5 postMessage API: The Window.postMessage() method, introduced in HTML5, allows JavaScript code running on different origins to communicate with each other in a bidirectional manner. e.g. This API can be used for communication between an iframe and its parent document.

This blog post highlights potential security issues in postMessage API implementations.
Recommended reads:
Why is the same origin policy so important?
How does CSRF correlate with Same Origin Policy


What is the difference between OWASP PHPSEC and PHP-ESAPI?

I would not use ESAPI-PHP.   It's a port of the Java ESAPI framework, (which has had its own issues, but soldiers on, more or less, mostly less) but the PHP port has been dead for a considerable amount of time now.  I wouldn't trust it as far as I could throw it.

I can't speak authoritatively to the PHP Security Project, but at a glance, the PHP Security Project may be in a similar state (their project page and site announces their upcoming participation in AppSecUSA 2013, which happened over a year ago) but at least it was a native PHP framework designed for PHP, so there may still be use to be had from it.  It's potentially worth researching, at minimum.


When the SPF is not validating, its clear that the mail are not going through your servers. Propably the end user has configured their client to mail through a ISP-owned "smarthost" that the ISP enforces.

Double check the client configuration and firewall settings, and ensure the mails are really reaching your relay SMTP.


How secure is github's whitelisting CORS domains?

Allowing any domain CORS access to GitHub's API isn't a huge security concern.

GitHub wants full control over who has access to their API.  The first step is that you have to contact GitHub in order to be added to their CORS API whitelist:

  Please contact us to request white listed access for your application.
  We prefer sites that setup OAuth applications for their users.

This allows GitHub to enforce this part of their Terms of Service:

  Abuse or excessively frequent requests to GitHub via the API may
  result in the temporary or permanent suspension of your account’s
  access to the API. GitHub, in its sole discretion, will determine
  abuse or excessive usage of the API. GitHub will make a reasonable
  attempt via email to warn the account owner prior to suspension.

  GitHub reserves the right at any time to modify or discontinue,
  temporarily or permanently, your access to the API (or any part
  thereof) with or without notice.


Spoofed MAC address with macchanger but cant connect to internet

Try sudo macchanger -r (interface) or sudo machchanger -a (interface)

While interface is down, then bring it back up again.


Encrypted folder with different access rights for different users

Solution-1 Enterprise & The Right Way
Check the steps listed below.

Prepare you information classification (public, private, internal only, etc.)
Define which type of data will be at which classification level
Define the permission strategy, define how you will identify who can do what at which doc. (object/subject/action matrix)
Deploy a file sharing software, it can be both embedded sharing solutions which are comes with OS or 3rd party tools.
Prepare users/user groups directories and set the permissions
Be sure you have logs of file actions on server / application (for example Windows does not store file action logs at default, "Audit object access" feature can give you the log)
Deploy an disk / file encryption solution, most of them encrypts all the system and only gives decryption rights to authorized users.
Deploy a DLP solution and monitor activities at clients (of course servers, network traffic, etc...)
Deploy SIEM solution, collect all of the logs of them and then correlate with each other.

Solution-2 Tageted // Just Wanna Be Compliant
Check OwnCloud (it have opensource version) tool or something similar like that. It is easy and stable which is compliant with GDPR, you can check it at https://owncloud.com/gdpr/.


By sending a SHA-512 hash of it, you don't expose more useful information about the key, than the attacker had from the Diffie-Hellman messages. However, it is completely insecure to rely on that hash. The man in the middle could give every side its needed hash, and still could intercept the traffic. For Diffie-Hellman to provide any security, either the messages must be signed with a public key cryptosystem, or the negotiated key. Note that when a signature gets transmitted, no more information leaks about the signed content than a hash.


How can I compute the value of the ASP.NET forms authentication cookie?

It completely depends on the settings you've chosen.   The value of the forms authentication cookie is a FormsAuthenticationTicket.   The ticket has a number of properties, and it is then:

Serialized before further processing.
At this point it can either be signed (using a message authentication code), or encrypted, or signed and encrypted, or neither.
If it signed, it could be signed using one of a number of mechanisms as specified in the machine or application configuration.
If it is encrypted, it will be encrypted using an algorithm and key specified in either the machine or application configuration.

So, you'll have to know which specific configuration you're targeting (and the specific keys, if applicable) in order turn the value of the forms authentication cookie into something usable.


Should I only disable, but never delete an account from ActiveDirectory?

Years ago I worked at a school board of 40,000+ users/staff, and each user had an AD account.

There was an Identity Management System in place, so the student records would populate AD. As long as the records were in the student system in a given state, the students existed in AD, but disabled if they had graduated, or whatever. Once the state of the student changed, the user was removed from AD, which if memory serves was a few years after graduation. I don't recall exactly, but I believe they were moved into a seperate OU too. They were kept because there was always a possibility that students would return for an extra semester, or work over the summer, or whatever.

The moral of the story: AD can easily handle large amounts of users, but removing them is dependent on the case of the user. If you need to keep the audit trail, leave the user but disable them and move them into a different OU. If they are seasonal, but may return leave them but disable them until they don't return for n number of seasons.


Figure out the cost level where you start getting uncomfortable.

Calculate the GB that would need to be transferred to reach that cost level.

See if you think an attacker will be willing to spend that much effort to hurt you for that amount of money.

Every time I run this calculation I end up thinking that if somebody hated me that much, they could certainly find an easier way to hurt me.

For example, a million downloads of your 2MB document is going to cost you about $240 in data transfer charges plus $1 in request charges.  To create this cost to you, the attacker is going to have to download 2,000 GB (2TB).  That's weeks of completely filling up a 10Mbps line.  Just for a measly $240 impact.

Amazon generally doesn't discuss publicly all of the security measures they have in place to stop DOS, DDOS, and other attacks against their customers.  In one whitepaper, Amazon says: "Proprietary DDoS mitigation techniques are used."  Of course, it's not always easy to differentiate between a DDOS and a popular resource :-)

You can read more about Amazon Web Services security on their site:

  http://aws.amazon.com/security/


Is revealing your residence physical address when browsing the web a security risk?

If it only narrows it down to an apartment building, it probably still isn't that big of a risk if it is fairly large.  The reason that it happens is that the apartment itself probably has a static IP tied to their domain or perhaps an IP range.  It's no different than when you use a traditional ISP and it says that your are connecting from 123_234_12_34.nycap.rr.com.  It's a sub-domain of the IPs controlled under their particular domain and so it shows up in a reverse lookup.

IP addresses in general already generally narrow it down to cities and anyone connecting from an office or school can generally be tracked down to that level.  Having a similar level for a large apartment building isn't significantly different from knowing someone was connecting from a community college or a public library.

In certain high risk situations might it be unacceptable?  Perhaps, but in the general case, I wouldn't be too worried about it personally unless there are only a dozen or two people in the building.  The more important thing to realize and remember is that you are almost never really anonymous on the Internet unless you go to a lot of effort to try to be.


Finally got it whats happening is when i do netcat somehow my request is directly destined to the given address not to the proxy but when i do netstat with proxychains ,proxychains is directing my request to my proxy server then my proxy is making connection with the address and response is redirected to me.


TL;DR: How does CORS prevent XSS? It does not. It is not meant to do so.

CORS is intended to allow resource hosts (any service that makes its data available via HTTP) to restrict which websites may access that data.

Example: You are hosting a website that shows traffic data and you are using AJAX requests on your website. If SOP and CORS were not there, any other website could show your traffic data by simply AJAXing to your endpoints; anyone could easily "steal" your data and thus your users and your money.

In some cases that sharing of data (Cross Origin Resource Sharing) is intended, e.g. when displaying likes and stuff from the Facebook API on your webpage.
Simply removing SOP to accomplish that is a bad idea because of the reasons explained in the above paragraph. So CORS was introduced.

CORS is unrelated to XSS because any attacker who can place an evil piece of JavaScript into a website can also set up a server that sends correct CORS headers. CORS cannot prevent malicious JavaScript from sending session ids and permlogin cookies back to the attacker.