How Can You Tell If A SQL Injection Attack Is Successful

egrizzlyegrizzly Member Posts: 533 ■■■■■□□□□□
Heh guys,

How can one tell if a SQL Injection Attack is successful?  For all the searches I did on SQL Injection attacks they always describe how it works and how to prevent it but not how to tell if it was successful or not.

Does any of you experienced folks know how to tell whether a SQL Injection attack was successful or not?  As always thanks for your feedback, tips, and comments.
B.Sc (Info. Systems), CISSP, CCNA, CCNP, Security+

Comments

  • si20si20 Member Posts: 543 ■■■■■□□□□□
    You might need to be a little bit more specific. Do you mean for a blue team looking at logs? Or for an attacker performing SQLi? If you're talking about an attacker, then a bad guy (or white hat) knows it was successful when he/she gets an error message. This usually indicates that it's vulnerable. When they've managed to extract data, even if it's something as seemingly small as a database version, then they'll know that it's vulnerable and needs patching.

    If you're talking about it from a blue team/analyst perspective - usually there are logs and logic/rulesets in place to look out for SQL being entered into applications.
  • egrizzlyegrizzly Member Posts: 533 ■■■■■□□□□□
    Thanks for the input si20.  I'm talking about it from a blue team/analyst perspective.  Yeah, I'm 100% up to speed with the part about identifying the SQL statements being entered into the applications however how do you know that such statements where successful in what they attempted to query?  I say this because anybody can enter SELECT, WHERE, etc into an input field but that does not mean any of it will get through.
    B.Sc (Info. Systems), CISSP, CCNA, CCNP, Security+
  • si20si20 Member Posts: 543 ■■■■■□□□□□
    egrizzly said:
    Thanks for the input si20.  I'm talking about it from a blue team/analyst perspective.  Yeah, I'm 100% up to speed with the part about identifying the SQL statements being entered into the applications however how do you know that such statements where successful in what they attempted to query?  I say this because anybody can enter SELECT, WHERE, etc into an input field but that does not mean any of it will get through.
    That's what your ethical hacking team are there to do really. Incident response should engage the security team to check it out.
  • iBrokeITiBrokeIT Member Posts: 1,318 ■■■■■■■■■□
    DB log review
    2019: GPEN | GCFE | GXPN | GICSP | CySA+ 
    2020: GCIP | GCIA 
    2021: GRID | GDSA | Pentest+ 
    2022: GMON | GDAT
    2023: GREM  | GSE | GCFA

    WGU BS IT-NA | SANS Grad Cert: PT&EH | SANS Grad Cert: ICS Security | SANS Grad Cert: Cyber Defense Ops SANS Grad Cert: Incident Response
  • egrizzlyegrizzly Member Posts: 533 ■■■■■□□□□□
    iBrokeIT said:
    DB log review
    I know you determine this from logs.  What specifically are you looking for in the logs?
    B.Sc (Info. Systems), CISSP, CCNA, CCNP, Security+
  • iBrokeITiBrokeIT Member Posts: 1,318 ■■■■■■■■■□
    edited May 2020
    egrizzly said:
    iBrokeIT said:
    DB log review
    I know you determine this from logs.  What specifically are you looking for in the logs?

     Malformed SQL queries that are not consistent with the design of the webapp's input fields. 
    2019: GPEN | GCFE | GXPN | GICSP | CySA+ 
    2020: GCIP | GCIA 
    2021: GRID | GDSA | Pentest+ 
    2022: GMON | GDAT
    2023: GREM  | GSE | GCFA

    WGU BS IT-NA | SANS Grad Cert: PT&EH | SANS Grad Cert: ICS Security | SANS Grad Cert: Cyber Defense Ops SANS Grad Cert: Incident Response
  • JDMurrayJDMurray Admin Posts: 13,023 Admin
    edited May 2020
    When I see information displayed on the screen that came from me injecting a SELECT on a table in the database I consider that a success. If I perform an SQL injection and see database error messages on my screen that no user should see I consider that a success. If I perform an SQL injection and get no response back when I should see an "invalid input" error message that a user should see I consider that a success too.
  • egrizzlyegrizzly Member Posts: 533 ■■■■■□□□□□
    Hi JD.  Yeah, but you're saying all this from a pen-testers point of view.  I'm a SOC analyst. The furthest I can get with these attacks is being able to identify the SQL commands (e.g. SELECT, WHERE, etc). However after that their's no way to tell if the attack was successful (or if the system is vulnerable) just by looking at the logs.
    B.Sc (Info. Systems), CISSP, CCNA, CCNP, Security+
  • denisehiltondenisehilton Member Posts: 17 ■■■□□□□□□□
    The logs will tell you obviously. That's why Syslog servers and SIEM solutions are so useful. If there's any unauthorized access the SIEM will generate an alert.
  • iBrokeITiBrokeIT Member Posts: 1,318 ■■■■■■■■■□
    The logs will tell you obviously. That's why Syslog servers and SIEM solutions are so useful. If there's any unauthorized access the SIEM will generate an alert.
    SQL injection leverages the webapp's DB access to "inject" the malicious query through an authorized connection therefore you will not see unauthorized access related to SQL injection.
    2019: GPEN | GCFE | GXPN | GICSP | CySA+ 
    2020: GCIP | GCIA 
    2021: GRID | GDSA | Pentest+ 
    2022: GMON | GDAT
    2023: GREM  | GSE | GCFA

    WGU BS IT-NA | SANS Grad Cert: PT&EH | SANS Grad Cert: ICS Security | SANS Grad Cert: Cyber Defense Ops SANS Grad Cert: Incident Response
  • JDMurrayJDMurray Admin Posts: 13,023 Admin
    egrizzly said:
    Hi JD.  Yeah, but you're saying all this from a pen-testers point of view.  I'm a SOC analyst. The furthest I can get with these attacks is being able to identify the SQL commands (e.g. SELECT, WHERE, etc). However after that their's no way to tell if the attack was successful (or if the system is vulnerable) just by looking at the logs.
    Ah, you didn't mention from the SOC analyst's perspective. The database server's transaction logs will indicate what happened at the time the injection was performed. You need to make sure the detection system and the database server are using the same time-base for their time-stamping of events.
Sign In or Register to comment.