keyUsage Extensions on a Certificate Authority I have a question about what key usage should I choose when creating a private CA (root or subordinate).

I have inspected some root and issuing web certificate authorities and they tend to use digitalSignature, cRLSign and keyCertSign. But isn't it logical to only use  cRLSign and keyCertSign since the job of a CA is to sign other certificates and CRLs ?

Should I mark the key usage extension for a CA as critical or not? (My guess is yes, but I don't know how to justify it.)

Can someone please clarify the methodology behind these choices?

EDIT:

Example  C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3:

-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----

I think you're right. RFC 5280 section 4.2.1.3. Key Usage says (emphasis mine):

KeyUsage ::= BIT STRING {
       digitalSignature        (0),
       nonRepudiation          (1), -- recent editions of X.509 have
                            -- renamed this bit to contentCommitment
       keyEncipherment         (2),
       dataEncipherment        (3),
       keyAgreement            (4),
       keyCertSign             (5),
       cRLSign                 (6),
       encipherOnly            (7),
       decipherOnly            (8) }

  Bits in the KeyUsage type are used as follows:

  The digitalSignature bit is asserted when the subject public key
  is used for verifying digital signatures, *other than signatures on
  certificates (bit 5) and CRLs (bit 6)*, such as those used in an
  entity authentication service, a data origin authentication
  service, and/or an integrity service.

  ...

  However, the digitalSignature
     and/or nonRepudiation bits MAY be set in addition to the keyCertSign
     and/or cRLSign bits if the subject public key is to be used to verify
     signatures on certificates and/or CRLs as well as other objects.

My guess is that CAs want the ability to use the root key for some other kind of authentication; who knows, maybe signing logs or something? Either that or it's misconfiguration.

Full disclosure, I work for Entrust, so I'll use them as an example: the publicly-trusted Entrust Root Certificate Authority—G2 and the L1K and L1M issuing CAs do not have the digitalSignature keyUsage, so it's certainly not needed:

As for your other question:

  Should I mark the key usage extension for a CA as crticial or not ? (my guess is yes, but I don't know how to justify it)

RFC 5280 (same section) says:

  When present, conforming CAs SHOULD mark this extension as critical.

I'm not sure what happens if you mark this as non-critical, but I'm guessing some clients / verifiers will work fine, and some will have weird behaviours.


Are client generated CSRF tokens as secure as server generated ones I'm currently struggling with the implementation of CSRF in a web application. The application is (more or less) stateless. There is however a session that is kept in a (HttpOnly) cookie. As we use this cookie we are subject to CSRF. But as the session is the only state the application has, I'm wondering how I could do the CSRF protection.
My current approach is to hash the session information and use this as CSRF token. Thus I can recreate the token for validation based on the session and (almost) no session information is available to the JS code. But I kind of dislike the idea that there is a connection from session to CSRF token as CSRF tokens should be random.
I found this post on doing CSRF in a stateless application that focuses on generating the CSRF token in the JS code and sending it as cookie and header. This approach seems to be very reasonable. But client-side generation of the CSRF token seems to be rather uncommon and most guides only mention server-side generated tokens.
Thus I'm wondering if there are any drawbacks with the approach of generating the CSRF token on the client-side?

The actual answer to your question depends entirely on how the token is generated and used. In some cases, doing it server-side is a necessity if you don't want to trade away other security. In other cases, it makes no difference.

There is only one important part of "generating the CSRF token in the JS code and sending it as cookie and header" and it's the "header" part. You can't send custom headers (or standard headers with any but a narrow set of values) in cross-site requests, unless CORS is specifically configured on the server to allow it. Thus, a completely fixed header name/value pair of IsCsrf: no is sufficient to prevent CSRF, so long as no third-party sites are allowed (per CORS preflight responses) to send requests with that header set. No randomness required.
Anyhow, that approach certainly doesn't require the server to pick a string, except in the sense of "the server should probably have a known header name it looks for". Nothing else matters, and it's fine for every user to use the same string (so long as there's no way for one user to force another to make a forged request from the target site directly... but of course that's not Cross-Site Request Forgery anymore).
Of course, that approach means all state-changing requests must be sent using script, which is undesirable for some sites (and already inherent for some others). Doing the more traditional version of double-submit cookie - where the value is both in a cookie and in the request body - is much more broadly compatible, but suffers from the thing where the security model of cookies is kind of a mess (what happens if the same cookie name is set with different values in Secure and non-Secure contexts? Why is it possible at all for a value set in a secure context to ever be visible in an insecure one, or vice versa?). There are various approaches to solving this - the most portable and widely-supported being HTTP Strict Transport Security (HSTS) as this effectively makes all cookies "Secure" whether they are actually flagged that way or not and totally obviates the issue of non-secure contexts - but if you're going for modern solutions you can also just use the SameSite flag and just break the assumption that cookie-based sessions mean CSRF risk.
If you go with traditional double-submit cookies, I don't see any reason they need to be generated server-side. The important part is that something a cross-site request controls (the anti-CSRF token in the body) and something the cross-site request (hopefully) doesn't control (the anti-CSRF token in the cookie) match, or at least have some tightly coupled relationship (it's fine for one to be a cryptographic hash digest of the other, for example). On the other hand, double-submit cookies are... not a great approach, because there are too many ways to plant a cookie on a victim that suddenly you need to be careful about.

Or you can go with your initial idea, of hashing the session token and using that value as the anti-CSRF token! This is actually a great idea, one I wish I saw more often. It's as stateless as your session token. It's as secure as your session token (which had better be "very"). It inherently solves a problem I've seen in home-rolled anti-CSRF code, where the CSRF tokens are generated and checked securely but nobody remembered to tie them to a session, so I can log in, see my CSRF token, and use it to CSRF you even though you're supposed to have a different one. The meaningful requirement of anti-CSRF tokens isn't actually that they be "random", it's that they be "unpredictable", which is less strict. Since the exact same constraint applies to session tokens (e.g. a JWT is not at all random, but it does contain a very unpredictable signature), it's perfectly reasonable to use the session token as a source for the anti-CSRF token. Leaving the session token as HttpOnly and hashing it to get the anti-CSRF token means no risk of somebody stealing the session token through XSS (though of course, remote-controlling the site using script injected via XSS will still work; stealing the session token itself is less relevant than some people think).
If you're still concerned about randomness, you can easily solve this by using a (random) salt and concatenating the (unhashed, plain-text) salt with the hash digest rather than using the digest alone... but I'd love to hear any argument for any attack this actually protects against.
Obviously, if you use the "hash of the session token" approach and your session token is still HttpOnly, you do need to generate the anti-CSRF token server-side. Fortunately, that's really simple to do. The server won't even need to re-compute it except when actually checking the value; the value could be computed once and stored client-side (in local / session storage), then get dynamically injected into any HTML form or similar request where the protection is needed.


"Due diligence" in PCI requirement 12.8.3 Item 12.8.3 from the PCI DSS requires the following:

  12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

What is considered "proper due diligence" in this case?

12.8.3 is very ambiguously written, but what it boils down to is that you need to vet your potential service provider. You need to have procedural documentation showing the processes behind vetting a service provider. That part is pretty simple.

As far as what you should do to vet your potential service provider, that's a tough call. (and it's up to you to figure the majority of it out) Risk analysis will have to be done. Look into the reputation of the company and their past history. Ask tough questions related to what you are potentially working with the provider.


Cryptographic File Storage scheme First of all,I am new to security as a whole and taking my first formal course on it.So sorry if any major errors are present.
I had a scheme for remote file storage as an attempt to use my course topics:

I have a few google accounts(say 2 = N) to which seperate firebase storage instances(2 again) are there
within each instance there are a few folders(say 3 = M) each corresponding to a deployment service(heroku,pythonanywhere..).No cross folder access is permitted.
Each deployed service(a total of N*M) has its own set of users and authentication implemented.
All services have REST API's for read/write to their folders.
On a local app on setup an master password is given and a key file is generated the master password is passed through an KDF(say to give masterkey) and then KDF(keyfile+masterkey) gives key encryption key(kek).
A set of accounts for each storage bucket is created to 1 randomly chosen service per bucket and the accounts are registered with the service
The data of all accounts is encrypted and stored locally by a database encryption key(dek) which is by itself encrypted by kek for storage.
On a file to be uploaded it is broken down by (N,N) secret sharing scheme and N files are created which now is useless without all N being present.Each of this N files are uploaded to the buckets by the services mapped for this user.
On a file read all N files are read and used.
This might be overkill but I just wanted to use all schemes as a whole.Can somebody tell me if there are any critical vulnerabilities in this scheme?

Almost every question asking "is this secure?" will be met with another question: "secure against what?" and that's my question too. But I will infer the average attacker.
You defense must be built in such a way that an attacker that gets the encrypted file cannot do anything with it, and with a minimal amount of components to do so.  Every new layer may marginally increase security, but can add vulnerabilities that can led attackers to easily get your data, or lock you out.
The critical step is this one:

The data of all accounts is encrypted and stored locally by a database encryption key(DEK) which is by itself encrypted by KEK for storage.

Anything else is superfluous from the security standpoint. Having data partitioned and distributed on multiple services is great for availability and vendor independence, because if any of your providers go offline (or go dark), you don't lose your data.
All your layers add little to the equation.

I have a few google accounts(say 2 = N) to which seperate firebase storage instances(2 again) are there

Phishing can deal with that, and the attacker will have access to the Google accounts.

Each deployed service(a total of N*M) has its own set of users and authentication implemented.

How is this implemented? Plaintext passwords? SHA1 and salt? Argon? And where the passwords are stored? When the database leaks, what is the consequences? Is the mapping transparent on the database? If data is encrypted, where is the key to decrypt? And if an attacker have database access, can he access the key? And how well protected against bruteforce is the authentication?

All services have REST API's for read/write to their folders.

How access to the API is managed? Are rate-limiting enabled? Soft-ban is employed if a client exceeds the rate?

On a local app on setup an master password is given and a key file is generated the master password is passed through an KDF(say to give masterkey) and then KDF(keyfile+masterkey) gives key encryption key(KEK).

And if the user loses this keyfile, how to proceed? He will lose everything, or there's a way to recover the keyfile? If there's a way, what stops an attacker from using this mechanism to create a keyfile for itself?

Having more pieces only makes your solution more difficult to understand and support, and can add hidden issues that will only become apparent when the service is being used and refactor isn't easy or even possible.


How do I prove that my email was hacked? I am getting emails and verification from sex sites that I didn't subscribe to. How do stop I them and prove that my email was hacked?

For you to recieve emails from different sites your email does not have to be hacked. Anyone who has your email adress could have signed it up for different accounts or mail lists. Or it is just random spam, that your recieve without anyone signing you up for anything.

If you email has been used to succesfully create an account on a site that requires the user to verify the email by clicking a verification link sent in an email, then that would be a sign that your email is actually hacked.

One way to see if you have been hacked is to see what IP adresses that has been used to access it. Many webmails (e.g. Gmail) provide this service. If you can't find it, perhaps you can ask whoever operates your mail server for a list. If you find suspicious IP addresses there (e.g. from a country you have never been to) that is a sign you have been hacked.

To stop the emails, just mark them as spam. No matter what, you should probably change your email password right away, just in case. I don't think you have been hacked, but it never hurts.


Proof of SIM card possession on iOS devices I need to proof that a user of my app is in possession of the correct SIM card.

On android devices, this is possible by simply sending a challenge within an SMS to the corresponding number (the proof that a user belongs to a specific phone number is not discussed here). As an android app can receive SMSes programmatically, the transmitted challenge can then be sent back to the server using the data connection. Obviously, there is more security to be implemented (e.g. digital signature of the challenge), but this is not relevant here.

Reacting programmatically to incoming SMSes is not possible with iOS. Does anyone have an idea how to proof the possession of the correct SIM card in iOS?

Thanks in advance.

I believe Ericsson were working on something similar to this. I'm not sure how far they have progressed, nor how easy or expensive it is but maybe worth being aware of.

https://labs.ericsson.com/apis/identity-management-framework/

All I've seen is some nice video slides showing how the framework would work to allow you to authenticate people based off their SIM. It uses something called Generic Bootstrapping Architecture to check the authenticity of a SIM/IMEI combination. If the iPhone doesn't support it at the moment, it should do in the future as it is a 3GPP standard.

http://en.wikipedia.org/wiki/Generic_Bootstrapping_Architecture

Sorry if this isn't the sort of thing you're looking for.


Is it bad practice to use your real name online? On some accounts I use my real name on-line (Google+/Facebook/Wikipedia/personal blog), others (Q&A/Gaming) I use an alias.

My question is: Security and privacy wise, what can people do with my real name? What are the dangers of using your real name on-line.

This is actually an interesting new field in infosec - reputation management.

Employers, Law Enforcement and other government agencies, legal professionals, the press, criminals and others with an interest in your reputation will be observing all online activity associated with your real name.
These "interested parties" (snoops) are usually terrible at separating professional and personal life, so you could be made to suffer for unpopular opinions, political or religious convictions, associates or group affiliations they consider "unsavory", and any behavior that can be interpreted in the most uncharitable light. (Teachers have been forced to resign for drinking wine responsibly while vacationing in Europe. No, really.)
Conversely, you need an online presence, otherwise you will be made to suffer for a lack of things for the snoops to spy on - employers, especially (from Forbes):

  Key takeaway for hiring employers: The Facebook page is the first
  interview; if you don’t like a person there, you probably won’t like
  working with them. The bad news for employers, though, who are hoping
  to take the Facebook shortcut: “So many more profiles are restricted
  in what the public can access,” says Kluemper.

You must carefully balance your public and private personas. Give as little information as possible in your public persona, and be mindful that unknown entities who may be antagonistic toward you will look to use whatever you put online against you. For instance - you announce you're going to visit relatives for the weekend! Robbers and vandals may take notice (from Ars Technica:)

  39-year-old Candace Landreth and 44-year-old Robert Landreth Jr.
  allegedly used Facebook to see which of their friends were out of
  town. If a post indicated a Facebook friend wasn't home, the two broke
  into that friend's house and liberated some of their belongings.

Social media companies such as Facebook and Google have proven to be hostile to the notion of privacy, and continually change their terms of service and "privacy settings" without consent to share more and more of your information with others. You cannot rely on them to protect your public reputation from your personal life. From NBC:

  The Internet search giant is changing its terms of service starting
  Nov. 11. Your reviews of restaurants, shops and products, as well as
  songs and other content bought on the Google Play store could show up
  in ads that are displayed to your friends, connections and the broader
  public when they search on Google.

  The company calls that feature "shared endorsements.''

It is best to offer information of a more personal nature pseudonymously, and keep the pseudonym(s) carefully firewalled from your real identity. Avoid major social media services when participating online pseudonymously if at all possible.


If forced to download files using FTP, what steps can be taken to provide security? I am in a situation where I must access data via FTP on a regular basis (for argument's sake, updated every 10 minutes). No other protocol is available for this operation. This data needs to be put onto a network share. I do not want to connect directly from an important network share to another server via FTP. The data itself and the username/password are not sensitive from my perspective as they are provided by the server organisation. I am more concerned about Man-in-the-Middle Attacks, Code or File injections and network reconnaissance.

I have two proposed solution. Any feedback or pointing to literature about these solutions would be appreciated as well as a straight answer:

Local: Have a server partitioned from the network to handle data transfer. Perform checks (automated such as virus scans, manual such as user file inspection or both) before moving it on to the network. Prevent dedicated server from being able to access the network.
Commerical: Use an MFT Product. Many of these products claim to provide additional security on top of FTP. I am struggling to find 3rd party information/analysis of these products however.

Thanks

Setup your own server (A) in an isolated secure enclave. Only allow this system to access the IP address of the remote FTP server (FTP) and nothing else. If the vendor running the FTP server can also restrict access to only your IP that would be ideal.

Then have your internal system (B) connect to this server via a one-way firewall rule using something like Secure Shell.

(FTP) <-------(FW)<---(A)<---(FW)<---(B)

      (A) Polls the (FTP) server every 10 minutes via script
      (B) Polls the (A) server every 10 minutes via script with a 5 min offset.

Note: The (FW) may be the same Firewall but a third network interface

(FTP) <-----(FW)--(B)
             |
            (A)

The important thing is to ensure that (A) cannot access (B) or anything else on your internal networks. Ideally nothing else in the world other than the FTP server. You may also want (B) to run tests on the files from (A) before importing them. There are also tricks with using two directories on (A) for scanned and unscanned files where files are scanned as soon as the FTP GET is completed. Lot's of options with this architecture.

Final note: Some vendors use FTP because they don't know how to use SFTP from the system they are using (most notably this occurs with AS/400's). It is possible to have the AS/400 FTP the files to a loopback address on itself (127.0.0.1) then have you access them via SFTP. This is MUCH safer than using FTP directly. Likewise, you can have the vendor do the reverse of what I wrote above to send these files to an SFTP server on their end instead of forcing you to use FTP at all.

Alternatively, you can run the FTP through a VPN which only allows your organization to initiate connections to the remote vendor but not allowing them to access your network.


Can a mobile operator assign traffic to every SIM card in their network? When using 3G or 4G internet on my phone, is this running over the SIM card or is this similar to WLAN traffic?

Can  a mobile network provider assign my mobile internet traffic to my phone by either the SIM card number or the IMEI of my phone?

All the things in mobile operators are assigned per SIM card. You have stored in HLR 3 parameters: MSISDN (your phone number), IMSI (internal customer identifier) and ICCID (SIM card serial number). Based on those parameters in different subsystems of mobile operator are created CDR (call detail record) for voice and data traffic. Once per month (for postpaid) and in the moment of usage (for prepaid) those CDRs are used to generate billing information for your account

IMЕI is not used for authentication/billing. The only moment when IMЕI is in charge is when this number is in black list of stolen or lost devices and depend of policies provider can permit or deny traffic (voice and/or data) to the device

P.S. And for each call, SMS, data packet is created such CDR. Sometime is possible mobile operator to sniff for data traffic (in charging proxy for example), but this depend of operator, law, etc.


How could you detect and defend against this type of (local) man-in-the-middle attack? Consider this type of non-standard man-in-the-middle attack, which is fundamentally the same nature of attack without the poisoning phase being required:

  Someone cuts the internet line at your house, or anywhere between you
  and your ISP, and re-joins it with a piece of hardware designed to let
  the data pass through as usual but also record it.

How could you detect and defend against this type of attack?

The result of this attack is not really different from someone compromising your router, your ISP, your VPN endpoint or similar:  the attacker will be able to intercept and modify the traffic.

Depending on the way the attack is done and depending on the characteristics of the line (i.e. FTTH vs. xDSL vs. cable...) one might detect changes to the line behavior like increased error rate, lower bandwidth or larger latency but if the attacker has done a proper job everything will look fine and nobody will notice.

Apart from the described problems with unprofessional hacks (bandwidth, latency) there will be no visible difference on the network layer if only passive sniffing is used. But if traffic modification is done you will notice it with protocols which have a built-in integrity check, like in case of HTTPS or VPN.

One defense against the attack would of course by to physically secure the line against the attack. But usually the line is not in your full control. The other way is not to defend against the hack itself but against its results: since the attacker wants to sniff and/or modify the traffic you should only use protocols with built-in encryption and integrity, i.e. send all your traffic through a VPN.


DLP vs end-to-end messengers I am interested in how DLP systems work. I have noticed that developers of DLP say that the software can see messenger traffic including end-to-end solutions. I understand MITM, certificate change, but in the case of end-to-end, how does it work? There is encryption between two devices, the third device cannot see it, isn't that correct? It must decrypt for analyzing traffic.

It will depend on the specific implementation of the specific product and the specific message traffic.

Data Loss Prevention tools tend to work in one of two ways: they sit on the network and look at logs, read emails, read file shares; or they are installed as a desktop agent which, the vendors assert, has full access to every keystroke, window, file and memory object.  DLP vendors, IMHO, like to assert much.  The network DLP products may require that the end user organisation tags data of interest.  The product then uses its magic unicorn to identify all those documents with that tag.  The agent-based products will know what files are being touched and can therefore assign a risk weighting to actions and hence report on them via the dashboards that they seem to love.

To read a message then could be as simple as the keystrokes being captured, could be the window being asked to report on its contents, it could be that the tool has the message certs and it implements a MITM as you say.  It could be as simple as reading the message store from the message server.

Regulated institutions such as financial service trading floors may have a requirement to monitor and record all instant messages being used. Many years ago I implemented IMLogic which was an IM compliance tool used by an investment bank as their traders used all the IM clients to have personal calls with external parties. They had a client that intercepted messages and sent them to the server for storage: nothing particularly clever.

The DLP products can only report on what they know: I expect that it would be possible to write your own chat client that they could not inspect if you had full end-to-end encryption.

The only way to be absolutely sure about how a specific vendor monitors a specific chat channel is to ask them.


Hash based code obfuscation The code below

if(str1 == "abc") {}

can be converted to

if(hash(str1) == 0x8732e) {} // assume hash("abc") == 0x8732e

to obfuscate the code.

But they are not equivalent when hash collision occurs; e.g., str1 = "xyz"'s hash value is the same as "abc".

That is true theoretically. But is it an issue in real-life when the method above is used to obfuscate code? Is it a well accepted obfuscation method?

The example hash digest you gave is wayyyyyyy too short (20 bits, or about a million possibilities), so you'd get collisions far too often and, worse, anybody who decompiled your program could trivially produce the correct strings (or, at least, strings that are acceptable due to hash collisions) just by brute-forcing the likely input space.

"That's a silly objection. It's just an example..." you might say, but it really isn't. I've found, and exploited, this exact type of weakness before. For example, there was a mobile app that used a 32-bit hash function on user inputs to try and hide what inputs would produce what outputs. It took under an hour to write, and run, a program that brute-forced the search space and found inputs that mapped to every hash digest the app was looking for.

In essence, this is much like trying to store passwords securely. There are definitely differences - passwords are rarely very long, while hardcoded strings in a program can be, and if you're performing the string equality test frequently then you can't afford for it to be as slow as a good password verify function would be - but a lot of the same parallels hold. Use a strong hash function, not just resilient to collisions and reversal but also ideally one that isn't so fast its possible to brute-force the whole search space. For short strings, use a salt so that people can't just look up the value in a rainbow table.

Now, as for actual obfuscation: this technique is one (of a great many) that obfuscation can use. It's usually not very effective, especially when implemented weakly (see my second paragraph), and has enough performance impact that it isn't usually used except selectively in places where the slowdown isn't a big deal. Obfuscation in general is a non-solution; at best it slows down reverse engineering enough that by the time the RE is complete the codebase is old enough nobody cares, without causing undue performance or program logic bugs in the meantime. In practice, though, it's usually not that good.


Should I use a separate SQL Server instance for a database with PII? We build software which needs a SQL SERVER  database.  This database will hold private user information (address,bank, ...)

My question is: Should I install my database in a fresh SQL Server instance, or can I use an exiting instance?

(I doesn't want to wast user resources but also want to deny unauthorized access)

If the existing database has strong security controls then there's no reason to have a separate one. If there are not strong controls on the existing database, and setting up strong security controls is not possible on the existing database then you will need to have a separate database to better protect the data.


GPG masterkey and subkey for encryption and signature and default keys I am a little confused (as many others) about the concept of subkeys as related to the primary key. gpg by default (at least it seems on my system --- using RSA), upon gpg --gen-key creates a masterkey and a subkey. The masterkey has flags SC that it could be used for signing and certification. It also creates one subkey with flag E, used for encryption. Are the following statements correct?

If I understand the whole concept both the masterkey and the subkey are key pairs, that is a pair of private-public keys.
the fact that one is only for encryption is because some algorithms have such requirement (need separate keys for encryption and signature)
The subkey with E flag: its public part can be used to encrypt information and its private part to decrypt the information that was encrypted with the public part.
The masterkey with SC flag: its private part is used to sign/certify and its public part is used to verify the validity of the signature.

The more confusing part is when I follow the advice to create further subkeys, one for signature, one for encryption. Let's just call the original encryption subkey ESK0 and the new encryption subkey ESK1, and the new signing subkey SSK1 and the masterkey MK.

After creating ESK1 and SSK1 I should have in total 4 public/private key pairs, correct? Then, following the guides, I remove the MK to an offline medium and remove it from my computer, thus I now have in my comoputer:

A public/private pair ESK0 (original encryption)
A public/private pair ESK1 (new encryption)
A public/private pair SSK1 (new signature)
A public key  for      MK

I then change password using gpg --edit-key $id passwd. According to some guides it should change the password to the subkeys, but I am not so sure about that, I think that this just changes password to the whole structure bounded to MK it is just that the structure with private MK stored offline has still the old password. Which is correct?

Now, if I sign something, which is the signing key? I believe it has to be SSK1 since MK is no longer available. Correct?

I then upload some public key to a key server using gpg --send-key $id. Which public key/keys have I uploaded?

If someone will use the information from the key server to send me some encrypted information, which public key will be use for the encryption - ESK0 or ESK1? I am worried it would be ESK0 since then the whole point of having subkeys would be completely pointless as for decryption I would still be using ESK0.

Also, why is it that the guides suggest removal of MK but the ESK0 still is supposed to stay on the system? What is the purpose of ESK1 then?

Thank you for any help.

If you already have an SC and E keys, and you want to remove your C ("master") key to offline storage, then all you require is a new S key (SSK1 in your example). You do not need to create a new encryption subkey -- your existing one is just fine for this purpose.

  I then change password using gpg --edit-key $id passwd. According to some guides it should change the password to the subkeys, but I am not so sure about that, I think that this just changes password to the whole structure bounded to MK it is just that the structure with private MK stored offline has still the old password. Which is correct?

You will change the passphrase on any locally stored subkeys, so it's a perfectly valid thing to do. The offline master key's passphrase will not change. The passphrase is what GnuPG uses to symmetrically encrypt your private keys before storing them on disk (to make sure they are not easily stolen via malware or poorly secured backups).

  Now, if I sign something, which is the signing key? I believe it has to be SSK1 since MK is no longer available. Correct?

By default, GnuPG will use the most recently created S key, so SSK1 will be always used in your case -- which is what you want.

  I then upload some public key to a key server using gpg --send-key $id. Which public key/keys have I uploaded?

You upload all public key data, including any new subkeys or identities.

  If someone will use the information from the key server to send me some encrypted information, which public key will be use for the encryption - ESK0 or ESK1? I am worried it would be ESK0 since then the whole point of having subkeys would be completely pointless as for decryption I would still be using ESK0.

Having multiple valid encryption subkeys is a recipe for something like this happening, so I strongly recommend you do NOT create a new encryption subkey. As I said, you do not need a new encryption subkey if you already have one.

  Also, why is it that the guides suggest removal of MK but the ESK0 still is supposed to stay on the system? What is the purpose of ESK1 then?

The "Master key" is your "C" key (certify). It is the key used to sign other people's keys and your own subkeys and identities. If any of your E or S subkeys are lost or you're worried they got exposed to malware, you can simply revoke them and create new ones as long as you trust the integrity of your C key. This is why it is recommended that your C key ("master key") is carefully safeguarded and stored offline.

At the end, your goal is to have the following structure:

existing [SC] key -- stored offline, removed from local disk
existing [E] key -- kept on disk
new [S] key -- kept on disk

Final note -- by default, GnuPG creates your Master key as [SC], but it doesn't have to. You can specifically tell GnuPG to create a standalone [C] key.


How to mitigate UDP flood attacks? My friend linked me some website where you pay $5.00 / m and get access to a plethora of 'dos stresser' tools that offer udp flooding, and other malicious flooders. It's a web-based system and you just enter in their IP and you're done. It's literally that easy it's sad.

My issue is even if you're behind iptables on a linux vps and are dropping all UDP packets, those packets are still going to hit the server.  I'm curious is there a way to block incoming UDP packets at the physical layer, or physical firewall so they cannot reach the software layer (or clients servers)? If that makes sense :P. I'm very bad at trying to explain this.

Thanks!

Your explanation is fine! I think I understand your question.

DDoS Mitigation works generally by placing a mitigation device/system upstream from your internet connection.  You can contract a DDoS mitigation service like Prolexic for these services, or you can go with a cloud provider that already includes DDoS mitigation from whatever vendor.

It is impossible to mitigate DDoS at the physical level from your server because the packets are likely flooding the next hop up on the network, e.g. your ISPs local switch.   So, you can be dropping the packets all you want, they are still coming from the ISPs switch to your network and utilizing your bandwidth.  Thus, to mitigate the attack, the packets need to be dropped upstream.

For smaller web sites, you can use a proxy service like CloudFlare -- in fact, this is the preferred solution for many until they reach very large size.  CloudFlare works by controlling your DNS for the domain.  It then proxies all web traffic through its network and servers, which are heavily fortified to withstand DDoS attacks and also to intercept other common hack attempts such as XSS and SQL Injection.  Legitimate traffic is then forwarded to your web server while suspicious traffic is dropped upstream, leaving you unaffected by the affects of a potential DDoS.


Is storing session data in the DMZ ok in an n-tier enterprise web application? Say I have a standard multi-tier web application with web servers in the DMZ and multiple services only accessible from an authenticated web app. Also let's suppose the web app uses server-side sessions.

I'm interested in the community opinion - do you think it would be ok to store web app session data in some kind of a database still in the DMZ, or should that data be in a proper backend database, encapsulated by a service? (By database in the DMZ I mean any kind of database, SQL, NoSQL, or even the filesystem of the web server like for example PHP does this by default.)

I understand it's all about what I want it to be protected against.

Considering an attacker only having access to the application UI, it almost doesn't matter (see at the bottom) as long as there is no session-related vulnerability in the application, but if there is one, session data is breached anyway.
Considering an attacker already having access to the web server with the user running the web app (eg. OS command injection in the web app), he would be able to either read the database in the DMZ or connect to the session service using the application credentials.
For an attacker already root/admin on the web server it's also the same.
From a management perspective, IT ops for the DMZ and a secure zone would typically be the same people.
Considering an attacker having gained some level of access to something else (not the web app) in the DMZ, it could be easier to access other servers, like the one containing the session data for this web app. This would be even more of a concern with a session store like Redis where authentication is not a strong point. But what if there is nothing else in this infrastructure apart from this application in question?

So what would be the benefit of putting session data behind a service? What would justify the additional cost, complexity and performance penalty?

For example having the session database in the DMZ, I could think of the threat of misconfiguration of the infrastructure that allows somebody from outside network level access to the session database.

Also some unrelated vulnerabilities in the web application might result in the breach of session data, especially if it's on the web server itself, like for example a simple local file inclusion could then be enough. But this risk can be mitigated in other ways in some environments (the application process itself doesn't necessarily have to have access to the session database files directly - or it could simply be a separate database, not on the web app).

So would you accept such an application as properly n-tier and reasonably secure in this regard, or do you think this idea is flawed and session data should be handled the same as any other application data?

Ultimately, this comes down to the level of risk you are prepared to carry. To assess that, you need to understand the impact of each risk being realised.

In this case, if there is relatively little impact if the session data is breached - which is to say that an attacker couldn't use the session data to mass exfiltrate personally identifiable data or create costly errors - then you are probably OK to keep it in the DMZ with the application.

If the session data would give access to credit card or other financial information, addresses, medical data, ... - especially for multiple users, then I'd say that was a significant risk and I would want to see it better secured.


Replaced single quote bypass for SQLi I have this scenario on my lab. HTTP POST login form on a IIS server. ASP backend using MSSQL database, and a single simple query as this:

sql="SELECT * FROM USERS_TABLE WHERE USER='" & user & "' AND PASS='" & pass & "'"

There is a simple "security" mechanism on ASP doing a replacement for single quote char. Single quote is replaced by nothing. Something like:

user = Replace(Request.Form("username"), "'", "")
pass = Replace(Request.Form("password"), "'", "")

As you can see both parameters are inside single quotes, CHAR(39) is not working because it is not interpreted as a command if put on any parameter, it is  inside the string. So first step is to be able to "break" the single quote. Unicode seems to be not working.

I'd like to know if there is any known technique to be able to inject SQL here.

I would try injecting a backslash at the end of the username.  Depending on how the language/system works (I'm not familiar with ASP) you may need to inject a double-backslash.  Also don't forget that your payload will probably need to be URL encoded.  i.e.:

http://example.com?username=admin%5C

You'll end up with this fragment in your query:

WHERE USER='admin\'

In most systems this will turn the single quote that was supposed to end the string into a single quote inside the string.  This would break the query, except that the opening single quote around the password parameter will end the user search string, and then whatever your password is will be injected directly into the query.  So you would use a payload like:

http://example.com?username=admin%5C&password=%20OR%201%3D1--

You'll then end up with this query:

WHERE USER='admin\' AND PASS=' OR 1=1--'

Just to be clear, AND PASS= has now become part of the search term on the USER column and there is no longer a search on the PASS column.  The comment is needed to make the final closing single quote disappear and avoid an SQL error.  The search on the USER column won't match anything but the OR 1=1 obviously will, and you'll (potentially) end up logged in as the first user in the system (probably an admin).  You could also try to target someone by replacing OR 1=1 with OR ID=SOMENUMBER to try to login as a particular user.


What bytes are stripped by info-zip? I see many software that check only for..between path separators. For a long time I thought they were no possibility to exploit invalid bytes (for example attempt to create..will lead to.?.on osx).

But I saw cve‑2003‑0282 yesterday. So what are the invalid characters that can trigger that bug on vulnerable versions.

I tried to search more about this, but it sees all the relevant links on the cve report are dead.

From the patch it can be seen that it is skipping any control and some more characters ([\x00-\x1f\x7f\xff]) when constructing the target file name:

+        * SECURITY: Skip past control characters if the user
+        * didn't OK use of absolute pathnames. lhh - this is
+        * a very quick, ugly, inefficient fix; it traverses
+        * the WHOLE path, eating up these as it comes to it.
+        */
+       dp = cp;
+       do {
+           workch = (uch)(*dp);
                 ...
+            } else if (workch == '.' && !snarf_ddot) {
+               snarf_ddot = TRUE;
+           } else if (isprint(workch) ||
+                      ((workch > 127) && (workch <= 254))) {
+               /*
+                * Since we found a printable, non-ctrl char,
+                * we can stop looking for '../', the amount
+                * in ../!
+                */
+               break;
+           }
+
+           dp++;
+        } while (*dp != 0);


How does Facebook track your browsing without third party cookies? Facebook has served me an ad for a website I visited earlier in the day. I have third party cookies disabled and have not followed any links between the website and Facebook (links which could contain a tracking ID connecting my Facebook account to the website).

Without third party cookies, how can Facebook know that I visited the website?

Facebook does not need to use third-party cookies to track you as you move from site to site, if the sites contain Facebook's javascript code (e.g. for the Facebook 'like' button).  In this case, Facebook's javascript code can place first-party cookies on your system, and communicate back to Facebook's servers to show you ads based on sites that you've visited previously.


Why does Cain and Abel downgrade SSH version 2 to v 1.51? I am developing a lab exercise with Cain and Abel and want to know why it is necessary to downgrade SSH before attacking.

  Identification phase

  The server sends to the client an identification string of the form
  "SSH-.-"; the client parses the
  server's string, and sends a corresponding string with its own
  information in response. Here APR-SSH-1 automatically replaces the
  version specified by the server in the first packet in order to
  downgrade the communication to SSH protocol v1.51.

What can SSH-2 do that version 1.51 can't?

SSH-2 is a complete rewrite of SSH-1, as SSH-1 has inherent design flaws like client authentication forwarding and packet injection. Ironically, the detection of the latter was implemented in a way that allowed executing code with the privileges of the daemon. Ettercap can utilize the design flaws in MitM-attacks by stealing the session key and decrypting all the traffic.

SSH1 MAN-IN-THE-MIDDLE
When the connection starts (remember that we are the
master-of-packets, all  packets go through ettercap) we substitute the
server public key with one  generated on the fly and save it in a list
so we can remember that this  server has been poisoned before.
Then
the client send the packet containing the session key ciphered with
our key, so we are able to decipher it and sniff the real 3DES session
key.  Now we encrypt the packet with the correct server public key and
forward it  to the SSH daemon.  The connection is established
normally, but we have the session key !!  Now we can decrypt all the
traffic and sit down watching the stream !
The connection will remain
active even if we exit from ettercap, because  ettercap doesn't proxy
it (like dsniff). After the exchange of the keys,  ettercap is only a
spectator... ;)

SSH-2 provides strong cryptographic integrity checks, Diffie-Hellman key agreement and support for public-key certificates. The communication protocol must be downgraded to avoid those improvements.


Does incognito/private browsing prevent XSS attacks? When starting an incognito/private browsing session, no cookies from other browsing profiles should exist. For example, if I am logged in to a site on my main browsing profile, then start a new private browsing session, I am not logged into that same site (cookies not carried over). Assuming it is a new private browsing session, there should not be any existing cookies or sensitive information that is available at all.

Does this also have the side effect of preventing or nullifying XSS attacks since there is no sensitive data to steal? Or this is a false sense of security?

An XSS attack is not primarily about cookies. It is not about stealing sensitive data either. It is instead about executing attacker-controlled code on the client side within the context of the site you visit. What kind of harm can be done by this code depends on the actual site and context.

Using a private browsing session will not prevent XSS by itself but it might limit the impact of what harm XSS can do - i.e. it has no access to the cookies or other stored data from the non-private browser session. It might though still do harm, but again this depends on the specific context and site you visit.


Emailing debit card details to a guesthouse I'm trying to arrange a holiday out to the Aran Islands, and the guesthouse emailed me back confirming that they do have a room available.

But here is the catch: they want me to email my credit card number, expiry date and the CVV to confirm my booking, which makes me a little uneasy. According to this answer, this is quite common.

Unlike the hotel mentioned in that question, the guesthouse is not a large chain that should know better (or be able to hire somebody who does know better).

Given that my card is chip-and-pin, should I be (particularly) worried? If so, what should I do next?

Ask your credit card provider for a one-time card number. Or get a new account with a low limit.

Put the credit card number (and maybe a short random string) in a plain text file. 7zip this file with AES encryption. Email the hotel with this file as an attachment. Phone them and tell them the password to decrypt the file.

(You might have to do a bit of "tech support" to help them out, but it's probably worth it)


Can SHA1 certificate be used for SHA256 cipher? I have two Windows 2008 R2 domain controllers configured with TLS 1.2. Both certificates are SHA1-RSA. I captured network traffic between two DCs while running LDAPS (LDP.EXE). It seems TLS 1.2 was agreed but the cipher it was used
TLSCipherSuite: TLS_RSA_WITH_AES_128_CBC_SHA256         { 0x00, 0x3C }

So by looking at it, is it going to use SHA1 certificate to sign SHA256 hash?
Will that work? Why it didn't pick up SHA1 cipher?

That's fine. It used SHA256 because that's stronger than SHA1. The signature in the cert is only used during validation of the cert and doesn't have any direct effect on the chosen cipher.

That said, SHA1 is being phased out as this Google Chrome blog post explains.


How did Snowden do it? We've all read about how Edward Snowden got access to thousands of classified documents and shared them with reporters.  But how did he do it?  He got access to tons of documents that he was not cleared for, i.e., that he should not have been able to access.  What do we know about how he was able to access them?

Motivation. I think this case study might have fascinating insights for security against the insider threat.  It might help us get a better understanding of what the threats are and how to defend against them.  We've all heard the Santayana quote: "Those who cannot remember the past are condemned to repeat it".  And, of course, if an insider can get this kind of access inside the NSA -- which I'd hope is one of the most locked-down environments around -- that should really teach us something about the insider threat in other environments.  So, I think it'd be helpful for us to understand what technical methods Snowden used to access documents he wasn't authorized to access.

Clarification. There's lots and lots of speculation out there.  I want to clarify that I'm looking for what we know about how Snowden did it, rather than your personal guesses/speculation.  I would ask that you avoid speculation, and instead stick to facts, citable references, reports from those in a position to know, etc.  If you absolutely cannot restrain yourself and must include some speculation in your answer, please make sure that you clearly distinguish between speculation (hypotheses, inferences, etc.) vs what's known (e.g., information that's been confirmed by someone in a position to know).

For instance, it's been widely reported that Snowden was a system administrator, which invites the speculation that maybe he used his administrator privileges to access documents that were being viewed by other
users on machines he administered.  But do we know that, or is that just speculation?  It's also been widely reported that Snowden had some training in security and exploitation, which invites the speculation that maybe he used some sort of technical attacks to defeat certain security mechanisms.  But do we know that, or is that just a natural hypothesis?  What do we know?

A very new Reuters release notes that:

  Former U.S. National Security Agency contractor Edward Snowden used
  login credentials and passwords provided unwittingly by colleagues at
  a spy base in Hawaii to access some of the classified material he
  leaked to the media, sources said.

  A handful of agency employees who gave their login details to Snowden
  were identified, questioned and removed from their assignments, said a
  source close to several U.S. government investigations into the damage
  caused by the leaks.

  Snowden may have persuaded between 20 and 25 fellow workers at the NSA
  regional operations center in Hawaii to give him their logins and
  passwords by telling them they were needed for him to do his job as a
  computer systems administrator, a second source said.

No way to verify if the sources are being truthful. Although the Reuters provenance is somewhat reassuring, everyone makes mistakes.


iOS: sandbox of an iphone app I am new to iOS so I do have only limited knowledge about iOS in general. For self learning purposes, I would like to know several things as I am quite confused after searching the web.

I do know that that there is a sandbox for each iphone app. So what I would like to understand is comparing a jailbroken and non jailbroken phone, would the sandbox still be available in each app at install? If so, is there any difference of the sandbox between a jailbroken phone and non jailbroken phone?

Also I would also wish to know the common types of data that are being probed from the sandbox. I believe it is not as simple as how I described.

The sandbox restricts each application so that it can only read its own files, and must get explicit user permission for access to features like location, camera, microphone, etc. Cookies are stored per-app, and sqlite databases are files subject to the sandbox restrictions.

On any phone, jailbroken or not, some of the Apple apps are system apps which are not restricted by the sandbox.

On a jailbroken phone the sandbox is still enforced for standard apps. However, it becomes possible to create third-party system apps that are not restricted by the sandbox. The details vary depending on which jailbreak you use. There's good information here: https://stackoverflow.com/questions/16026920/why-sandbox-in-ios-6-1-1-still-exists-for-app-even-after-i-have-jailbreak


Prevent Replay Attack When using FingerPrint as login We have an application that allows users to login using fingerprint. The server validating the sent fingerprint. Now, anyone can watch the traffic and resend them. What the best way to prevent this from happening? Should we add captcha when using fingerprint as validating the fingerprint?
Update: We have a system where legitimate users watch the traffic using Network Sniffer like Fiddler to capture their fingerprints and they can use the same HTTP traffic to replay which makes them automatically logged in without using fingerprint. We wanna force users to use a fingerprint every time instead of allowing them to replay.

That's not possible without TPM. Once a client digitally stores its biometric data, it can reuse it in the authentication request. A nonce won't help either as the client is not replaying anything. It just reuses its biometric like a saved password.
Let app requests nonce from the web service, use that nonce in biometric authentication. Once TPM validates biometric, the authentication result from TPM along with the nonce will be certified which can be validated by the web service. This is called attestation.
TPMs do not certify biometric data as this data never leaves the secure environment. The implementation to use hardware backed attestation varies across OEMs and OS.


Man in the Middle how to read incoming traffic for victims on the network i was just testing something about MITM i know MITM well
attack is just like:
gateway = 192.168.1.1
victim = 192.168.1.13
attacker = 192.168.1.6
performing mitm and enable linux kernel ip_forwarding and i see outgoing traffic for victim 192.168.1.13
i just wanted to know how to capture incoming traffic for 192.168.1.13 is that is possible ?
i see in wireshark a DNS request to 8.8.8.8 from victim but i didnt see the response traffic from 8.8.8.8 to victim probably because forwarding packets contains IP src=192.168.1.13 so real gateway at 192.168.1.1 send incoming traffic for 192.168.1.13 directly how to fix this could be fixed by sending ARP saying 192.168.1.13 is at attacker_mac ?
another question:
if now 192.168.1.1 at attacker mac and 192.168.1.13 at attacker mac and attacker has ip_fowarding isnt it causing a conflict as also gateway will say that 192.168.1.1 at his gateway and also vicitm machine will say 192.168.1.13 at its mac so vicitm outgoing traffic will go to both attacker and gateway ? and attacker will forward the same traffic that already had been sent also the sameway in incoming traffic !!
,regards

In order to truly man in the middle them you'll need to arpspoof them. By arp poisoning the router and your target, you can make them both forward traffic to you instead of each other. Then you forward it on, after inspecting it or modifying it.

assuming you're on kali or parrot

echo 1 > /proc/sys/net/ipv4/ip_forward

arpspoof -i <your interface> -t <router ip> -r <target ip>

arpspoof -i <your interface> -t <target ip> -r <router ip>

at this point you can either start wireshark, mitmf, etc etc etc

  References

What is arp spoofing

Tutorial on MiTM With kali


What probability of injecting invalid data is considered safe? I encrypt some sensitive data with AES128 and I use custom method (encrypted CRC) for providing data integrity. I have calculated the probability of successful injection of invalid data that equals 4.54e-13. It means that if an attacker injects one random packet per 1 ms the probability of successfully injecting invalid data within a month is at the level of 1e-3.

Would you consider this as safe solution? I know that the answer depends on the sensitivity of the data but I struggle to find information what probabilities of injecting invalid data are considered safe

Xenos' comment is right.

Unless you are a badge-bearing cryptographer, trust the badge-bearing cryptographer and don't implement your own method. You may think your method is secure, but you have no way to really assess that. Even professional crypto guys commited mistakes undermining their process. So use the hard work of the giants before you and use Autenticated Encryption.

It would be interesting to know how you calculated the probability of an attack. Do you have a decryption oracle? Can the attacker use chosen plaintext? Can the arracker have the source code? Is your solution according with the Kerckhoffs' principle? (attacker have everything but the key)?


I was hacked, but I don't know why Tonight I found by accident that someone had injected a bunch of crap links into the bottom of my personal site's index.html page. I thought it was a script at first, but after going into my FTP account and looking at the file on disk, the links are actually in the HTML. After further inspection of my hosting account, I noticed a few other files that didn't belong to me sitting there.

I get it. Someone figured out my not-very-secure password, modified my file, uploaded some other crap. My question is, why? What do they have to gain? Were people being hurt by this code? Have I been a zombie for the past month or two? I don't have a database or even any server-side code, so I have nothing worth stealing.

The following are pastebin links containing the contents of the hacker's code:

zip.asp
temp37.asp
links injected into index.html
/scripts/N5JmuiiPLm.asp

I'm in the process of getting the hosting access logs from my hosting provider. I could probably provide those too if anyone would be interested in seeing them. Also, I apologize if I've posted this on the wrong site; this seemed the most appropriate given my options.

Thanks.

You probably were hacked because you were an easy target. And even if there are no important data at your site it can be valuable to point people to a seemingly innocent and trusted host and get them infected by drive-by-downloads etc. In your case it looks more like your host was used for SEO optimizations, by linking typical phrases to external hosts and thus increase the search engine ranking of these hosts.


Risks of using AJAX on an HTTPS domain from a page served over HTTP I was working on a company's staging server today when I noticed that they are hosting their API's subdomain over an HTTPS connection while they are serving their user-facing dashboard over an HTTP connection. Does this pose a security risk? I know that HTTP provides no protection to data transmitted over the network, but I don't know if this will affect any HTTPS calls that are made after the page has loaded in a user's browser.

Also, a few notes: The company's dashboard is a single page application. I inspected the network traffic going on when you load the page and as far as I can tell all AJAX requests are being sent over HTTPS, including requests for logging in.

If this is a security risk, can you point me towards some official documents that I can use to persuade the company that they have an issue?

You have an HTTP dashboard that loads API content over HTTPS. This implies that if a man-in-the-middle attacker observes someone requesting the dashboard, they can arbitrarily modify the response and inject their own content, e.g. in a way that will reveal all subsequent API requests by the modified dashboard page to the attacker.

An attacker could achieve this by injecting JS code that with each API request also sends the response to an attacker-controlled domain or possibly by rewriting the requests to the HTTPS API to plain HTTP.

  I don't know if this will affect any HTTPS calls that are made after the page has loaded in a user's browser.

After the HTTP site has loaded and only under the condition that the attacker cannot observe any plain HTTP requests afterwards (meaning the user never reloads the site), the attacker wouldn't have a chance to eavesdrop on any subsequent HTTPS requests to the API or modify any content.

(But they could trick the user into reloading the HTTP dashboard by blocking the HTTPS requests - making the user think there is a bug that could be fixed by reloading the site.)


Redirection using HTTP meta tag I've created a small project, where I scan a 1000+ sites for TLS implementation, including

Does a https site exist
Does the site redirect from http to https
Various other info about the cert

Surprisingly, when I first ran the scan, a lot of sites were NOT redirecting users to https, even though the a https site existed (what a waste!), but gradually most of them begun redirecting users.

My question is on the redirection method. I feel redirection via HTTP Status code (i.e. server responds with a 301 status code, with the url of the https site) is the best way. I also feel that Javascript redirects are a no-no, and should be avoided.

But I recently discovered that you're able to redirect using a HTML meta-tag, this is stil a client-side redirect, but one that doesn't require javascript. To me this looks like an OK thing to do, especially if you have no ability to modify configurations on Apache/NGINX etc.

Obviously this is slightly less efficient that HTTP Status codes (since the site needs to fully load before redirection), but looks like a reasonable way to implement a redirect -- especially if the original http site is left empty.

Are there any security considerations around HTML Meta Tag redirects? And should I start marking meta-tag redirects as 'good'?

Only browsers (which interpret the HTML) will follow http-meta refresh tags and usually also only browsers will follow Refresh headers in the HTTP response header.

I have no idea why you consider Javascript based redirects a no-no. But if the reason is that it will only work in browsers then you should treat http-meta refresh tags in a similar way.

  And should I start marking meta-tag redirects as 'good'?

Since you don't explain what you consider 'good' in the first place it is impossible to say if redirects using http-meta fit your idea of 'good'.


What was state of the art knowledge on security of speculative evaluation when it was introduced to Intel CPUs? Many sources claim that almost all Intel x86 CPUs back to Pentium Pro are vulnerable to the Meltdown attack. Pentium Pro was introduced to the market in 1995.

What was the state of the art knowledge on security of speculative evaluation, the basis for the Meltdown attack, at that time?

The state of the art was non-existent.

At the time of the Pentium Pro, the World Wide Web was four years old.  Widespread use of shared hosting was about ten years in the future; if you suggested that people would want to run untrusted code provided by random third parties, they'd look at you like you'd grown a second head.  Memory protection was about preventing one crashing program from taking down the whole system, not about letting programs hide data from one another.  Speculative execution was not seen as having any security implications whatsoever -- it was simply a way of avoiding performance-killing pipeline stalls.


Is there a vulnerability when TLS is decrypted, then encrypted with OpenSSL that is vulnerable to BEAST or CRIME? Assume that the following TLS proxy exists

  User <-----> Load Balancer that decrypts, encrypts <------> WebServer

Where the web server is running a vulnerable version of OpenSSL.

Can the user exploit the web server if it is vulnerable to TLS or Beast, assuming the first link to the load balancer is secure?

BEAST is a vulnerability on the client, not on the server. A server is not, and never has been, "vulnerable to BEAST". There is some confusion about tools that "test SSL servers", that may report a "BEAST vulnerability" if the server fails to fix a vulnerable clients -- namely, if the client is vulnerable, and specifies in its ClientHello that it prefers to use a cipher suite with a block cipher in CBC mode, and also says that it accepts to use a non-vulnerable cipher suite (e.g. based on RC4), then the server has the possibility to save the client by choosing the non-CBC cipher suite, despite the client preferences. When the server does not do that, SSL testing tools will report "vulnerable to BEAST", but the vulnerability is still on the client, not on the server.

That being said, both BEAST and CRIME rely on a usage context where the attacker can do all of the following:

The attacker can choose part of the data that gets encrypted, along with some secret data that the attacker is very interested in (typically, an HTTP cookie).
The attacker can see the encrypted result.
Information obtained from point 2 can be used for point 1: the attack is adaptive.

In your case, this would require that the attacker can eavesdrop on communications between the load balancer and the Web server, and can choose the data that gets encrypted by the load balancer. Since the load balancer encrypts data that it just decrypted, straight from the user, the concept of BEAST and CRIME applies. This is true regardless of how the data is conveyed from the user's browser to the load balancer. That specific TLS protects data in transit between the user and the load balancer, but the attack really is on the connection between the load balancer and the Web server, i.e. out of the scope of that first TLS.

Things will still be challenging for the attacker, for the following reasons:

The usual method by which an attacker can both insert his data in the plaintext stream and observe the encrypted result is through a fake WiFi access point. However, in your situation, the attacker must somehow inject his malicious JavaScript on the client side (so he must be close to the user, network-wise), but also observe things on the internal network between load balancer and Web server. The attacker must be at two places at once.
BEAST does not work any more. To apply the attack, the attacker must have rather fine control on the bytes that he adds to the plaintext stream; mere HTTP headers are not sufficient. Note that we are talking here of the malicious code that runs on the client, i.e. within the context of the user's browser. The BEAST authors had found two ways to push their bytes in the stream, using a Java hole, or a draft implementation of WebSockets. Both holes have been fixed in browsers for several years.
Even if BEAST still worked, it might still have trouble getting through the load balancer: the fine-tuning of the attacker's additional input is not compatible with HTTP request; things must be a little more low-level than that.

CRIME will get through fine, though.


To choose a specific certificate among many I have 2 certificates (same hostname but issued from different CAs) installed for the same application on a server (lets say from domain A). however they are supposed to being used for authenticating with 2 different servers from 2 different domains (B and C). Problem is, both servers are trying to fetch the same cert which causes one domain to pop error since the CA trusted in one domain (B) is not trusted in the other (C).

Ideally, the plan was to make B take a cert trusted between A and B, while C would take a cert valid between A and C.

Is there any way to do that?

I hope I explained the question well enough.

The selection which certificate is send to the client is done at the TLS level based on the information in the ClientHello. Since there is no distinction in the ClientHello between these the clients B and C it is impossible to decide which of these certificates to serve based on these information.

Depending on the environment you are in and the server software you use you might be able to make this decision based on the IP address of the client. For example if your are able to divert the incoming connection to a specific local IP and port based on the source IP of the client you could then setup a server to provide different certificates and these ports. But, the exact setup depends on your environment and is off-topic here.


Why is the BLP access control model a mandatory one? In my lecture on formal methods in IT security as-well as on Wikipedia it is stated that the BLP model is a mandatory access control model. It is not clear to me why this is the case.

We have defined mandatory access control models as ones where modifications are constrained. I don't see why this is the case here. We have security properties (ss-property, *-property and ds-property) which restrict the set of protection states to a set of BLP-secure protection states, however it is possible to define a BLP system whose transition relation allows transitions in those states, then the system is just not BLP-secure anymore.

It's mandatory because the state stays the same while the system is in operation. Each subject and object is given a security level (clearance technically for subjects) of which cannot be altered when the system is running.

If the system allows changes of security levels then true BLP is not being practised, for example using likes of Harrison-Ruzzo-Ullman (HRU).

If your security policy allows changes then BLP is not the security model to use.


Password generation - too primitive? A while ago (12 years old), I recognized my passwords weren't safe at all. Because I used the very same password everywhere, some grumpy admin could easily take over all my accounts (he got mail and password).

The obvious thing to do is to change all passwords to unique new passwords. However, remembering these is cumbersome. There had to be a better way...

Leading to: Yet another password generator (Java >= 6).

Non-storing password generation (no file containing all passwords)
Easy recover of lost passwords
Master password used only locally, therefore totally safe (I thought)
Consistency across platforms (Android, Desktop, etc.)
Configurable length of generated password

It works like this:

Input master password and use of the password (e.g. google.com)
Create a Sha1 SecureRandom object
Seed it with the UTF-8 bytes of the master password and the use of the password
Generate as many random alphanumeric characters as specified by the length slider

Questions:

How might this method of generating passwords be attacked (else than bruteforce)?
How safe is this method of generating passwords?

If it is unsafe, what causes this unsafety and how to improve it?

Is there something entirely wrong with this approach?

For security, one important thing to take into account is that an exhaustive search on the master password is feasible. Schematically, an attacker who got a site-specific password (e.g. an evil admin on that site) can run your Java application (or some code of his own which applies the same algorithm) and "try" potential master passwords, to see if it yields the known site-specific password.

If your master password is fat and random (say, at least 70 bits of entropy), then this won't be an issue. However, if your master password is more "normal" (a "strong" password is, say, 45 bits of entropy), then this is a weakness. The situation can be improved by using proper password hashing:

You need the transformation from master password to site-specific password to be slow through the use of many iteration.
You need a salt. In this case, imagine that 10000 people use your system and all have an account on, say, google.com (a fictitious example). They will all use "google.com" as "password use". Correspondingly, an evil admin at google.com could attack all the 10000 master passwords in parallel, with a lot of cost sharing. You could use your own name as salt; names are not utterly good salts, but this would still significantly improve this situation.

This is "brute force", but with human-remembered passwords, brute force tends to work.

For usability, there can be some issues:

You have to remember what password length you used on each site.
Some sites have special requirements, and there is no "one size fits all" set of rules which works everywhere (e.g. some sites make it mandatory to use punctuation signs, while some others prohibit punctuation signs).
Some sites may mandate password changes. By definition, your applet cannot tolerate a password change, unless you use a new "use" string, and then you have to remember it.
In addition to being suboptimal for password hashing, Sun/Oracle's default implementation of SecureRandom is not well specified, and not guaranteed never to change. If Oracle decides to modify it at some point, all your passwords will be lost. You really should rely on some algorithm which is not subject to such changes.
Good luck running your Java code on your iPhone or iPad. For real portability (including making your code run on the machine you will own 5 years from now), you may need to implement your algorithm in several languages, because there is no such thing as One Language To Rule Them All. This again implies using a well-defined standard, and not "what Java appears to use for now as a PRNG algorithm".

For all the reasons above, making a "password wallet" which does not need storage space is challenging. This concept has been proposed and even implemented many times, and that may work for most sites, so you may tolerate it for your own usage. Depending on your own context (which site you use, what kind of hardware and OS you own...).


Building an info sec VM lab - safe to keep on my home network? I'm a new member making my first post here. I had a very quick, and admittedly basic, question. I'm setting up an info sec lab for the first time at home. I'm trying to build some more technical skills with things like Kali linux, pfsense, etc to help me transition from help desk/desktop support to a security analyst (or similar) role.

Just wanted to see if it was reasonably safe to put my host OS on my home wifi network? My understanding of VMs is that I can network them directly to each other and not expose them to the Internet. If that is the case, is it still necessary to put the host OS on its own network as well, or am I safe to leave it on the home network?

I was trying to see if my router (Verizon Actiontec) would allow for VLANs, but as far as I can tell, that is not the case. From what I've read so far, if I wanted to segregate my lab PC from my home wifi network, I'd need to purchase a second router. But if that's not necessary, and its safe to leave the host OS on my home network, I'll do so.

I very appreciate your time and feedback on this question and helping me to better understand. Thank you!

It sounds like you are trying to setup something of a cyber-range for learning. If this is the case you simply need to understand what risks are and are not being added to your network. Are you trying to make these systems available to the Internet as a whole ? If so, then you are adding very different risks than if they can only be accessed internally.

Likewise are you using this to test malware or play with botnets ? Systems for experimenting with these will have entirely different risks.

In any of these situations you are increasing the level of risk to your other home systems but if you are just setting up a cyber-range that cannot be accessed from the Internet it seems like it may be a reasonable risk for the amount of experience you will gain.

Your question doesn't have enough detail for anyone to really help you evaluate the risks but I think this also makes for a great learning experience for you too. What do you think of the risks and how would you learn to evaluate them. Evaluating risks is a big part of helping organizations with their security so maybe this is a great time to consider all aspects of what risks you are changing in your home network and also think about other things you can do to mitigate those risks. Maybe consider increasing the security of the other devices, backing up more often, and setup some type of network monitoring if you can. Again it depends on what your concerns are.

As a side note many security professionals do have two or more networks at home for this type thing and there are a lot of ways to do it. Likewise VM's can be very useful for creating cyber-ranges and cloud computing resources can be a helpful inexpensive solution for many types of tests (especially something like Amazon AWS where you can use a resource for just a few hours as needed).

My suggestion is if you're not dealing with malware or anything explicitly malicious go ahead and dive in. Some of the mistakes you will make will provide your best learning experiences and the faster you make those mistakes the quicker you'll learn their lessons.


Why does this cause XSS? And how can I prevent it? This is my source code:

<!DOCTYPE html>

    <title>XSS</title>

When I send q=\x3cscript\x3ealert(1)\x3c/script\x3e to my script, the alert is fired. How can I prevent this?

Escaping is context sensitive. You are escaping for HTML, but are using the variable in Javascript. Instead, correctly encode for JavaScript using json_encode:

printf('output = %s;', json_encode($_GET['q']));

Also, you are using the html function even though you don't seem to want HTML at all. What you probably want is the text function:

$("#output").text(output);


What is the difference between wiping vs deleting? I was reading about the Mask malware on Kaspersky. And they mentioned this:

  “Several reasons make us believe this could be a nation-state
  sponsored campaign. First of all, we observed a very high degree of
  professionalism in the operational procedures of the group behind this
  attack. From infrastructure management, shutdown of the operation,
  avoiding curious eyes through access rules and using wiping instead of
  deletion of log files. These combine to put this APT ahead of Duqu in
  terms of sophistication, making it one of the most advanced threats at
  the moment,”

So what is the difference?

What does a computer/OS do when a user clicks delete and how is it different from a wipe?

And how does a user do a wipe?

EDIT

Follow up questions:

Can data be recovered that is deleted? (I believe this would work as long as the data hasn't been over written?)

Can data that is wiped be recovered?

When you delete a file, the information is not immediately removed from the disk.  Instead, the OS/file system simply updates a database keeping track of files on the disk to acknowledge that the file is no longer needed and hides the file from being visible.  The information is only removed when, at some point in the future, the OS decides to use the space to store another file. That could be a few minutes later, or many weeks later, depending on how the computer is used.  Before then, the data is still recoverable using data recovery programs.

When you do a wipe (also sometimes called a secure delete), you are telling the operating system to not only update its file records, but also immediately overwrite the disk space with either zeros or random data, making it much harder to recover anything.

To do a wipe many operating systems support the key combination Shift+Del which will immediately overwrite the space the file occupied.  For maximum security though, there are many programs out there that actually fill the entire hard drive with random data and then delete the random data, sometimes more than a dozen times.  This makes it nearly impossible to recover any previously deleted files.  CCleaner, for example, is one freeware program that has that ability.

So to answer your followup questions:
1. Yes, it is usually quite easy to recover deleted (not wiped) data as long as it hasn't been too long since the data was deleted.  This is how most data recovery programs work.

2. That depends. If you do a single wipe (ie, you overwrite the space once with random data), you're probably not going to be able to recover anything with standard data recovery programs anymore. However, skilled investigators may still be able to recover the data by putting your hard disk platters under an electron microscope to determine what was originally there, as overwrites are not always completely clean.  It's like erasing a letter with a pencil and writing another letter over it; sometimes you can still faintly see the original letter.

If you do multiple passes with a very secure wiping algorithm though (like DoD, which overwrites the data 35(!) times), even this becomes unfeasible.


Benefit of randomly generated column names? Would it be of any benefit to have tables with randomly generated names?

For example:

An SQL injection might be looking for:

SELECT * FROM users WHERE 1=1

But if users is really rifchodafsnhe (or some other nonsense) their injection wouldn't work.

Question: pros vs cons of gibberish column names from a security vs usability standpoint

Security by obscurity is not always bad, but here I think it is.

The correct way to judge a security mechanism/implementation/control is "Does it impose more of a burden on the legitimate user than on the illegitimate user?, and is the burden disproportionate to the benefit?"

This poses a significant burden on the legitimate user and makes it rather likely that the legitimate user will misremember/misunderstand the answer and reach a bad conclusion.

I find the single mis-use case you pose to be unpersuasive.  (Others may disagree, but for me, the value is not worth the cost).


How nmap guesses the operating system? nmap has the capability to guess the operating system with the option -O.
I was highly surprised that it can find the correct kernel or service pack.

* How nmap guesses the operating system?

* What are common signatures for Windows 7,8, various Linux systems etc?

A list of the various tests used are provided in the mmap documentation at http://nmap.org/book/osdetect-methods.html#osdetect-probes-seq. For more specific details you'll have to read the source code.

Essentially various different probe packets are sent and the results analysed. Slight differences between TCP/IP software mean there are sometimes slight differences in the response to certain probe packets. With enough tests you can put together a fingerprint that identifies the OS very accurately.

An example might help. If you receive a TCP packet from a host, it contains a number of header options. The definition of the TCP protocol in RFC793 doesn't specify what order these options should be put in. So if the person who wrote the networking code for BeOS put those options in a particular order, and you receive a packet with the options in that order, then you can deduce that the packet might have come from a BeOS host.  That may not enough on it's own to be sure it is BeOs; perhaps the TCP stack in Haiku puts the options in the same order. So you have to find some other test that gives different results for a packet from BeOS than it does from Haiku.


I think they can.
Assuming that the 192.168.1.0 network is your home-network and the 10.2.100.0 network the VPN network, this line in your routing table:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.158 25

0.0.0.0 0.0.0.0 On-link 10.2.100.225 1

Show that the VPN Gateway has a lower Metric value than your home gateway.
This means that all routing to any IP address (0.0.0.0) will first be TRIED over the VPN.

If the VPN is configured to block this, your normal route will be followed, but, technically, your company can LOG packets incoming on the VPN interface.

So to your question, "CAN they see what I'm doing", the answer is, yes, likely.


Should a wildcard ssl certificate be shared with a different organization hosting a subdomain? We are hosting our own secure site with a wildcard certificate.  However, we are working with a marketing company that provides landing pages on subdomains of our domain, on ip addresses supplied by their isp.  They might want to secure those landing pages.

So the plan might be to allow them to use our wildcard certificate on their servers.

Is this a good idea?
Would be be better to get another certificate for the purposes of sharing with this other company?
Should they get their own certificate, since it would be hosted on their servers, and perhaps just invoice us for the cost?

I've had to do this before with Marketo and a few other firms.  In these situations, build a new wildcard cert using a subdomain and send them that cert/key pair.  That way if they're compromised somehow you can revoke that single cert and remove that subdomain.  This is a pretty common way to get around these issues.

Example:

Your existing wildcard: *.company.com
For marketing channel:  Create *.campaign.company.com  (give them this)

My caveat:  No marketing solution that I've worked with ever really needed a full wildcard to do their job and it's possible their administration is just lazy.  Ask if there are specific names they're looking for and in that case, SAN cert.

Never let another company build a cert against your domain name.  A) They may not/should not be able to unless using a horrid CA, and B) they don't need to follow your compliance requirements regarding SSL.

-Chase


Where can I use the TCP FIN scan? For a coursework i've got to run the various port scans, i'm having trouble with the FIN scan though, I can't seem to find a system where I can try it, everywhere I try it all ports either come back as Open | Filtered or all closed (which I know is not correct).

As i understand it's used to get around stateless firewalls that block SYN scans, does anyone know an operating system or setup I can use to get a few screenshots of it working in action?

The background is RFC 793 says open ports should discard out-of-state segments and closed ports should return a RST packet, but lots of operating systems don't follow the RFC to heart, i'm looking for a system that does so I can test the FIN scan out.

I would like to remind you that FIN scan does not work on windows operating systems. Furthermore, the existence of firewalls can prevent the scan from returning the correct result.

It will work fine on Mac and Linux. (Unless the port has been filtered by a firewall)
I tested with Kali Linux-Kernel 3.14 and it works.

root@kali:~# nmap -sF 127.0.0.1 -p 80

Starting Nmap 6.46 ( http://nmap.org ) at 2014-10-03 17:13 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000064s latency).
PORT   STATE  SERVICE
80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds
root@kali:~# apache2ctl start
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
root@kali:~# nmap -sF 127.0.0.1 -p 80,81

Starting Nmap 6.46 ( http://nmap.org ) at 2014-10-03 17:14 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000017s latency).
PORT   STATE         SERVICE
80/tcp open|filtered http
81/tcp closed        hosts2-ns

Nmap done: 1 IP address (1 host up) scanned in 1.46 seconds
root@kali:~# uname -a
Linux kali 3.14-kali1-amd64 #1 SMP Debian 3.14.5-1kali1 (2014-06-07) x86_64 GNU/Linux


Is it possible to find out what a remote user is trying to do connecting to a closed port? From my iptables log, I can observe a particular remote IP address trying to connect to my server from port 80 to a private port number:

Jul 09 01:24:41 example.com kernel: IPTABLES: IN=eth1 MAC=xx:xx:xx SRC=abc.a.b.c DST=xyz.x.y.z LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=16405 PROTO=TCP SPT=80 DPT=61412 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 09 01:29:42 example.com kernel: IPTABLES: IN=eth1 MAC=xx:xx:xx SRC=abc.a.b.c DST=xyz.x.y.z LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=31270 PROTO=TCP SPT=80 DPT=61412 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 09 01:32:41 example.com kernel: IPTABLES: IN=eth1 MAC=xx:xx:xx SRC=abc.a.b.c DST=xyz.x.y.z LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=43052 PROTO=TCP SPT=80 DPT=61412 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 09 01:34:40 example.com kernel: IPTABLES: IN=eth1 MAC=xx:xx:xx SRC=abc.a.b.c DST=xyz.x.y.z LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=53328 PROTO=TCP SPT=80 DPT=61412 WINDOW=16384 RES=0x00 ACK SYN URGP=0

This has been going on for a day and the connection is made every 5 minutes or so. I tried accessing the site from its IP address but it says connection reset. nslookup gives a non-authoritative answer:

Non-authoritative answer:
xyz.x.y.z.in-addr.arpa  name = xyz.x.y.z.static.eigbox.net.

It appears that someone could be spoofing my server's ip address, causing this remote computer to respond by sending ACK SYN packages to my server. I even log the iptables output to this IP address to ensure that my server is not responding to it.

Is it possible to find out what a remote user is trying to do connecting to a closed port without compromising my server's security?

If I'm reading that log correctly, you're seeing backscatter from a spoofed-packet denial-of-service attack (possibly a SYN flood) against a webserver running on abc.a.b.c.  The constant destination port and exact-multiples-of-a-minute timing is a bit odd, though.

The log is showing SYN/ACK packets (that is, the second stage in a TCP three-way handshake) coming from port 80 to a port in the private range.  That means the server received a packet to port 80 that claimed to be from your address; if it's part of an attack, the attacker is using forged addresses to hide where the attack is coming from and make it harder to block.

As for seeing what they're doing, you could use Wireshark or another packet-sniffing program to look at what's inside those packets, but I doubt you'll find anything interesting.


Why would someone want to encrypt RSS feeds? I heard the idea of encrypting the RSS feeds using public key encryption system from someone and since then I am intrigued by the idea. But then I started to wonder what would be the basic need for someone to encrypt their RSS feeds but, could figure it out myself.

I need ideas about why someone wants to encrypt their feeds. This would help me to take a decision whether RSS public-key encryption is something worth doing. I also would like to see if there are any other encryption systems and if they failed to satisfy people and why?

If you're talking about SSL, the answer is why not? If I had the choice, I'd prefer that every site on the internet provided HTTPS. Is it strictly necessary? Of course not. Does it stop anyone from snooping on my content? Yes. Does it reduce the chances of an attacker injecting content into a page via man-in-the-middle? Yes. Are either of these scenarios likely to occur? Not really. It's just a case of what you find comfortable.

In terms of the effort required by the RSS feed provider, it's largely dependant on the type of content and types of user that will be subscribing. If it's a feed of posts from the EFF, then you damn well better make sure it's done over HTTPS. If it's a feed of muffin recipes, it's not so much of an issue.


Is it possible to remove the password on new generations of Lenovo X1? I have lost the password for my setup.
I set it up a few years ago and now I cannot recall it.
The supervisor password is not stored in an EEPROM so the usual tricks do not work.
I think it is in a TPM chip.
Would it be possible to reprogram the chip or replace it to remove the password?

I understand I might lose some key in the TPM that is required to decrypt the data on my hard-drive but that is not a problem. I don't have a boot password and still access my data on the hard-drive and can make a backup copy of it before proceeding with resetting the TPM chip.

From the Lenovo Support Website:

  A forgotten Supervisor password will prevent access to the ThinkPad
  BIOS setup utility. If the Supervisor password has been forgotten and
  cannot be made available to the service technician, there is no
  service procedure to reset the password. The system board must be
  replaced for a scheduled fee. Proof of purchase is required, and this
  repair is not covered under the warranty.

So this leads me to believe that there is something soldered onto the board that is storing the supervisor password, possibly the TPM. However, I have not been able to find any evidence for this claim. The way to reset the Supervisor password from here is replacing the system board, either by yourself or through Lenovo.